force drop dbspace with first chunk inconsistent?

Hi, we have in a test environment a dbpspace with it's first chunk in state I (inconsistent) and we can't drop the dbspace (we don't need it, but it's not possible to drop it). I'd like to know if there's a way to force the dropping of the dbspace. The dbspace itself is, according to the onstat -d ouput in state 'NP B', which means ' Physically recovered, waiting for P -- logical recovery'. The chunk is in state 'PI-B', i.e. inconsistent. The output from onstat -d update: ~ $ onstat -d update |grep test 157f67d88 18 0x40401 24 1 2048 NP B informix test_dbs 157f65d30 24 18 0 25000 24161 PI-B /opt/informix/db1/test_dbs The problem with the whole thing is that the backups with onbar fail because of this inconsisency. It would be nice if there was a way to tell the IDS server that we don't want to proceed with the logical recovery of test_dbs (we can't, we don't have the logs) and that we just don't need the dbspace at all. When we try a drop informix prompts us with this: ~ $ onspaces -d test_dbs WARNING: Dropping a DBspace. Do you really want to continue? (y/n)y Cannot drop the Space. ISAM error: no such DBspace IDS is 10.00.FC9 on solaris (SPARC) 5.9. Thanks in advance. Gerardo Padierna

Put a call into tech support and they can do a secure "dial-in" to your system and drop it for you. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Aug 24, 2010 at 6:38 AM, GERARDO PADIERNA <g.padierna@gmail.com>wrote: > Hi, > we have in a test environment a dbpspace with it's first chunk in state I > (inconsistent) and we can't drop the dbspace (we don't need it, but it's > not > possible to drop it). I'd like to know if there's a way to force the > dropping > of the dbspace. > The dbspace itself is, according to the onstat -d ouput in state 'NP B', > which > means ' Physically recovered, waiting for P -- logical recovery'. > The chunk is in state 'PI-B', i.e. inconsistent. > > The output from onstat -d update: > ~ $ onstat -d update |grep test > 157f67d88 18 0x40401 24 1 2048 NP B informix test_dbs > 157f65d30 24 18 0 25000 24161 PI-B /opt/informix/db1/test_dbs > > The problem with the whole thing is that the backups with onbar fail > because > of this inconsisency. It would be nice if there was a way to tell the IDS > server that we don't want to proceed with the logical recovery of test_dbs > (we > can't, we don't have the logs) and that we just don't need the dbspace at > all. > When we try a drop informix prompts us with this: > ~ $ onspaces -d test_dbs > WARNING: Dropping a DBspace. > Do you really want to continue? (y/n)y > Cannot drop the Space. > ISAM error: no such DBspace> > IDS is 10.00.FC9 on solaris (SPARC) 5.9. > > Thanks in advance. > > Gerardo Padierna > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0016e6471ada9a463a048e99709e