Informix

IDS 12.10.FC14

Solaris 10   1/13

This is related to this prior thread which discusses sbspaces that contain objects with Ref Count = 0, or Ref Count = 1, but with zero tables in the database that actually reference the object.

The work-around is simple and effective: bounce Informix, then run 'onspaces -cl'.

That, of course, means an interruption in service, which we avoid as much as possible for our production databases.  And, the database involved in this case is production.

Running 'onspaces -cl' cleans up the erroneous objects with Ref Count = 0, but, does it do anything else?

I'm always paranoid about doing stuff to production.  I want to DROP that sbspace, so I don't care whether it is cleaned up first, or not.  But, if it does anything else (behind the scenes) that could have some side-effect that would "bite me", I'll wait for our next maintenance window, and do the bounce.

Otherwise, I could just do a forced DROP ('onspaced -d -f') and be on my way.

Might anyone know if there is any risk in doing the forced drop, as opposed to cleaning the sbspace, and then doing the drop?

(I have already satisfied myself that the remaining object that has a Ref Count = 1, really and truly is absolutely NOT referenced by any other table in the database.  So, I am happy to destroy it, too.  How 'oncheck -cS'  could report a Ref Count = 1, when there is no reference is a mystery to me.  Were it up to me, I would insist that Informix should track the references, and be able to tell me what table(s) reference objects when Informix asserts that there are more than 0 references.)

Anyway, I can't mock up a test environment because I do not know how to intentionally create zombie objects (objects that have a Ref Count of 0-- or more than 0--, yet have zero tables in the database that actually reference the object).

I just want to (forcibly) delete that sbspace, but do not want to put a production database at risk.

Thank you.

DG

IDS 12.10.FC14

Solaris 10   1/13

This is related to this prior thread which discusses sbspaces that contain objects with Ref Count = 0, or Ref Count = 1, but with zero tables in the database that actually reference the object.

The work-around is simple and effective: bounce Informix, then run 'onspaces -cl'.

That, of course, means an interruption in service, which we avoid as much as possible for our production databases.  And, the database involved in this case is production.

Running 'onspaces -cl' cleans up the erroneous objects with Ref Count = 0, but, does it do anything else?

I'm always paranoid about doing stuff to production.  I want to DROP that sbspace, so I don't care whether it is cleaned up first, or not.  But, if it does anything else (behind the scenes) that could have some side-effect that would "bite me", I'll wait for our next maintenance window, and do the bounce.

Otherwise, I could just do a forced DROP ('onspaced -d -f') and be on my way.

Might anyone know if there is any risk in doing the forced drop, as opposed to cleaning the sbspace, and then doing the drop?

(I have already satisfied myself that the remaining object that has a Ref Count = 1, really and truly is absolutely NOT referenced by any other table in the database.  So, I am happy to destroy it, too.  How 'oncheck -cS'  could report a Ref Count = 1, when there is no reference is a mystery to me.  Were it up to me, I would insist that Informix should track the references, and be able to tell me what table(s) reference objects when Informix asserts that there are more than 0 references.)

Anyway, I can't mock up a test environment because I do not know how to intentionally create zombie objects (objects that have a Ref Count of 0-- or more than 0--, yet have zero tables in the database that actually reference the object).

I just want to (forcibly) delete that sbspace, but do not want to put a production database at risk.

Thank you.

DG