Re: Rootdb

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. _____________________________________________________________________________