IDS, raw diskspace and Solaris

Hi, after RTFMing most the way through the Admin Manual for IDS Workgroup Edition I want to start with a little test database. I'm using a Sun system with Solaris 2.5.1 and just added a new drive for testing. I want to use raw disk space and partitioned the disk for experimenting with multiple dbspaces and mirroring. I still got the following questions (used SE until now): 1. will my eyes ever return back to their natural form after I continued with all the other manuals ?-) 2. the admin manual suggests setting group and user 'informix' for the raw disk device. Is this mandatory or are this security reasons. How should I set this for Solaris systems - the /dev/rdsk entries are linked themselves in some stages to the real device. Can anyone give me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set the 'informix' ownership to the link. 3. is there a practical decision where to put the link? Should I put it in the /dev directory or is it better to create a new "dbspace" directory with all the links in it? TIA Axel (and sure there is more to learn)

>2. the admin manual suggests setting group and user 'informix' for the >raw disk device. Is this mandatory or are this security reasons. How >should I set this for Solaris systems - the /dev/rdsk entries are >linked themselves in some stages to the real device. Can anyone give >me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set >the 'informix' ownership to the link. It's more than a suggestion; IDS will be unable to access the disk unless it's owner and group are informix. The permissions should be 660, although more liberal permissions will also work. As mentioned in TFM, you should create a link to the raw device rather than use the device name itself - this helps recovery if the disk fails. So, as an example: 1. ln -s /dev/rdsk/c0t1d0s0 /opt/informix/dbspaces/mydbspace 2. chown informix:informix /opt/informix/dbspaces/mydbspace 3. chmod 660 /opt/informix/dbspaces/mydbspace 4. onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 0 -s 2097150 (Don't forget to slice up your disk so as not to use cylinder 0 for a raw device - the disk vtoc is stored here and Solaris will allow Informix to overwrite it. Also, I've composed the aboveoffline so I can't swear for its 100% accuracy). >3. is there a practical decision where to put the link? Should I put >it in the /dev directory or is it better to create a new "dbspace" >directory with all the links in it? I find it easier to administer the system using the latter approach - all the dbspaces listed in a central area. Neil Truby Londis Stores Hampton Hill, UK

Neil Truby wrote: > > >2. the admin manual suggests setting group and user 'informix' for the > >raw disk device. Is this mandatory or are this security reasons. How > >should I set this for Solaris systems - the /dev/rdsk entries are > >linked themselves in some stages to the real device. Can anyone give > >me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set > >the 'informix' ownership to the link. > > It's more than a suggestion; IDS will be unable to access the disk unless > it's owner and group are informix. The permissions should be 660, although > more liberal permissions will also work. > > As mentioned in TFM, you should create a link to the raw device rather than > use the device name itself - this helps recovery if the disk fails. So, as > an example: > > 1. ln -s /dev/rdsk/c0t1d0s0 /opt/informix/dbspaces/mydbspace > 2. chown informix:informix /opt/informix/dbspaces/mydbspace > 3. chmod 660 /opt/informix/dbspaces/mydbspace > > 4. onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 0 -s 2097150 > > (Don't forget to slice up your disk so as not to use cylinder 0 for a raw > device - the disk vtoc is stored here and Solaris will allow Informix to > overwrite it. Also, I've composed the aboveoffline so I can't swear for its > 100% accuracy). > Yes, Niel, but you specified offset zero in your step 4. I think if you were going to follow this, it would look like this? onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 1024 -s 2097150 ------------------------------------------------------------^^^^^^ AIX for example *allows* offset zero, probably the same for other UNIX's, and as a matter of practice I use 4096 for all the starting offsets. This way there's no possible problem. By the way if you're using XPS, you use neato commands like this instead of onspaces: CREATE DBSLICE work_dbs FROM COGROUP all CHUNK "/opt/informix/symlinks/work01.%c" OFFSET 4096 SIZE 2000000 KBYTES , COGROUP all CHUNK "/opt/informix/symlinks/work02.%c" OFFSET 4096 SIZE 2000000 KBYTES ; It would be good to see single-server 7.x--or whatever the next release will be, move towards this kind of interface, a bit more user friendly than onspaces. ( Of course you wouldn't need COGROUPs. ) > >3. is there a practical decision where to put the link? Should I put > >it in the /dev directory or is it better to create a new "dbspace" > >directory with all the links in it? > > I find it easier to administer the system using the latter approach - all > the dbspaces listed in a central area. > > Neil Truby > Londis Stores > Hampton Hill, UK -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -

In article <375FA3CD.745FF77C@mindspring.com>, Tim Schaefer <tschaefe@mindspring.com> writes >Neil Truby wrote: >> >> >2. the admin manual suggests setting group and user 'informix' for the >> >raw disk device. Is this mandatory or are this security reasons. How >> >should I set this for Solaris systems - the /dev/rdsk entries are >> >linked themselves in some stages to the real device. Can anyone give >> >me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set >> >the 'informix' ownership to the link. >> >> It's more than a suggestion; IDS will be unable to access the disk unless >> it's owner and group are informix. The permissions should be 660, although >> more liberal permissions will also work. >> >> As mentioned in TFM, you should create a link to the raw device rather than >> use the device name itself - this helps recovery if the disk fails. So, as >> an example: >> >> 1. ln -s /dev/rdsk/c0t1d0s0 /opt/informix/dbspaces/mydbspace >> 2. chown informix:informix /opt/informix/dbspaces/mydbspace >> 3. chmod 660 /opt/informix/dbspaces/mydbspace >> >> 4. onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 0 -s 2097150 >> >> (Don't forget to slice up your disk so as not to use cylinder 0 for a raw >> device - the disk vtoc is stored here and Solaris will allow Informix to >> overwrite it. Also, I've composed the aboveoffline so I can't swear for its >> 100% accuracy). >> > >Yes, Niel, but you specified offset zero in your step 4. I think if you were >going to follow this, it would look like this? > > onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 1024 -s 2097150 If the actual slice is correctly set up (e.g. doesn't use cylinder 0) then I don't think that you need an offset in the first dbspace set up on that slice. Of course subsequent dbspaces do - unless you want to overwrite the initial one! However, if this is just an initial test system and you have the space I think it's much easier to use 'cooked' file systems to start with. <snip> -- Surfer!

"Surfer!" wrote: > If the actual slice is correctly set up (e.g. doesn't use cylinder 0) > then I don't think that you need an offset in the first dbspace set up > on that slice. Of course subsequent dbspaces do - unless you want to > overwrite the initial one! > > However, if this is just an initial test system and you have the space I > think it's much easier to use 'cooked' file systems to start with. > > <snip> > > -- > Surfer! Surfer Dude, A "slice" is only possible on an XPS system, a dbspace is what you meant to say. It appears with your alias and the errors in your message that you have no real world experience. Nice try here, but perhaps after actually doing the work your reply will be different. Along with a real name instead of an alias. Catch a wave, smoke on it, and then, loik dude, report back your findings. -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -

Axel Sander wrote: > > Hi, > > after RTFMing most the way through the Admin Manual for IDS Workgroup > Edition I want to start with a little test database. I'm using a Sun > system with Solaris 2.5.1 and just added a new drive for testing. I > want to use raw disk space and partitioned the disk for experimenting > with multiple dbspaces and mirroring. > > I still got the following questions (used SE until now): > > 1. will my eyes ever return back to their natural form after I > continued with all the other manuals ?-) Yes, but do not try this with other vendor's manuals. I know DBAs who have never recovered from trying to read the big O's manuals. > 2. the admin manual suggests setting group and user 'informix' for the > raw disk device. Is this mandatory or are this security reasons. How > should I set this for Solaris systems - the /dev/rdsk entries are > linked themselves in some stages to the real device. Can anyone give > me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set > the 'informix' ownership to the link. The ownership (informix), group (informix), and permissions (0660) are mandatory, the engine will not even start if the permissions are not exact and you can only start it as root if the ownerships are wrong. Set the permission on the link if it is a hard link and on the link AND the device to which it points if it is a soft link. > 3. is there a practical decision where to put the link? Should I put > it in the /dev directory or is it better to create a new "dbspace" > directory with all the links in it? I always place the links that the engine actually uses as chunk names in the informix home, or the parent of the install directory in a subdir named "disks". This way when you upgrade to another version you do not have to worry about moving the links from the old version's install dir. Also by keeping the links away from /dev you keep them away from aggressive admin types who occassionally decide to remove links that they do not recognize. I also always make these soft links owned by informix/informix/777 with the ownerships and permissions of the pointed-to device as detailed above. Note that on some systems the permissions of devices will not survive the reboot process so you may have to install an rc script to correct the permissions and ownerships of your chunks at each reboot. > TIA Axel (and sure there is more to learn) Art S. Kagel

Tim Schaefer wrote in message <375FA3CD.745FF77C@mindspring.com>... >Neil Truby wrote: >> (Don't forget to slice up your disk so as not to use cylinder 0 for a raw >> device - the disk vtoc is stored here and Solaris will allow Informix to >> overwrite it. Also, I've composed the aboveoffline so I can't swear for its >> 100% accuracy). >> > >Yes, Niel, but you specified offset zero in your step 4. I think if you were >going to follow this, it would look like this? > > onspaces -c mydbspace -p /opt/informix/dbspaces/mydbspace -o 1024 -s2097150 Tim I said "Don't forget to SLICE (my capitals) up your disk so as not to use cylinder 0 ......" , that is, use the UNIX format command to avoid use of cylinder 0 for a raw slice. If you do this, then there is no need to specify an offset in Informix as well. Perhaps there's a confusion in terms here? In Solaris, format is used to partition a disk, and specify the block ranges for a slice. Neil

In article <375FF3C6.451AB90B@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes > > >Axel Sander wrote: >> >> Hi, >> >> after RTFMing most the way through the Admin Manual for IDS Workgroup >> Edition I want to start with a little test database. I'm using a Sun >> system with Solaris 2.5.1 and just added a new drive for testing. I >> want to use raw disk space and partitioned the disk for experimenting >> with multiple dbspaces and mirroring. >> >> I still got the following questions (used SE until now): >> >> 1. will my eyes ever return back to their natural form after I >> continued with all the other manuals ?-) > >Yes, but do not try this with other vendor's manuals. I know DBAs >who have never recovered from trying to read the big O's manuals. > Sorry, never got far with the O manuals (I feel ill already!!..) >> 2. the admin manual suggests setting group and user 'informix' for the >> raw disk device. Is this mandatory or are this security reasons. How >> should I set this for Solaris systems - the /dev/rdsk entries are >> linked themselves in some stages to the real device. Can anyone give >> me an example? Otherwise I would link to /dev/rdsk/c0txdysz and set >> the 'informix' ownership to the link. > >The ownership (informix), group (informix), and permissions (0660) are >mandatory, the engine will not even start if the permissions are not >exact and you can only start it as root if the ownerships are wrong. > >Set the permission on the link if it is a hard link and on the link >AND the device to which it points if it is a soft link. > Solaris has /dev/rdsk as soft links into /devices. You need to change all the permissions. Create a soft link in your own directory to /dev/rdsk.. and change all the permissions:- ln -s /dev/rdsk/c0t0d0s0 /mysoftware/devices/chunk1 # -h changes permissions on the link itself chown -h informix /mysoftware/devices/chunk1 chgrp -h informix /mysoftware/devices/chunk1 chmod 660 /mysoftware/devices/chunk1 chown -h informix /dev/rdsk/c0t0d0s0 chgrp -h informix /dev/rdsk/c0t0d0s0 # /devices entry ends in a-g for slice s0-s7 # ,raw means the raw device (/dev/rdsk/... # without ,raw it is the cooked device /dev/dsk/... chown informix /devices/...sbus@1f...a,raw chgrp informix /devices/...sbus@1f...a,raw [Now we have a Sun box at work I feel a new entry for IIUG coming on infxperm /mysoftware/devices/chunk1...). >> 3. is there a practical decision where to put the link? Should I put >> it in the /dev directory or is it better to create a new "dbspace" >> directory with all the links in it? > >I always place the links that the engine actually uses as chunk names >in the informix home, or the parent of the install directory in a >subdir named "disks". This way when you upgrade to another version you >do not have to worry about moving the links from the old version's >install dir. Also by keeping the links away from /dev you keep them >away from aggressive admin types who occassionally decide to remove >links that they do not recognize. I also always make these soft links >owned by informix/informix/777 with the ownerships and permissions of >the pointed-to device as detailed above. Note that on some systems the >permissions of devices will not survive the reboot process so you may >have to install an rc script to correct the permissions and ownerships >of your chunks at each reboot. > >> TIA Axel (and sure there is more to learn) > >Art S. Kagel -- David Williams

In article <375FB311.65D75A28@mindspring.com>, Tim Schaefer <tschaefe@mindspring.com> writes >"Surfer!" wrote: >> If the actual slice is correctly set up (e.g. doesn't use cylinder 0) >> then I don't think that you need an offset in the first dbspace set up >> on that slice. Of course subsequent dbspaces do - unless you want to >> overwrite the initial one! >> >> However, if this is just an initial test system and you have the space I >> think it's much easier to use 'cooked' file systems to start with. >> >> <snip> >> >> -- >> Surfer! > >Surfer Dude, > >A "slice" is only possible on an XPS system, a dbspace is what you meant >to say. No. I meant a slice. The system I look after has several dbspaces and chunks in the same slice so I doubt very much that 'slice' and 'dbspace' are one and the same thing. They all use the same device name (which is a link to the actual device) with different offsets. The slice is in effect the physical address of where we started allocating disk space in the raw file system to Online, of in the case of the cooked chunks added by someone else of the UNIX file containing the dbspace. > >It appears with your alias I use and alias as my own name is very easy to find in the phone book, and also it's generally better to not use my business email address to post. Makes the difference between me and my employer quire clear. > and the errors in your message that you have >no real world experience. That's not what it felt like the other week.... > Nice try here, but perhaps after actually >doing the work your reply will be different. Along with a real name >instead of an alias. How much of a real name do you want? And how would you know that I was telling the truth? Surely it's better to use and obvious alias than a made up name. However I will change to 'John Doe' if you prefer. AFAIK there is nothing against anonymity in the charter for this NG. > >Catch a wave, smoke on it, and then, loik dude, report back your findings. -- Surfer!

Neil Truby wrote: <...> > I said "Don't forget to SLICE (my capitals) up your disk so as not to use > cylinder 0 ......" , that is, use the UNIX format command to avoid use of > cylinder 0 for a raw slice. If you do this, then there is no need to > specify an offset in Informix as well. > > Perhaps there's a confusion in terms here? In Solaris, format is used to > partition a disk, and specify the block ranges for a slice. > > Neil Neil, Yes, I see the confusion. I did not know that Solarious had this feature to avoid offset zero. I'd been told AIX doesn't have this ability, so we always offset by at least 1 page, for safety ( 4096 for XPS ). And the other thing is that there is indeed the term to "disk slice" and Informix's term to DBSLICE a logical grouping in XPS of dbspaces such as: rootdbs Co DB Chk Svr Disk Drive Offset No No DB Space Name Symbolic Link 1 /dev/rm1c1l1d1r5 4096 1 1 rootchk.1 /opt/informix/symlinks.1/rootchk.1 2 /dev/rm2c1l1d1r5 4096 4 4 rootchk.2 /opt/informix/symlinks.2/rootchk.2 3 /dev/rm3c1l1d1r5 4096 2 2 rootchk.3 /opt/informix/symlinks.3/rootchk.3 4 /dev/rm4c1l1d1r5 4096 3 3 rootchk.4 /opt/informix/symlinks.4/rootchk.4 tempdbs Co DB Chk Svr Disk Drive Offset No No DB Space Name Symbolic Link 1 /dev/rm1c1l1d2r4 4096 5 5 tempchk1.1 /opt/informix/symlinks.1/tempchk1.1 3 /dev/rm3c1l1d3r4 4096 14 14 tempchk2.3 /opt/informix/symlinks.3/tempchk2.3 3 /dev/rm3c1l1d4r4 4096 15 15 tempchk3.3 /opt/informix/symlinks.3/tempchk3.3 3 /dev/rm3c1l1d5r4 4096 16 16 tempchk4.3 /opt/informix/symlinks.3/tempchk4.3 4 /dev/rm4c1l1d2r4 4096 17 17 tempchk1.4 /opt/informix/symlinks.4/tempchk1.4 4 /dev/rm4c1l1d3r4 4096 18 18 tempchk2.4 /opt/informix/symlinks.4/tempchk2.4 4 /dev/rm4c1l1d4r4 4096 19 19 tempchk3.4 /opt/informix/symlinks.4/tempchk3.4 4 /dev/rm4c1l1d5r4 4096 20 20 tempchk4.4 /opt/informix/symlinks.4/tempchk4.4 1 /dev/rm1c1l1d3r4 4096 6 6 tempchk2.1 /opt/informix/symlinks.1/tempchk2.1 1 /dev/rm1c1l1d4r4 4096 7 7 tempchk3.1 /opt/informix/symlinks.1/tempchk3.1 1 /dev/rm1c1l1d5r4 4096 8 8 tempchk4.1 /opt/informix/symlinks.1/tempchk4.1 2 /dev/rm2c1l1d2r4 4096 9 9 tempchk1.2 /opt/informix/symlinks.2/tempchk1.2 2 /dev/rm2c1l1d3r4 4096 10 10 tempchk2.2 /opt/informix/symlinks.2/tempchk2.2 2 /dev/rm2c1l1d4r4 4096 11 11 tempchk3.2 /opt/informix/symlinks.2/tempchk3.2 2 /dev/rm2c1l1d5r4 4096 12 12 tempchk4.2 /opt/informix/symlinks.2/tempchk4.2 3 /dev/rm3c1l1d2r4 4096 13 13 tempchk1.3 /opt/informix/symlinks.3/tempchk1.3 The above is a report on the "tempdbs" DBSLICE and the rootdbs, which spans 4 coservers, or nodes, or machines. "Co Svr" represents a node or machine number. The second report is for space usage: rootdbs DB Chk Co DB -------- Pages -------- Pct -------- Megabytes ------- No No Svr Space Name Total Free Used Full Total Free Used 1 1 1 rootdbs.1 12500 10425 2075 16.60 50000 41699 8299 4 4 2 rootdbs.2 12500 12357 143 1.14 50000 49427 571 2 2 3 rootdbs.3 12500 12357 143 1.14 50000 49427 571 3 3 4 rootdbs.4 12500 12357 143 1.14 50000 49427 571 * rootdbs 50000 47496 2504 5.01 200000 189982 10013 tempdbs DB Chk Co DB -------- Pages -------- Pct -------- Megabytes ------- No No Svr Space Name Total Free Used Full Total Free Used 5 5 1 tempdbs.1 500000 499543 457 0.09 2000000 1998171 1827 14 14 3 tempdbs.10 500000 499543 457 0.09 2000000 1998171 1827 15 15 3 tempdbs.11 500000 499543 457 0.09 2000000 1998171 1827 16 16 3 tempdbs.12 500000 499543 457 0.09 2000000 1998171 1827 17 17 4 tempdbs.13 500000 499543 457 0.09 2000000 1998171 1827 18 18 4 tempdbs.14 500000 499543 457 0.09 2000000 1998171 1827 19 19 4 tempdbs.15 500000 499543 457 0.09 2000000 1998171 1827 20 20 4 tempdbs.16 500000 499543 457 0.09 2000000 1998171 1827 6 6 1 tempdbs.2 500000 499543 457 0.09 2000000 1998171 1827 7 7 1 tempdbs.3 500000 499543 457 0.09 2000000 1998171 1827 8 8 1 tempdbs.4 500000 499543 457 0.09 2000000 1998171 1827 9 9 2 tempdbs.5 500000 499543 457 0.09 2000000 1998171 1827 10 10 2 tempdbs.6 500000 499543 457 0.09 2000000 1998171 1827 11 11 2 tempdbs.7 500000 499543 457 0.09 2000000 1998171 1827 12 12 2 tempdbs.8 500000 499543 457 0.09 2000000 1998171 1827 13 13 3 tempdbs.9 500000 499543 457 0.09 2000000 1998171 1827 * tempdbs 8000000 7992688 7312 0.09 32000000 31970750 29234 I'd show you other dbslice examples but don't want to risk showing things that are client confidential. Thanks, Tim -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -