Informix

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

cat /dev/null > chunkpath will release all the space

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Hey all,

We have a smart blob space that has reached 100% for a vendor package TWS.  We don't know what is in this space.  If this was a data space, we would repack and shrink.  If it was an index space we would drop and rebuild some of the larger indexes.  Is there anything like this you can do to a smartblob?

Yes I know which table is causing the problem (see details below).  We can purge this table of old records, but it still shows the s001 dbspace as 100% full, so the clobs are either 1) not being removed or 2) not being reorged/repacked/shrinked (whatever it is for blobs) to show the space is now free.

create table "LOG".lrpr_record_properties

  (

    lrpr_object_id char(32) not null ,

    lrpr_property_name varchar(50) not null ,

    llrc_id decimal(20,0) not null ,

    llrc_category char(1) not null ,

    lrpr_property_value "informix".clob,

    primary key (llrc_id,lrpr_object_id,lrpr_property_name)  constraint "informix".pk_lrpr

  ) PUT lrpr_property_value in

  (

    s001

  ) extent size 32 next size 32 lock mode row;

revoke all on "LOG".lrpr_record_properties from "public" as "LOG";

create index "LOG".i_lrpr_01 on "LOG".lrpr_record_properties (llrc_id)

    using btree  in d001;

alter table "LOG".lrpr_record_properties add constraint (foreign

    key (llrc_id) references "LOG".llrc_log_records  on delete

    cascade constraint "informix".fk_lrpr_llrc_01);

Unload of tables using s001 showed the problem table to be the properties one:

set isolation to dirty read;

-- sql to find tables that are filling the smart blob spaces

-- lkt01 Mar 4, 2022

--unload to /opt/hd/db/tmp/s001/log.lprp_record_properties select * from "LOG".lprp_record_properties;

I got these files in the filesystem created.  It is clearly the LOG.lprp_record_properties table that is taking all the space.

stuxsh02.st7001:/opt/hd/db/tmp/s001> ls -ltr

total 5857

-rw-rw-r-- 1 informix informix 2217537 Mar  4 17:14 LOG.lrpr_record_properties – table that is growing

-rw-rw-r-- 1 informix informix 2728616 Mar  4 17:14 clob1698.9a4 – blobs going to s001