All 3 messages in topic - view as tree
From: Mike Badar - view profile
Date: Mon, Dec 4 2006 9:21 pm
Email: "Mike Badar"
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
mba...@esri.com
303-449-7779
www.esri.com
OS: Solaris 9
IDS: 9.3.FC1
- Hide quoted text -
- Show quoted text -
>> 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 500000 0
MO-
>> /dev/datadbs3M
>> 10dd754c0 15 4 125001 375000 369525
PO-
>> /dev/datadbs4
>> 10dd76958 15 4 125001 375000 0
MO-
>> /dev/datadbs4M
>> 10dd75648 16 1 350001 25000 24981
PO-
>> /dev/rootdbs
>> 10dd76ae0 16 1 350001 25000 0
MO-
>> /dev/rootdbsM
>> 16 active, 2047 maximum
>> INFORMIX ha_prod >
>> (secondary)
>> INFORMIX ha_prod_b >onstat -d
>> Informix Dynamic Server Version 9.30.FC1 -- Quiescent --
Up
>> 14:11:39 -- 105472 Kbytes
>> Dbspaces
>> address number flags fchunk nchunks flags
>> owner name
>> 10d16ce50 1 0x2 1 2 M
>> informix rootdbs
>> 10dd76958 2 0x2 2 1 M
>> informix phylog
>> 10dd76ad0 3 0x2 3 1 M
>> informix llog
>> 10dd76c48 4 0x2 4 2 M
>> informix ap
>> 10dd76dc0 5 0x2 5 1 M
>> informix crs
>> 10dd77028 6 0x2 6 2 M
>> informix ori
>> 10dd771a0 7 0x2001 7 1 N T
>> informix tmp
>> 10dd77318 8 0x2001 8 1 N T
>> informix tmp2
>> 10dd77490 9 0x2 9 1 M
>> informix hr
>> 10dd77608 11 0x2 11 3 M
>> informix cts
>> 10 active, 2047 maximum
>> Chunks
>> address chk/dbs offset size free bpages
>> flags pathname
>> 10d16d028 1 1 1 25000 3439
PO-
>> /dev/rootdbs
>> 10d16d1b0 1 1 1 25000 0
MO-
>> /dev/rootdbsM
>> 10dd74028 2 2 25001 75000 69947
PO-
...
read more »
Reply » Rate this post: Text for clearing space
From: barr...@xtivia.com - view profile
Date: Mon, Dec 4 2006 11:40 pm
Email: barr...@xtivia.com
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.
- Hide quoted text -
- Show quoted text -
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
> mba...@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 500000 0
> MO-
> >> /dev/datadbs3M
> >> 10dd754c0 15 4 125001 375000 369525
> PO-
> >> /dev/datadbs4
> >> 10dd76958 15 4 125001 375000 0
> MO-
> >> /dev/datadbs4M
> >> 10dd75648 16 1 350001 25000 24981
> PO-
> >> /dev/rootdbs
> >> 10dd76ae0 16 1 350001 25000 0
> MO-
> >> /dev/rootdbsM
> >> 16 active, 2047 maximum
> >> INFORMIX ha_prod >
> >> (secondary)
> >> INFORMIX ha_prod_b >onstat -d
> >> Informix Dynamic Server Version 9.30.FC1 -- Quiescent --
> Up
> >> 14:11:39 -- 105472 Kbytes
> >> Dbspaces
> >> address number flags fchunk nchunks flags
> >> owner name
> >> 10d16ce50 1 0x2 1 2 M
> >> informix rootdbs
> >> 10dd76958 2 0x2 2 1 M
> >> informix phylog
> >> 10dd76ad0 3 0x2 3 1 M
> >> informix llog
> >> 10dd76c48 4 0x2 4 2 M
> >> informix ap
> >> 10dd76dc0 5 0x2 5 1 M
> >> informix crs
> >> 10dd77028 6 0x2 6 2 M
> >> informix ori
> >> 10dd771a0 7 0x2001 7 1 N T
> >> informix tmp
> >> 10dd77318 8 0x2001 8 1 N T
> >> informix tmp2
> >> 10dd77490 9 0x2 9 1 M
> >> informix hr
> >> 10dd77608 11 0x2 11 3 M
> >> informix cts
> >> 10 active, 2047 maximum
> >> Chunks
> >> address chk/dbs offset size free bpages
> >> flags pathname
> >> 10d16d028 1 1 1 25000 3439
> PO-
> >> /dev/rootdbs
> >> 10d16d1b0 1 1 1 25000 0
> MO-
> >> /dev/rootdbsM
> >> 10dd74028 2 2 25001 75000 69947
> PO-
> >> /dev/rootdbs
> >> 10dd75648 2 2 25001 75000 0
> MO-
> >> /dev/rootdbsM
> >> 10dd741b0 3 3 100001 250000 197
> PO-
> >> /dev/rootdbs
> >> 10dd757d0 3 3 100001 250000 0
> MO-
> >> /dev/rootdbsM
> >> 10dd74338 4 4 1 25000 19977
> PO-
> >> /dev/datadbs1
> >> 10dd75958 4 4 1 25000 0
> MO-
> >> /dev/datadbs1M
> >> 10dd744c0 5 5 25001 150000 142129
> PO-
> >> /dev/datadbs1
> >> 10dd75ae0 5 5 25001 150000 0
> MO-
> >> /dev/datadbs1M
> >> 10dd74648 6 6 175001 175000 4116
> PO-
> >> /dev/datadbs1
> >> 10dd75c68 6 6 175001 175000 0
> MO-
> >> /dev/datadbs1M
> >> 10dd747d0 7 7 350001 75000 74947
> PO-
> >> /dev/datadbs1
> >> 10dd74958 8 8
...
read more »
Reply » Rate this post: Text for clearing space
From: Mike Badar - view profile
Date: Wed, Dec 6 2006 3:37 pm
Email: "Mike Badar"
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
- Hide quoted text -
- Show quoted text -
> 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
> > mba...@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 500000 0
> > MO-
> > >> /dev/datadbs3M
> > >> 10dd754c0 15 4 125001 375000 369525
> > PO-
> > >> /dev/datadbs4
> > >> 10dd76958 15 4 125001 375000 0
> > MO-
> > >> /dev/datadbs4M
> > >> 10dd75648 16 1 350001 25000 24981
> > PO-
> > >> /dev/rootdbs
> > >> 10dd76ae0 16 1 350001 25000 0
> > MO-
> > >> /dev/rootdbsM
> > >> 16 active, 2047 maximum
> > >> INFORMIX ha_prod >
> > >> (secondary)
> > >> INFORMIX ha_prod_b >onstat -d
> > >> Informix Dynamic Server Version 9.30.FC1 -- Quiescent --
> > Up
> > >> 14:11:39 -- 105472 Kbytes
> > >> Dbspaces
> > >> address number flags fchunk nchunks flags
> > >> owner name
> > >> 10d16ce50 1 0x2 1 2 M
> > >> informix rootdbs
> > >> 10dd76958 2 0x2 2 1 M
> > >> informix phylog
> > >> 10dd76ad0 3 0x2 3 1 M
> > >> informix llog
> > >> 10dd76c48 4 0x2 4 2 M
> > >> informix ap
> > >> 10dd76dc0 5 0x2 5 1 M
> > >> informix crs
> > >> 10dd77028 6 0x2 6 2 M
> > >> informix ori
> > >> 10dd771a0 7 0x2001 7 1 N T
> > >> informix tmp
> > >> 10dd77318 8 0x2001 8 1 N T
> > >> informix tmp2
> > >> 10dd77490 9 0x2 9 1 M
> > >> informix hr
> > >> 10dd77608 11 0x2 11 3 M
> > >> informix cts
> > >> 10 active, 2047 maximum
> > >> Chunks
> > >> address chk/dbs offset size free bpages
> > >> flags pathname
> > >> 10d16d028 1 1 1 25000 3439
> > PO-
> > >> /dev/rootdbs
> > >> 10d16d1b0 1 1 1 25000 0
> > MO-
> > >> /dev/rootdbsM
> > >> 10dd74028 2 2 25001 75000 69947
> > PO-
> > >> /dev/rootdbs
> > >> 10dd75648 2 2
...
read more »
Reply » Rate this post:
End of messages
No comments:
Post a Comment