IDS 12.10.FC14
Solaris 10 1/13
This may be similar to a previous issue I posted about, concerning a zombie sblob-- but in that case, the Ref Count = 1.
Today, I'm interested in removing (garbage collecting, I would think) several sblobs in an sbspace. The reason for this is I want to DROP the old sbspace. There are 7 of these problematic things. (8 if you count the one with the Ref Count = 1.) Here is result of 'oncheck -cS <sbspace>':
informix@ifmx-prod-anc>oncheck -cS blbsbs
Validating space 'blbsbs' ...
sbspace Metadata Partition Partnum Used Free
blbsbs:'informix'.TBLSpace 0x400001 6 44
blbsbs:'informix'.sbspace_desc 0x400002 2 2
blbsbs:'informix'.chunk_adjunc 0x400003 2 2
blbsbs:'informix'.LO_ud_free 0x400004 179 42412
blbsbs:'informix'.LO_hdr_partn 0x400005 143024 18648
Large Objects
ID Ref Size Allocced Creat Last
Sbs# Chk# Seq# Cnt (Bytes) Pages Extns Flags Modified
---- ---- ----- ---- ---------- -------- ----- ----- ------------------------
4 4 122721 1 16359 9 1 L-N-H Sat Jun 1 01:43:23 2019
4 4 222121 0 8144 5 1 L-N-H Tue Oct 10 13:15:08 2023
4 4 222133 0 8245 5 1 L-N-H Tue Oct 10 12:34:32 2023
4 4 222135 0 7642 4 1 L-N-H Tue Oct 10 13:19:30 2023
4 4 570920 0 7623 4 1 L-N-H Tue Oct 10 11:56:17 2023
4 4 571334 0 8207 5 1 L-N-H Tue Oct 10 10:21:21 2023
4 4 571799 0 5907 3 1 L-N-H Tue Oct 10 08:27:04 2023
4 4 571811 0 9442 5 1 L-N-H Tue Oct 10 08:23:05 2023
The first sblob has Ref Count =1.
The remaining 7 have Ref Count = 0.
Using Mr. Rafaj's query ( Rafaj's query at end of this thread ), I observe that no table in any database in the instance references any of these sblobs (including the first one [which Informix claims has a Ref Count = 1]).
The strange thing is that when I execute 'onspaces -cl <sbspacename>', none of the 6 sblobs with Ref Count = 0 goes away.
What does that mean? Why would Informix not garbage collect the sblobs with Ref Count = 0?
Could it mean that some part of Informix thinks that those sblobs are still being referenced by something?
I'm thinking that I can force drop that sbspace because NO TABLE in any database in the instance references any of these sblobs.
This seems to be a continual problem with Informix and sblobs (internal ref counts getting out of sync with reality, and Informix does not provide a way to fix these-- nor even detect these problems).
For many years, I have not had occasion to use sblobs much. But, now that I am, I keep finding that there are problems. It just seems like the sblob handling capability of Informix is just not integrated well into the rest of Informix. The whole sblob "ecosystem" seems "out of step" with the rest of Informix (which is extremely robust and reliable). Sblobs not so much.
Anyway, the questions are:
1) Why doesn't 'onspaces -cl' garbage collect the 0 Ref Count sblobs?
2) Why would an sblob with Ref Count = 1 NOT show any references with Rafaj's query? (This question is mostly rhetorical-- I think I've beat it to death in a previous thread, and I think this apparent discrepancy is, in fact, a true discrepancy. IOW, a defect).
3) Is there a risk in force-dropping this sbspace?
I must be careful because this is a production database.
Thank you.
DG
P.S. A tad more info concerning the 7 sblobs with ref count = 0, and dating from Oct 10. That was just a couple days ago when I was moving all (hundreds of thousands) sblobs to a new sbspace. I'm not sure what happened there, but afterwards, a few sblobs (these were clobs, not blobs) continued to be inserted into the old sbspace (despite having run SQL ALTER commands to change the PUT clause in the tables that use sblobs). I "fixed" that by changing the SBSPACENAME config parm to the new sbspace. The question of why that fixed the problem (of clobs being inserted into the old sbspace) when the DDL for the tables had already been ALTERed remains, but that is not the topic of this thread, and is a problem I will address after I get this current issue of safely removing the old sbspace resolved.
------------------------------
David Grove
------------------------------