Recovering a DBspace

Version: 7.31 OS: AIX 4.3.3 We recently had a hard drive go south on our test box which IBM has replaced. Unforutnately, due some obscure problem in AIX, the only way we could recreate the logical volume for the Informix dbspace was with a different name. Also, it appears that we do not have a proper backup (don't ask!) and Informix tech support says we need to drop the dbspace and recreate it BUT they refuse to tell us how to do this, insisting they must dial into our system and do it themselves. This is not a trivial task, Sooo, is it really all that difficult/dangerous to drop a dbspace? If not how? (This is not one of the critical ones but ...) Part 2: How difficult would it be to move the data for that one dbspace from our production box to the test one? Could that be done from the production level 0 or should we unload/reload or what? Now for the REAL fun and games! The root dbspace resides on a logical volume with a corrupted control block which IBM tells us cannot be rebuilt (they tried!). Their recommendation: remove and recreate the lv and then restore from backups. Informix will come up fine so we can probably run a level 0 but I would appreciate any tips/gotchas/etc. To wit: 1. What information should be saved/printed before blowing away the root dbspace? 2. Is ontape really reliable enough to risk everything on a single level 0? Can backups be verified? 3. Can only the root dbspace be restored or must all dbspaces? Any help for a fledgling DBA trainee would be greatly appreciated. Thank you, Lucky Lucky Leavell Phone: (800) 481-2393 or (812) 366-4066 UniXpress - Your Source for SCO FAX: (888) 231-9640 or (812) 366-3618 1560 Zoar Church Road NE Email: lucky@UniXpress.com Corydon, IN 47112-7374 WWW Home Page: http://www.UniXpress.com

In the IDS Admin manuals it plainly recommends the use of soft links to chunk names, rather than the chunk names themselves. And your problems illustrate why! I think you're saying that you're in the situation where your root dbspace is located on, say /dev/lv01/rchunk01, and that the disk is fault. Had you used a link to this chunk, say /opt/informix/dbspace1/rootdbs, you could simply close IDS down, dd the contents of /dev/lv01/rchunk01 to, say, /dev/lv04/rchunk09, remove the soft link from /opt/informix/dbspace1/rootdbs to the old disk and re-created it linked to the new one, and brought IDS back up. Similarly with the non-critical disk; if you'd used links you could take a level 0 archive, re-linked to the new lv name and restored. IDS has a flaw (some will say it's a design feature, but it *is* a flaw!) which allows archives to be restored only to the precise chunk names extant at the time of the archive - hence the soft link recommendation. Perhaps Informix can frig things for you - after all, the names must be stored somewhere, reserved pages I expect, but you have to know what you're doing, so they don't support it unless they do it themselves, and even then will probably ask you to waive their liability before they do it. This limitation will probably be the main constraint on using ontape to copy your database from live to test. In answer to your specific questions: 1. Before blowing away the root dbspace you should have a note of the extant chunk names used by the server (onstat -d). 2. ontape really is that reliable. However, in order to guard against media failure you could take multiple back-ups. www.iiug.org has an arcchecker utility you could use. 3. You'll have to restore all dbspaces. Lucky Leavell [RIS] <ris@iglou.com> wrote in message news:Pine.GSO.4.31.0101262054100.18219-100000@shell1... > Version: 7.31 > OS: AIX 4.3.3 > > We recently had a hard drive go south on our test box which IBM has > replaced. Unforutnately, due some obscure problem in AIX, the only way we > could recreate the logical volume for the Informix dbspace was with a > different name. Also, it appears that we do not have a proper backup > (don't ask!) and Informix tech support says we need to drop the dbspace > and recreate it BUT they refuse to tell us how to do this, insisting they > must dial into our system and do it themselves. This is not a trivial > task, Sooo, is it really all that difficult/dangerous to drop a dbspace? > If not how? (This is not one of the critical ones but ...) > > Part 2: How difficult would it be to move the data for that one dbspace > from our production box to the test one? Could that be done from the > production level 0 or should we unload/reload or what? > > Now for the REAL fun and games! The root dbspace resides on a logical > volume with a corrupted control block which IBM tells us cannot be rebuilt > (they tried!). Their recommendation: remove and recreate the lv and then > restore from backups. Informix will come up fine so we can probably run a > level 0 but I would appreciate any tips/gotchas/etc. To wit: > > 1. What information should be saved/printed before blowing away > the root dbspace? > > 2. Is ontape really reliable enough to risk everything on a single > level 0? Can backups be verified? > > 3. Can only the root dbspace be restored or must all dbspaces? > > Any help for a fledgling DBA trainee would be greatly appreciated. > > Thank you, > Lucky > > Lucky Leavell Phone: (800) 481-2393 or (812) 366-4066 > UniXpress - Your Source for SCO FAX: (888) 231-9640 or (812) 366-3618 > 1560 Zoar Church Road NE Email: lucky@UniXpress.com > Corydon, IN 47112-7374 WWW Home Page: http://www.UniXpress.com >

If you were using onbar you could backup or restore by dbspace. Henry Neil Truby wrote: > In the IDS Admin manuals it plainly recommends the use of soft links to > chunk names, rather than the chunk names themselves. And your problems > illustrate why! > > I think you're saying that you're in the situation where your root dbspace > is located on, say /dev/lv01/rchunk01, and that the disk is fault. Had you > used a link to this chunk, say /opt/informix/dbspace1/rootdbs, you could > simply close IDS down, dd the contents of /dev/lv01/rchunk01 to, say, > /dev/lv04/rchunk09, remove the soft link from /opt/informix/dbspace1/rootdbs > to the old disk and re-created it linked to the new one, and brought IDS > back up. > > Similarly with the non-critical disk; if you'd used links you could take a > level 0 archive, re-linked to the new lv name and restored. IDS has a flaw > (some will say it's a design feature, but it *is* a flaw!) which allows > archives to be restored only to the precise chunk names extant at the time > of the archive - hence the soft link recommendation. Perhaps Informix can > frig things for you - after all, the names must be stored somewhere, > reserved pages I expect, but you have to know what you're doing, so they > don't support it unless they do it themselves, and even then will probably > ask you to waive their liability before they do it. This limitation will > probably be the main constraint on using ontape to copy your database from > live to test. > > In answer to your specific questions: > > 1. Before blowing away the root dbspace you should have a note of the > extant chunk names used by the server (onstat -d). > 2. ontape really is that reliable. However, in order to guard against > media failure you could take multiple back-ups. www.iiug.org has an > arcchecker utility you could use. > 3. You'll have to restore all dbspaces. > > Lucky Leavell [RIS] <ris@iglou.com> wrote in message > news:Pine.GSO.4.31.0101262054100.18219-100000@shell1... > > Version: 7.31 > > OS: AIX 4.3.3 > > > > We recently had a hard drive go south on our test box which IBM has > > replaced. Unforutnately, due some obscure problem in AIX, the only way we > > could recreate the logical volume for the Informix dbspace was with a > > different name. Also, it appears that we do not have a proper backup > > (don't ask!) and Informix tech support says we need to drop the dbspace > > and recreate it BUT they refuse to tell us how to do this, insisting they > > must dial into our system and do it themselves. This is not a trivial > > task, Sooo, is it really all that difficult/dangerous to drop a dbspace? > > If not how? (This is not one of the critical ones but ...) > > > > Part 2: How difficult would it be to move the data for that one dbspace > > from our production box to the test one? Could that be done from the > > production level 0 or should we unload/reload or what? > > > > Now for the REAL fun and games! The root dbspace resides on a logical > > volume with a corrupted control block which IBM tells us cannot be rebuilt > > (they tried!). Their recommendation: remove and recreate the lv and then > > restore from backups. Informix will come up fine so we can probably run a > > level 0 but I would appreciate any tips/gotchas/etc. To wit: > > > > 1. What information should be saved/printed before blowing away > > the root dbspace? > > > > 2. Is ontape really reliable enough to risk everything on a single > > level 0? Can backups be verified? > > > > 3. Can only the root dbspace be restored or must all dbspaces? > > > > Any help for a fledgling DBA trainee would be greatly appreciated. > > > > Thank you, > > Lucky > > > > Lucky Leavell Phone: (800) 481-2393 or (812) 366-4066 > > UniXpress - Your Source for SCO FAX: (888) 231-9640 or (812) 366-3618 > > 1560 Zoar Church Road NE Email: lucky@UniXpress.com > > Corydon, IN 47112-7374 WWW Home Page: http://www.UniXpress.com > >