RE: HDR: restore failed on secondary

Barrie, > 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. This worked. Thank you very much. Mike > > 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