Re: Rootdb

I just wanted to point out that currently we are using unix filesystem mirroring not Infomix's chunk to chunk mirroring. Rootdb is a raw space allocated for Informix and is managed by Informix. I am a bit confused as to why I need to do a dbexport. I was under the assumption that, all I need to do is create a level 0 backup of the database (which is about 11.5 gigs), create a Logical Volume in the other VG, bring Informix down, remove the current link, create the link pointing to the new rootdb and then restore...since the new rootdb has no data. jparker@hpbs3645.boi.hp.com (Jack Parker) wrote: >I am making this public since I didn't see a lot of other answers float across >and because it is a good thing to know how to do. >If y'all would be good enough to comment on this we can clean it up and >stick into the FAQ. >---- cya ---- >I hope you understand that this note is strictly my own thoughts and that >I am not acting in an official capacity for HP. Should something go >disastrously wrong with the procedure I outlined it's not HPs fault. For >that matter it's not my responsibility. >You should be all right - we have used such a procedure succesfully in the >past - but it would not be good to let you think that I was the official >HP/Informix mouthpiece. >--- >I'm pretty thin on the logical volume manager - so you'll have to interpret >what I suggest there. >I am also going to assume that your Online knowledge is minimal. If I >insult your intelligence please forgive me. >I also wrote this in large part without referring to other materials. In >places I make comments about this or that which are not wholly accurate, but >there is enough information to get through it. >----------------------------------------------------------------------------- >The basic procedure, with the goal of staying online as much as possible, >is: >1 - backup. Do a tbtape AND a dbexport. If we make a mistake, we should >be able to recover from the tbtape archive, but tbtape insists on having the >same dbspace names, sizes and device links (I seem to remember) - so just to >be safe do a dbexport as well. This will probably turn the database into >read-only for a bit - so there's "downtime 1". >2 - I neglected to ask if you have a spare drive hanging around. If you do, >specify this as the mirror to rootdbs. You can do this by manually editing >the $TBCONFIG file and specifying the device, offset and MIRROR = 1. ># These guys - the situation below is a non-mirrored situation >MIRROR 0 # Mirroring flag (Yes = 1, No = 0) >MIRRORPATH # Path for device containing root dbspace mirror >MIRROROFFSET 0 # Offset into mirror device (Kbytes) ># Mirrored situation >MIRROR 1 # Mirroring flag (Yes = 1, No = 0) >MIRRORPATH /dev/xxxxx # Path for device containing root dbspace mirror >MIRROROFFSET 40 # Offset into mirror device (Kbytes) >You should also be able to make these changes through tbmonitor > (dbspaces->mirror I think) >------------------ >Some notes: >a - always use an offset of at least 40. We have had problems in the past with >Informix trying to take over that portion of the disk where sparing information >is kept causing disk crashes. >b - always use a symbolic link for device names: > MIRRORPATH /users/informix/dev/rootdb_mirror > rootdb_mirror is then symbolically linked to /dev/rdsk/c?d?s? >Like: >/bsmc/dev: >lrwxr-xr-x 1 informix informix 16 Sep 17 1992 logdbs -> /dev/rdsk/c6d0s2 >/dev/rdsk: >crw-rw-r-- 1 informix informix 12 0x000102 Jun 5 14:53 /dev/rdsk/c6d0s2 >This makes it possible to play disk games like we are going to need to play now. >This way you can swap out a physical drive by merely pointing your symbolic >link to a different device and things will still work smoothly. >c - make sure permissions on the device AND the symbolic link are 664 and >the owner is informix:informix. (Hmmm, ours are 664 and 755 - I'm probably >wrong then). >------------------ >3 - You will then need to take the engine down and bring it back up so that it >reads the changed configuration. "downtime 2" >4 - once you are up the mirror may automatically start "imaging". It may come >up in a down state. You WANT it to start imaging. a tbstat -d should show >the device as imaging - (I think it's status becomes "I" as opposed to "O" >(Online) or "D" (Down)). You will probably have to go to tbmonitor -> dbspaces >-> status, select the mirror and bring it up for this to occur. >5 - Once the mirror is imaged you can take down the primary chunk (the >splintered rootdbs). (tbmonitor -> dbspaces -> status -> select chunk and >change it's status). >6 - At this point you can do the logical volume manager stuff to create a >single volume of the proper size for your rootdbs. Probably something like >drop volume, create volume. If you are using a single device you don't really >need to do a logical volume (do you?). >7 - edit $TBCONFIG and change you ROOTPATH to your new device (remember to >use a symoblic link). >(for example). >ROOTPATH /as_built/dev/as_built_rootdbs #device containing root dbspace >8 - take the engine down and bring it back up to read the config changes. >"downtime 3" >9 - go change the status of the primary chunk to Online - IT will re-image and >you are set. >This should take care of what you want to do. Your engine will remain online >during most of this procedure. How long your dbexport takes, the imaging and >so forth all depend on the size of your database. We did this series of >operations about 3 years ago on a 2GB database and while it took 3-4 hours >to complete, actual downtime was along the lines of 10 minutes total. >The rootbs is normally fairly small (did you say 400MB?) - this should not >take a long time to image. The dbexport, of course, is going to export >everything. >Good luck - let me know how it works out or if you have any problems or >questions. >cheers >j. >_____________________________________________________________________________ >Jack Parker - Hewlett Packard, DMD/IS Boise, Idaho, USA >jparker@hpbs3645.boi.hp.com Back in Boise >_____________________________________________________________________________ > If anything can go wrong, fix it. To hell with Murphy. >_____________________________________________________________________________ > Any opinions expressed herein are my own and not those of my employers. >_____________________________________________________________________________ *************************************************************** Ask as many questions, you may find the answer. * * e-mail: dkulkarn@ix.netcom.com * * ****************************************************************