Re: Moving ROOTDBSPACE travails

In article <61vpre$d06@news.informix.com>, June Tong <junet@informix.com> writes >Cosmo Lee ("*NO-SPAM*cosmo"@echonyc.com) wrote: >: Helloooo, nobody out there has ever tried moving a root dbspace??? My >: newserver _must_ be dropping postings, cuz I _can't_ believe nobody here >: has done this. Or are you guys just holding out on me?! ;-) > >Okay, I've never done it myself, but I would never hold out, so here goes... > >: > I'm trying to physically move a client's rootdbs from a Unix file >: > based >: > dbs to a raw device. >: > 1. Take a level 0 archive to tape. 2. dd contents of cooked file into raw partition with the same offset and size. 3. Remove cooked file and replace with a link to the raw partition. Done. The ROOTPATH in your ONCONFIG file is a LINK to the cooked fil (so you just have to change where it link points to) isn't it? Informix recommends you use links to your chunk so you can move them by changing the link. >: > On the theory that the primary and mirror dbspaces are *exactly* the >: > same (I have been told this by an Informix Engineer) I've tried >: > turning >: > mirroring on for the rootdbs, and created a mirror on a raw device. I >: > >: > brought Online down then brought it back up with the primary rootdbs >: > symbolic link now pointing to the mirror slice. I turned mirroring >: > off >: > in the onconfig file so that Online wouldn't try to search for the >: > mirror chunk. This did not work. Online complained about >: > inconsistencies in the chunks. I'm curious why. > Because internally online contains a table listing the chunks including mirror chunks. Mirroring in the ONCONFIG file MUST be enabled if you have mirror chunks. >I don't know. I just tested this (using cooked files that I mv'ed around, >rather than symbolic links) and it worked fine. > >: > Since that did not work, I'm going to try another way: I'll bring the >: > primary chunk down (leaving a mirror up), I'll repoint the rootdbs >: > symbolic link (formerly the primary) to a raw device, then bring it >: > back >: > online. This should recover the dbs in the raw device, NO?? > >Sounds reasonable. > >: > 1) Assuming the above is viable, when I bring the former primary root >: > chunk/dbs back online, does it become the mirror or does it revert >: > back >: > to being the primary chunk? > >It reverts to being the primary chunk. > >: > 2) the primary rootdbs was created with an offset of 2000k. I don't >: > suppose that when I recover it after dropping it that I can get rid of >: > the offset (it's not needed)?? > >No, you can't get rid of it. I have no idea why they would have created it >with an offset on a cooked file in the first place. > >: > 3) When I mark the primary rootdbs (Unix file) as down, can I then >: > *drop* it? This would make the mirror dbspace the primary (with no >: > mirror) - then could I add another mirror, this time in a raw slice. >: > (with no offset??) > >No, you can't drop it. > >: > Anything I need to be warned about?. Is there is a better way to do >: > this?? Am I about to do something foolish and regrettable? > >Well, we would normally just recommend that you restore an archive after >moving the symbolic link to point to the raw device you want the rootdbs on, >but I guess you don't want to do that, so... In theory, it sounds good... >You won't get any guarantees from me, though ;-) > > >June > >---- June Tong Informix Software ---- >---- Senior Consultant (650) 926-6140 ---- >---- International Support junet@informix.com ---- >---- Location-du-jour: Stockholm, Sweden ---- >* >* Standard disclaimers apply >* >- Please do not send me requests/questions by mail. When I have the knowledge >- and time permits, I try to answer questions on comp.databases.informix, but >- travel schedule, time, and volume make responding to personal requests >- difficult and often slow. Please call your local Informix Technical Support >- organization for assistance with technical issues. -- David Williams