Informix

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

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

Hi,

Thanks!

What does oncheck -pS give for the sbspace?

How do the "Create Flags" and "Status Flags" compare to the other sblobs?

Regards,

David.

------------------------------
David Williams

Original Message:
Sent: Wed August 02, 2023 01:49 PM
From: David Grove
Subject: Smart BLOB 16359 bytes, w/ ref count = 1, yet apparently not used by any table

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

------------------------------
David Grove

Original Message:
Sent: Tue August 01, 2023 08:30 PM
From: David Williams
Subject: Smart BLOB 16359 bytes, w/ ref count = 1, yet apparently not used by any table

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

------------------------------
David Williams

Original Message:
Sent: Tue August 01, 2023 01:47 PM
From: David Grove
Subject: Smart BLOB 16359 bytes, w/ ref count = 1, yet apparently not used by any table

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

------------------------------
David Grove

Original Message:
Sent: Mon July 31, 2023 03:58 PM
From: David Grove
Subject: Smart BLOB 16359 bytes, w/ ref count = 1, yet apparently not used by any table

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
------------------------------

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

If you're certain you're not gonna miss sblob(s) still sitting in an sbspace, you can use the onspaces force-drop option to get rid of the space even though non-empty, then recreate the space, thereby restarting with a fresh, small LO header partition.

(force-drop is available only for sbspaces.)

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

Been a few weeks, but back to considering this issue, again.

Force dropping the sbspace is a workable solution for my private (experimental) sandbox.  I do experimenting here, before trying things on PRODUCTION.

So, in my private instance, I have dropped all user databases, and (as expected) this sblob remains.  IOW, I have a smart blob in an sbspace that takes up actual space, and has a non-zero reference count, but there is no table in any database in the instance that actually references it.

In this personal instance, I could easily force drop the sbspace.  But, I want to get rid of this zombie sblob in Production.  The Production instance has thousands of true sblobs, so I can't drop the sbspace.  I want to delete the specific object (4, 4, 122721), but I can't use SQL to delete it because there is no table to enumerate in the FROM clause.  No existing table refers to this object.

So, how can I get rid of this object, in the Production database?

Thank you.

DG

If you're certain you're not gonna miss sblob(s) still sitting in an sbspace, you can use the onspaces force-drop option to get rid of the space even though non-empty, then recreate the space, thereby restarting with a fresh, small LO header partition.

(force-drop is available only for sbspaces.)

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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

Is there a way to edit the Reference Count for an sblob?

Currently, in our production database, the Ref Count for the sblob (a mug shot) is 3.  But, there are only two actual references to this photo in all of the tables in the database.  Consequently, when I DROP the database (after importing it to my private sandbox), the sblob remains instantiated in the sbspace, but no table actually references it.  (And, as shown above, oncheck -cS displays it as having a Ref Count = 1.)

If I could change the Ref Count from "3" to "2" (which is the actual truth), then all would be good.  I know the exact rows in the exact tables that do properly reference the photo.  Informix thinks there is a third reference, but it doesn't really exist.  And, I don't know how to determine what table and row Informix "thinks" points to this photo.  There is no such table in the database, nor any database in the instance.  The sblob is a zombie, and I don't know how to get rid of it.

It seems to me (which is of no consequence) that either Informix should make it impossible for a Ref Count to be nonzero when there is no table that references the object; OR, Informix should provide a way to fix bad references when they occur.

Thank you.

DG

Been a few weeks, but back to considering this issue, again.

Force dropping the sbspace is a workable solution for my private (experimental) sandbox.  I do experimenting here, before trying things on PRODUCTION.

So, in my private instance, I have dropped all user databases, and (as expected) this sblob remains.  IOW, I have a smart blob in an sbspace that takes up actual space, and has a non-zero reference count, but there is no table in any database in the instance that actually references it.

In this personal instance, I could easily force drop the sbspace.  But, I want to get rid of this zombie sblob in Production.  The Production instance has thousands of true sblobs, so I can't drop the sbspace.  I want to delete the specific object (4, 4, 122721), but I can't use SQL to delete it because there is no table to enumerate in the FROM clause.  No existing table refers to this object.

So, how can I get rid of this object, in the Production database?

Thank you.

DG

If you're certain you're not gonna miss sblob(s) still sitting in an sbspace, you can use the onspaces force-drop option to get rid of the space even though non-empty, then recreate the space, thereby restarting with a fresh, small LO header partition.

(force-drop is available only for sbspaces.)

Thank you, David.  (Nice name!)

I did an 'oncheck -cS <sbspace>' and got:

informix@ifmx-prod-jnu>oncheck -cS |more

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      161     42430
  blbsbs:'informix'.LO_hdr_partn                   0x400005   139620     22052

  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

So, an object exists, and it is the only object in that sbspace.  But, no table references it, so I can't do an SQL 'DELETE' command.  (Because there is no table to enter in the 'FROM' clause.)

Also, I could not find (in the documentation) the meaning of the "Creat Flags".  I was curious because all the other sblobs (they are all in other sbspaces) have a value of "N-N-H" for Creat Flags, instead of "L-N-H", that this zombie object has.

DG

Hi,

Did you try oncheck -cS ?

Otherwise you might have to get HCL to dial in and take a look.

Regards,
David.

Edit: "the real question is how to get rid of this zombie sblob."

(Not "these zombie sblobs".  There is only one.)

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