Re: Moving ROOTDBSPACE travails

Just wanted to report the results of my root dbspace move. It went pretty smoothly, actually. I simply marked the primary chunk down. I then deleted the primary chunk, which was a Unix file. I then created a symbolic link with the same name/path as the original primary chunk, now pointing to a raw device. I brought the chunk back up by recovering it, and Voila, my root dbspace was now in a different location! It worked like a Charm. Although I have to admit I was feeling jittery throughout the whole process, even though I felt pretty sure it _should work_: you just never know until you know - I've had too many rude surprises with Online before. My previous attempt to repoint the primary chunk symbolic link to the mirror didn't work, I believe, because the mirror chunk was not created with an offset, while the primary was. I don't believe that there is anything one can do about this. Once your primary chunk is created w/ an offset, Online will always insist it have an offset. So, no, the Primary and its Mirror are not _exactly_ the same, but they are the same from a certain point. I had even tried modifying the root offset in the Onconfig file to zero, then re-starting Online, but that was no-go. I may have been able to get this to work, however, if I created the mirror with the same offset as the primary. The suggestion to use `dd` seemed needlessly complicated and error-prone to me (I'm not so facile w/ `dd`), plus, required bringing the system down. Restoring completely from an archive seemed too time-consuming, cumbersome and would have incurred downtime. It seemed far better to use the facilities built into the software to do this. And it had the advantage of enabling the move to take place w/o bringing database down or off-line. It was nice to see an element of Online which works beautifully in a truly "online" fashion.. Heck, when I was testing this on a trial system, I was marking down and recovering chunks like crazy, all the while the system stayed up. Kinda cool! Thanks for the replies, Art and June! Cosmo Lee Art S. Kagel wrote: >Just shut the engine down, dd the cooked file into the raw file, remove >the cooked file and relink the original filename to the raw file. This >seems easier to me. For best results use dd with bs=2k. >Sorry I missed your original posting. junet@informix.com (June Tong) wrote: 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. : > : > 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. >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 ;-)