RE: Possible to move rootdbs?

Nick, I got a similar error after replacing a disk due to hard IO errors. My problem then was that the partitioning of the disk was wrong - there should have been x2 slots reserved for the disk label, which Informix was overwriting. Run a prtvtoc against the new disk, if this is your problem then you should get an error - "could not read label" or something similar. Some disks don't require this initial offset, some do. Geoffrey.Poole@ogs.co.uk Oxford GlycoSciences > -----Original Message----- > From: nmiles@my-dejanews.com [SMTP:nmiles@my-dejanews.com] > Sent: 05 April 1999 22:35 > To: informix-list@iiug.org > Subject: Possible to move rootdbs? > > Hello all, > > Is is possible to take down a primary disk, leaving the mirror, and bring > up > the primary rootdbs on a new disk?? > > Here's what I've tried, which doesn't seem to work... > > Started by taking down the rootdbs primary, leaving the mirror active > with: > > onspaces -s rootdbs -p /dev/vg02/pchunk1 -o 0 -D> > Then I change the link /dev/vg02/pchunk1 to point to a new disk, and > issue: > > onspaces -s rootdbs -p /dev/vg02/pchunk1 -o 0 -O> > This appears to work, as I get: > Verifying physical disk space, please wait ... > > But after a few minutes, I get the error: > Cannot change chunk status. > Unknown error message 0. > > The log only shows: > 15:13:40 Chunk Number 1 - '/dev/vg02/pchunk1' -- Recovery > Begins(-1034506536) > 15:14:50 Checkpoint Completed: duration was 0 seconds. > 15:21:04 Chunk number 1 '/dev/vg02/pchunk1' -- Recovery Failed > 15:21:04 Chunk number 1 '/dev/vg02/pchunk1' -- Recovery > Failed(-1034506536)> > I tried this command while in OnLine mode, and also in Quiescent, both > with > the same results. We're running 7.24.UC5 on HPUX 10.20. > > The objective is to move rootdbs, logdbs, and temp over one day. Then > move > the datadbs's at the rate of 1-2 a day by importing/exporting to clean up > fragmentation. Our datadbs's are sort of separate business > entities, so we > wouldn't be taking down the whole company for a massive move. > > Has anybody tried this, or have any suggestions? > > Thanks in advance, > > Nick Miles > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own >

The requirement you describe (leaving a small offset on a raw device for vtoc information) does not apply to HP-UX, which is the OS that the original poster is using. Neil Geoffrey Poole wrote in message <7echiq$seq$1@news.xmission.com>... > >Nick, >I got a similar error after replacing a disk due to hard IO errors. My >problem then was that the partitioning of the disk was wrong - there should >have been x2 slots reserved for the disk label, which Informix was >overwriting. Run a prtvtoc against the new disk, if this is your problem >then you should get an error - "could not read label" or something similar. >Some disks don't require this initial offset, some do. >Geoffrey.Poole@ogs.co.uk >Oxford GlycoSciences > >> -----Original Message----- >> From: nmiles@my-dejanews.com [SMTP:nmiles@my-dejanews.com] >> Sent: 05 April 1999 22:35 >> To: informix-list@iiug.org >> Subject: Possible to move rootdbs? >> >> Hello all, >> >> Is is possible to take down a primary disk, leaving the mirror, and bring >> up >> the primary rootdbs on a new disk?? >> >> Here's what I've tried, which doesn't seem to work... >> >> Started by taking down the rootdbs primary, leaving the mirror active >> with: >> >> onspaces -s rootdbs -p /dev/vg02/pchunk1 -o 0 -D>> >> Then I change the link /dev/vg02/pchunk1 to point to a new disk, and >> issue: >> >> onspaces -s rootdbs -p /dev/vg02/pchunk1 -o 0 -O>> >> This appears to work, as I get: >> Verifying physical disk space, please wait ... >> >> But after a few minutes, I get the error: >> Cannot change chunk status. >> Unknown error message 0. >> >> The log only shows: >> 15:13:40 Chunk Number 1 - '/dev/vg02/pchunk1' -- Recovery >> Begins(-1034506536) >> 15:14:50 Checkpoint Completed: duration was 0 seconds. >> 15:21:04 Chunk number 1 '/dev/vg02/pchunk1' -- Recovery Failed >> 15:21:04 Chunk number 1 '/dev/vg02/pchunk1' -- Recovery >> Failed(-1034506536)>> >> I tried this command while in OnLine mode, and also in Quiescent, both >> with >> the same results. We're running 7.24.UC5 on HPUX 10.20. >> >> The objective is to move rootdbs, logdbs, and temp over one day. Then >> move >> the datadbs's at the rate of 1-2 a day by importing/exporting to clean up >> fragmentation. Our datadbs's are sort of separate business >> entities, so we >> wouldn't be taking down the whole company for a massive move. >> >> Has anybody tried this, or have any suggestions? >> >> Thanks in advance, >> >> Nick Miles >> >> -----------== Posted via Deja News, The Discussion Network ==---------- >> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own >>