Informix

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

P.S.  I think it is possible that there could have been some attempt to experiment with compression, in the past.

Is there any way to know whether any tables in a database are currently using compression?

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

I have executed the following for every user-created database in the instance:

'oncheck -pt <database> | grep Compressed'

I figured that if there is no "Compressed Data Summary" section, then no table in the database is using compression.

None of the databases had a "Compressed Data Summary" section.  Ergo, I think that compression is well and truly unused in this instance.  When IBM tech support gets to this point, I will ask them to delete those phantom remnants of compression.

Makes me scratch my head and wonder why those rsccompdict fragments even exist, and why Informix doesn't provide me a way to clean up the mess.

DG

P.S.  I think it is possible that there could have been some attempt to experiment with compression, in the past.

Is there any way to know whether any tables in a database are currently using compression?

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

You stated the syscompdicts query didn't return empty:

• How many rows did it return?
• They contain the partnum of the partition they were related to - any clues from that?
• If their dict_drop_* fields are non-zero, that means that either those compressed partitions got dropped (and maybe new ones recreated in the meantime for same partnum) or uncompressed.
• dbinfo("utc_to_datetime", dict_create_timestamp) and same on dict_drop_timestamp  might give more clues on when that might have happened.

I have executed the following for every user-created database in the instance:

'oncheck -pt <database> | grep Compressed'

I figured that if there is no "Compressed Data Summary" section, then no table in the database is using compression.

None of the databases had a "Compressed Data Summary" section.  Ergo, I think that compression is well and truly unused in this instance.  When IBM tech support gets to this point, I will ask them to delete those phantom remnants of compression.

Makes me scratch my head and wonder why those rsccompdict fragments even exist, and why Informix doesn't provide me a way to clean up the mess.

DG

P.S.  I think it is possible that there could have been some attempt to experiment with compression, in the past.

Is there any way to know whether any tables in a database are currently using compression?

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

Thank you, Andreas.

One row was returned from syscompdicts.

I have uploaded a file that contains the results of the queries/utilities you previously suggested.

Regards,

DG

You stated the syscompdicts query didn't return empty:

• How many rows did it return?
• They contain the partnum of the partition they were related to - any clues from that?
• If their dict_drop_* fields are non-zero, that means that either those compressed partitions got dropped (and maybe new ones recreated in the meantime for same partnum) or uncompressed.
• dbinfo("utc_to_datetime", dict_create_timestamp) and same on dict_drop_timestamp  might give more clues on when that might have happened.

I have executed the following for every user-created database in the instance:

'oncheck -pt <database> | grep Compressed'

I figured that if there is no "Compressed Data Summary" section, then no table in the database is using compression.

None of the databases had a "Compressed Data Summary" section.  Ergo, I think that compression is well and truly unused in this instance.  When IBM tech support gets to this point, I will ask them to delete those phantom remnants of compression.

Makes me scratch my head and wonder why those rsccompdict fragments even exist, and why Informix doesn't provide me a way to clean up the mess.

DG

P.S.  I think it is possible that there could have been some attempt to experiment with compression, in the past.

Is there any way to know whether any tables in a database are currently using compression?

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix

While waiting for an update from IBM tech support, I went back and re-examined the chunk that contained the phantom rsccompdict table.  (I had tried various suggestions from tech support, with no success.  Got error messages.)  To my surprise, it is now gone.  Disappeared.  I attempted to drop the chunk, and the drop succeeded.

Now, I am left with the rootdbs having the original chunk, plus one additional.  The additional chunk also contains a phantom rsccompdict table.  So, I will attempt to retrace my steps, and do everything I did the last time, and see if I can make this rsccompdict detritus also disappear.

But, this chunk also contains some other tables from sysmaster, sysutils, etc.

I have advised Tech Support of the success in dropping one chunk, and while I am waiting to re-engage with them  regarding the remaining chunk, I figured it wouldn't hurt to rebuild sysmaster, and see if (serendipitously) all the tables would be placed in the initial chunk of rootdbs.

I have never before had any issues with sysmaster, nor any reason to execute buildsmi.  Can I do that safely (after shutting down the scheduler), with no ill effects (other than achieving the same situation I have now-- sysmaster tables spread over both the initial and additional rootdbs chunks)?

Thank you.

DG

Thank you, Andreas.

One row was returned from syscompdicts.

I have uploaded a file that contains the results of the queries/utilities you previously suggested.

Regards,

DG

You stated the syscompdicts query didn't return empty:

• How many rows did it return?
• They contain the partnum of the partition they were related to - any clues from that?
• If their dict_drop_* fields are non-zero, that means that either those compressed partitions got dropped (and maybe new ones recreated in the meantime for same partnum) or uncompressed.
• dbinfo("utc_to_datetime", dict_create_timestamp) and same on dict_drop_timestamp  might give more clues on when that might have happened.

I have executed the following for every user-created database in the instance:

'oncheck -pt <database> | grep Compressed'

I figured that if there is no "Compressed Data Summary" section, then no table in the database is using compression.

None of the databases had a "Compressed Data Summary" section.  Ergo, I think that compression is well and truly unused in this instance.  When IBM tech support gets to this point, I will ask them to delete those phantom remnants of compression.

Makes me scratch my head and wonder why those rsccompdict fragments even exist, and why Informix doesn't provide me a way to clean up the mess.

DG

P.S.  I think it is possible that there could have been some attempt to experiment with compression, in the past.

Is there any way to know whether any tables in a database are currently using compression?

Thank you, Art.

I do have a tech support case open with IBM on this.  They are currently working on it.  I sort of expected that this would be a generally recognized situation on IBM's end.  But, apparently not.

DG

The rsccompdict table is an internal hidden table that contains compression dictionaries for compressed tables. It may be that sometime in the past a table or index was compressed or at least a dictionary was created to do so. 

If there are no currently compressed tables, I would open a PMR with IBM and get them to clear that table manually.

Art

Thank you, Andreas.

I checked things as you suggested.  I found that query "a" did not come back empty.  Bottom line, I observed the extent in 'oncheck -pe rootdbs'.

But, I can't DROP the table because there is no database in which the "table" resides.  I look at the tables and system catalog tables for every database in the instance, and there is no table "rsccompdict" present in any of them.

I wonder how this thing came into existence

Anyway, I thank you, and I forwarded all the info (queries/utilities and outputs from queries/utilities) to tech support.

I don't really know what else to do.  It just doesn't make sense to me.

Thank you.

DG

P.S.  There are three chunks in the rootdbs: the initial, and two that were added years ago, when the rootdbs was used for a whole ton of stuff.  I have since reorganized the storage in that instance, and no longer need any more than the initial chunk (which is about 10 times larger than what is now needed.)  So, that's why I'm trying to get rid of this garbage.  I want to DROP those two additional chunks, and use that space for something else.  But, I can't get rid of them if they aren't empty.  And, I am unable to make them empty.

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

Original Message:
Sent: Mon March 06, 2023 05:24 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

first check a) whether this really is empty and b) wheter it is the dbspace's compression dictionary partition:

a)

select * from sysmaster:syscompdicts;

-> should come back empty

b)

select hex(octptnm) from sysmaster:sysptnhdr where partnum = "0x100001";

if this returns a valid looking partnum, run

oncheck -pt <that_partnum>

and

oncheck -pe rootdbs

and see whether the extent in the chunk you want to get rid of is in this partition's extent list.

All this just to establish the facts - it still won't help you getting rid of this extent/partition/chunk and this functionality isn't implemented.
-> you'll have to ask tech support to do the right things to allow this chunk to be dropped.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Fri March 03, 2023 06:57 PM
From: David Grove
Subject: Phantom rsccompdict table

I put this aside for several months, but now it has come up again.

I don't really understand what happened.

I have a chunk (not the initial chunk) that is part of the rootdbs.  This chunk is empty-- except that, apparently, it isn't!

There are no database objects in it.  Except that Server Studio shows a single "table" named rsccompdict.  And, it shows it as belonging to database "rootdbs".

However, there is no database named rootdbs in this instance, so that doesn't even make sense.

We do not use compression, nor, to my knowledge have we ever.  Certainly, not at present.  Yet, there appears to be some artifact of compression.

The only option I get when right clicking on that row in Server Studio is "Show Object Properties".  When I click on it, I get an error message, "Unable to resolve object type for: rsccompdict.  Error: Database not found or no system permission."

I still want to DROP this chunk, but when I try, I get a -194 error (chunk not empty).  So, how do I get rid of this mystery object, or drop the chunk (which is what I really want)?  I have opened a tech support case, but just checking to see if I can get an answer faster.  It's been several days.  (In all fairness, I classified the problem as 3 [minor business iimpact], which it still is at the moment.)

Thank you for any thoughts.

DG

Here is how SS shows the contents of the chunk:

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

Original Message:
Sent: Wed September 07, 2022 06:42 AM
From: Andreas Legner
Subject: Phantom rsccompdict table

Hi David,

I know there's logic to prevent a dbspace from appearing non-empty because of only remaining rsccompdict partition, but on chunk level there's no way such rsccompdict extent could be made to go our of your way when trying to drop such chunk. And no, unfortunately there's no built-in way for getting rid of a dbspace's (empty) rsccompdict partition (or shrinking it).

One could possibly argue such partition should automatically be dropped or at least shrunk to its initial extent once empty, but that's not what we have right now.

BR,
 Andreas

------------------------------
Andreas Legner

Original Message:
Sent: Tue September 06, 2022 09:22 PM
From: David Grove
Subject: Phantom rsccompdict table

Informix 12.10FC14
Solaris 10  1/13

I am attempting to delete unused chunks from an Informix rootdbs.

One I would like to delete is almost empty.  I say "almost" because when I examine the objects in that chunk, I observe one table: rsccompdict.

I have looked at two sysmaster tables: syscompdicts_full and systabnames.

The table "syscompdicts_full" has 0 rows, and when I execute a SELECT * FROM syscompdicts" I get a -79701 error.

When i execute SELECT * FROM systabnames WHERE systabname = "rsccompdict", I get the following:
partnum      dbsname      owner      tabname       collate    dbsnum
1066473     rootdbs        informix    rsccompdict                    1

So far as I know, compression has never been used in the instance in which I am observing this.  Also, there is no database (nor has there ever been) named "rootdbs".  "rootdbs" is the root dbspace.

I really don't know what to make of this.  Any ideas on how I can get rid of this phantom table so i can delete the chunk?

Thank you.

DG

P.S. I'm ready to open a tech support case, but will wait until I get back from vacation in 10 days, so I can properly work with tech support.  In the mean time, figured it doesn't hurt to inquire here among the cogniscenti.  :)


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

#Informix