IDS 12.10.FC14
Solaris 10 1/13
I wanted to move all sblobs in a certain sbspace to another sbspace. I used this IBM tech note to do so: How to move a table's sblobs . It worked fine.
Because I''m paranoid, I then used 'oncheck -pS' to confirm that no sblobs remained in the original smspace. I was surprised to that a single sblob remained. I examined the oncheck output, and saw that there was an actual sblob (had nonzero size) and had a ref count = 1.
Of course that made me curios about this sblob. I wondered what table referenced it. So, I used Milan Rafaj's query generator (post #8 in the following thread: https://community.ibm.com/community/user/datamanagement/communities/community-home/digestviewer/viewthread?GroupId=4147&MessageKey=9560395b-149e-485b-b203-033d203e84fb&CommunityKey=cf5a1f39-c21f-4bc4-9ec2-7ca108f0a365&tab=digestviewer )
The resulting query produced no results. That is, for every table with sblobs, it reported zero references to the specific sblob that oncheck reported as physically instantiated, and having a ref count = 1.
I looked further, and noted that it was created in 2019. Many databases in that instance have come and gone since 2019.
So, here's the quandary: How can oncheck report a ref count=1 for an instantiated object that is not actually referenced by any table in the database?
OK, I guess I really don't care "why" (other than intellectual curiosity); the real question is how to get rid of these zombie sblobs. It's not like I can do a DELETE (there's no table from which to delete).
DG
------------------------------
David Grove
------------------------------