HDR: restore failed on secondary

Greetings, >From a colleague. Does anyone have any ideas on this one? Thanks in advance for your help. Mike Badar ESRI Professional Services 1 International Ct. Broomfield, CO 80021 mbadar@esri.com 303-449-7779 www.esri.com OS: Solaris 9 IDS: 9.3.FC1 >> After a hardware failure of an Informix 9.3 HDR pair secondary >> server, I am attempting to restart HDR between the primary and >> secondary servers. While HDR was down, another DBA performed >> dbspace drops and chunk adds on the HDR primary server. These >> changes were not replicated over to the secondary server because >> HDR was down at the time. The secondary server has been placed >> in standard mode and it's dbspaces and chunks aligned with those >> of primary server. While attempting to perform a cold restore on >> the secondary server from a level 0 backup taken recently from >> the HDR primary server, I am encountering the following message >> from ontape: >> >> "Physical restore failed - Cannot warm restore ROOT DBspace " >> >> Below is a cut/paste from the vt100 session of the restore (level >> 0 backup completed succesfully...): >> >> INFORMIX ha_prod_b >ontape -p >> >> Please mount tape 1 on twister:/dev/rmt/0 and press Return to >> continue ... >> >> Archive Tape Information >> >> Tape type: Archive Backup Tape >> Online version: Informix Dynamic Server Version 9.30.FC1 >> Archive date: Sun Dec 3 13:48:08 2006 >> User id: informix >> Terminal id: /dev/pts/3 >> Archive level: 0 >> Tape device: twister:/dev/rmt/0 >> Tape blocksize (in k): 256 >> Tape size (in k): 11000000 >> Tape number in series: 1 >> Continue restore? (y/n)y >> >> Spaces to restore:1 [rootdbs >> >> >> 2 [phylog >> >> >> 3 [llog >> >> >> 4 [ap >> >> >> 5 [crs >> >> >> 6 [ori >> >> >> 7 [hr >> >> >> 8 [cts >> >> >> Physical restore failed - Cannot warm restore ROOT DBspace >> >> >> Program over. >> INFORMIX ha_prod_b > >> >> Here is how onmonitor shows the root dbspace/chunks as currently >> configured: >> >> CHUNKS FOR rootdbs - primary >> >> Chunk Chunk Pages Pages Full Pathname of Chunk >> Status >> Id Offset In Chunk Used >> >> 1 1 25000 23769 /dev/rootdbs >> PO- >> 1 1 25000 25000 /dev/rootdbsM >> MO- >> 16 350001 25000 19 /dev/rootdbs >> PO- >> 16 350001 25000 25000 /dev/rootdbsM >> MO- >> >> CHUNKS FOR rootdbs - secondary >> >> Chunk Chunk Pages Pages Full Pathname of Chunk >> Status >> Id Offset In Chunk Used >> >> 1 1 25000 21561 /dev/rootdbs >> PO- >> 1 1 25000 25000 /dev/rootdbsM >> MO- >> 15 358401 25600 3 /dev/rootdbs >> PO- >> 15 358401 25600 25600 /dev/rootdbsM >> MO- >> >> Originally, I was under the impression that the dbspaces/chunks >> needed to match exactly for a cold restore to be performed on an >> HDR secondary server from an HDR primary server level 0 backup. >> However, research as indicated that an exact match is not >> required, only enough space large enough to contain the chunk(s) >> being restored. It this correct? >> >> Here is onstat -d output: >> >> (primary) >> INFORMIX ha_prod >onstat -d >> >> Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up >> 11:37:25 -- 105472 Kbytes >> >> Dbspaces >> address number flags fchunk nchunks flags >> owner name >> 10d16ce50 1 0x2 1 2 M >> informix rootdbs >> 10dd76c68 2 0x2 2 1 M >> informix phylog >> 10dd76de0 3 0x2 3 1 M >> informix llog >> 10dd77028 4 0x2 4 2 M >> informix ap >> 10dd771a0 5 0x2 5 1 M >> informix crs >> 10dd77318 6 0x2 6 2 M >> informix ori >> 10dd77490 7 0x2001 7 1 N T >> informix tmp >> 10dd77608 8 0x2001 8 1 N T >> informix tmp2 >> 10dd77780 9 0x2 9 1 M >> informix hr >> 10dd778f8 11 0x2 11 4 M >> informix cts >> 10 active, 2047 maximum >> >> Chunks >> address chk/dbs offset size free bpages >> flags pathname >> 10d16d028 1 1 1 25000 1231 PO- >> /dev/rootdbs >> 10d16d1b0 1 1 1 25000 0 MO- >> /dev/rootdbsM >> 10dd74028 2 2 25001 75000 69947 PO- >> /dev/rootdbs >> 10dd757d0 2 2 25001 75000 0 MO- >> /dev/rootdbsM >> 10dd741b0 3 3 100001 250000 197 PO- >> /dev/rootdbs >> 10dd75958 3 3 100001 250000 0 MO- >> /dev/rootdbsM >> 10dd74338 4 4 1 25000 3611 PO- >> /dev/datadbs1 >> 10dd75ae0 4 4 1 25000 0 MO- >> /dev/datadbs1M >> 10dd744c0 5 5 25001 150000 141925 PO- >> /dev/datadbs1 >> 10dd75c68 5 5 25001 150000 0 MO- >> /dev/datadbs1M >> 10dd74648 6 6 175001 175000 25 PO- >> /dev/datadbs1 >> 10dd75df0 6 6 175001 175000 0 MO- >> /dev/datadbs1M >> 10dd747d0 7 7 350001 75000 74947 PO- >> /dev/datadbs1 >> 10dd74958 8 8 350001 75000 74947 PO- >> /dev/datadbs1M >> 10dd74ae0 9 9 425001 250000 39326 PO- >> /dev/datadbs1 >> 10dd76028 9 9 425001 250000 0 MO- >> /dev/datadbs1M >> 10dd74c68 10 11 500001 500000 1016 PO- >> /dev/datadbs2 >> 10dd761b0 10 11 500001 500000 0 MO- >> /dev/datadbs2M >> 10dd74df0 11 11 1 500000 218 PO- >> /dev/datadbs2 >> 10dd76338 11 11 1 500000 0 MO- >> /dev/datadbs2M >> 10dd75028 12 6 0 125000 97471 PO- >> /dev/datadbs4 >> 10dd764c0 12 6 0 125000 0 MO- >> /dev/datadbs4M >> 10dd751b0 13 11 0 500000 390403 PO- >> /dev/datadbs5 >> 10dd76648 13 11 0 500000 0 MO- >> /dev/datadbs5M >> 10dd75338 14 11 500001 500000 125 PO- >> /dev/datadbs3 >> 10dd767d0 14 11 500001

In order to do a cold restore, your instance needs to be offline. Your onstat shows that the secondary is in quiescent mode, so ontape thinks you are trying to do a warm restore. Take the instance offline and try again. Barrie Shaw Xtivia, Inc. Mike Badar wrote: > Greetings, > > >From a colleague. Does anyone have any ideas on this one? > > Thanks in advance for your help. > > Mike Badar > ESRI Professional Services > 1 International Ct. > Broomfield, CO 80021 > mbadar@esri.com > 303-449-7779 > www.esri.com > > OS: Solaris 9 > IDS: 9.3.FC1 > > > >> After a hardware failure of an Informix 9.3 HDR pair > secondary > >> server, I am attempting to restart HDR between the primary > and > >> secondary servers. While HDR was down, another DBA > performed > >> dbspace drops and chunk adds on the HDR primary server. > These > >> changes were not replicated over to the secondary server > because > >> HDR was down at the time. The secondary server has been > placed > >> in standard mode and it's dbspaces and chunks aligned with > those > >> of primary server. While attempting to perform a cold restore > on > >> the secondary server from a level 0 backup taken recently > from > >> the HDR primary server, I am encountering the following > message > >> from ontape: > >> > >> "Physical restore failed - Cannot warm restore ROOT DBspace " > >> > >> Below is a cut/paste from the vt100 session of the restore > (level > >> 0 backup completed succesfully...): > >> > >> INFORMIX ha_prod_b >ontape -p > >> > >> Please mount tape 1 on twister:/dev/rmt/0 and press Return to > >> continue ... > >> > >> Archive Tape Information > >> > >> Tape type: Archive Backup Tape > >> Online version: Informix Dynamic Server Version 9.30.FC1 > >> Archive date: Sun Dec 3 13:48:08 2006 > >> User id: informix > >> Terminal id: /dev/pts/3 > >> Archive level: 0 > >> Tape device: twister:/dev/rmt/0 > >> Tape blocksize (in k): 256 > >> Tape size (in k): 11000000 > >> Tape number in series: 1 > >> Continue restore? (y/n)y > >> > >> Spaces to restore:1 [rootdbs > > >> > > >> > >> 2 [phylog > > >> > > >> > >> 3 [llog > > >> > > >> > >> 4 [ap > > >> > > >> > >> 5 [crs > > >> > > >> > >> 6 [ori > > >> > > >> > >> 7 [hr > > >> > > >> > >> 8 [cts > > >> > > >> > >> Physical restore failed - Cannot warm restore ROOT DBspace > >> > >> > >> Program over. > >> INFORMIX ha_prod_b > > >> > >> Here is how onmonitor shows the root dbspace/chunks as > currently > >> configured: > >> > >> CHUNKS FOR rootdbs - primary > >> > >> Chunk Chunk Pages Pages Full Pathname of > Chunk > >> Status > >> Id Offset In Chunk Used > >> > >> 1 1 25000 23769 /dev/rootdbs > > >> PO- > >> 1 1 25000 25000 /dev/rootdbsM > > >> MO- > >> 16 350001 25000 19 /dev/rootdbs > > >> PO- > >> 16 350001 25000 25000 /dev/rootdbsM > > >> MO- > >> > >> CHUNKS FOR rootdbs - secondary > >> > >> Chunk Chunk Pages Pages Full Pathname of > Chunk > >> Status > >> Id Offset In Chunk Used > >> > >> 1 1 25000 21561 /dev/rootdbs > > >> PO- > >> 1 1 25000 25000 /dev/rootdbsM > > >> MO- > >> 15 358401 25600 3 /dev/rootdbs > > >> PO- > >> 15 358401 25600 25600 /dev/rootdbsM > > >> MO- > >> > >> Originally, I was under the impression that the > dbspaces/chunks > >> needed to match exactly for a cold restore to be performed on > an > >> HDR secondary server from an HDR primary server level 0 > backup. > >> However, research as indicated that an exact match is not > >> required, only enough space large enough to contain the > chunk(s) > >> being restored. It this correct? > >> > >> Here is onstat -d output: > >> > >> (primary) > >> INFORMIX ha_prod >onstat -d > >> > >> Informix Dynamic Server Version 9.30.FC1 -- On-Line -- Up > >> 11:37:25 -- 105472 Kbytes > >> > >> Dbspaces > >> address number flags fchunk nchunks flags > > >> owner name > >> 10d16ce50 1 0x2 1 2 M > > >> informix rootdbs > >> 10dd76c68 2 0x2 2 1 M > > >> informix phylog > >> 10dd76de0 3 0x2 3 1 M > > >> informix llog > >> 10dd77028 4 0x2 4 2 M > > >> informix ap > >> 10dd771a0 5 0x2 5 1 M > > >> informix crs > >> 10dd77318 6 0x2 6 2 M > > >> informix ori > >> 10dd77490 7 0x2001 7 1 N T > > >> informix tmp > >> 10dd77608 8 0x2001 8 1 N T > > >> informix tmp2 > >> 10dd77780 9 0x2 9 1 M > > >> informix hr > >> 10dd778f8 11 0x2 11 4 M > > >> informix cts > >> 10 active, 2047 maximum > >> > >> Chunks > >> address chk/dbs offset size free bpages > >> flags pathname > >> 10d16d028 1 1 1 25000 1231 > PO- > >> /dev/rootdbs > >> 10d16d1b0 1 1 1 25000 0 > MO- > >> /dev/rootdbsM > >> 10dd74028 2 2 25001 75000 69947 > PO- > >> /dev/rootdbs > >> 10dd757d0 2 2 25001 75000 0 > MO- > >> /dev/rootdbsM > >> 10dd741b0 3 3 100001 250000 197 > PO- > >> /dev/rootdbs > >> 10dd75958 3 3 100001 250000 0 > MO- > >> /dev/rootdbsM > >> 10dd74338 4 4 1 25000 3611 > PO- > >> /dev/datadbs1 > >> 10dd75ae0 4 4 1 25000 0 > MO- > >> /dev/datadbs1M > >> 10dd744c0 5 5 25001 150000 141925 > PO- > >> /dev/datadbs1 > >> 10dd75c68 5 5 25001 150000 0 > MO- > >> /dev/datadbs1M > >> 10dd74648 6 6 175001 175000 25 > PO- > >> /dev/datadbs1 > >> 10dd75df0 6 6 175001 175000 0 > MO- > >> /dev/datadbs1M > >> 10dd747d0 7 7 350001 75000 74947 > PO- > >> /dev/datadbs1 > >> 10dd74958 8 8 350001 75000 74947 > PO- > >> /dev/datadbs1M > >> 10dd74ae0 9 9 425001 250000 39326 > PO- > >> /dev/datadbs1 > >> 10dd76028 9 9 425001 250000 0 > MO- > >> /dev/datadbs1M > >> 10dd74c68 10 11 500001