Deleting .rsccompdict from dbspace

Hello Everybody Because of reorg some Tables, we are doing some Tests with compression, and after filling a compressed 100G table I was not able to drop the dbspace which holds only the Table right after droping the compressed table. "oncheck -pe" lists some remaining .rsccompdict Parts on the dbspace. Is it possible to delete these dictionarys after dropping a compressed table / index? Is there a special way to drop a compressed Table from a dbspace together with the dictionary? The Table was CREATED with the compressed flag and was not compressed online. There was only that one Table fragmented in 20 Partions in this dbspace. Thank you in advance for your time and responces.

Check sysmaster:syscompdicts_fullto check all dictionaries from the dbspace have been dropped. Then use the following to purge the inactive compression dictionries: https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/i ds_sapi_083.htm Regards, David. > On 15 January 2018 at 09:38 ANDREAS WEIS <aweis@arz-emmendingen.de> wrote: > > > Hello Everybody > > Because of reorg some Tables, we are doing some Tests with compression, and > after filling a compressed 100G table I was not able to drop the dbspace which > holds only the Table right after droping the compressed table. > > "oncheck -pe" lists some remaining .rsccompdict Parts on the dbspace. Is it > possible to delete these dictionarys after dropping a compressed table / > index? Is there a special way to drop a compressed Table from a dbspace > together with the dictionary? > > The Table was CREATED with the compressed flag and was not compressed online. > There was only that one Table fragmented in 20 Partions in this dbspace. > > Thank you in advance for your time and responces. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hello David Thank You for your quick responce. There are some Entrys for the dbspace in dict_dbsnum. Is it okay to delete that rows, and then try purging them from the dbspace? Because of the Table not longer exists, which name for the Table should be used? I think this happened because of I dropped the Table as my own DBSA User and not Informix. Do you also think that this could be the reason? Gr33tZ Andy

Hello, I would not delete from a system table. The only option I can see is using the purge option with no table to purge all inactive compression dictionaries. You might be able to check the ph_tasks table in the sysadmin database to see what this task actually does. Regards, David. On 15 January 2018 at 13:09 ANDREAS WEIS <aweis@arz-emmendingen.de> wrote: Hello David Thank You for your quick responce. There are some Entrys for the dbspace in dict_dbsnum. Is it okay to delete that rows, and then try purging them from the dbspace? Because of the Table not longer exists, which name for the Table should be used? I think this happened because of I dropped the Table as my own DBSA User and not Informix. Do you also think that this could be the reason? Gr33tZ Andy ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hello David Thank you for your answer. Sadly I have no success with the Purge Command. The .rsccompdict files will remain in any case. I have tried both funtions "compression purge_dictionary" and "table purge_dictionary". I have also tried to recreate the Table and then purge the dictionary files. Any other Ideas how to solve this? Thank you in Advance.

Hi Andreas, I would open a support case at this point. Regards, David. > On 17 January 2018 at 08:34 ANDREAS WEIS <aweis@arz-emmendingen.de> wrote: > > > Hello David > > Thank you for your answer. > > Sadly I have no success with the Purge Command. The .rsccompdict files will > remain in any case. > > I have tried both funtions "compression purge_dictionary" and "table > purge_dictionary". I have also tried to recreate the Table and then purge the > dictionary files. > > Any other Ideas how to solve this? > > Thank you in Advance. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi, if you have a solution i am interesting. I had a lot of compressed databases/tables and rsccompdict is a big table. All compressed databases are now dropped. The partnum is in sysmaster:systabnames, so it is possible to do some admin operations with it. echo "select * from systabnames where tabname='rsccompdict'"|dbaccess sysmaster Database selected. partnum 5330540 dbsname datadbs_4 owner informix tabname rsccompdict collate dbsnum 5 I successed to purge_dictionary, but it just deleted all the rows. I successed to defragment rsccompdict. But it is actually always a big one. Not possible to shrink because it is forbidden on this table. Not possible to drop with a partnum. Using IDS 12.10FC7W1 on AIX 6.1 Below the result of oncheck, there are now 0 rows but the space used is 3327115 pages. CFRSV50251001DB<informix></informix>oncheck -pt 5330540 TBLspace Report for Unknown:Unknown.51566c ISAM error: no record found. Physical Address 7:18355187 Creation date 02/10/2016 13:25:35 TBLspace Flags c02 Row Locking TBLspace contains TBLspace BLOBs TBLspace use 4 bit bit-maps Maximum row size 92 Number of special columns 1 Number of keys 2 Number of extents 1 Current serial value 1 Current SERIAL8 value 1 Current BIGSERIAL value 1 Current REFID value 1 Pagesize (k) 4 First extent size 8 Next extent size 524288 Number of pages allocated 3327115 Number of pages used 3327115 Number of data pages 0 Number of rows 0 Partition partnum 5330540 Partition lockid 5330540 Extents Logical Page Physical Page Size Physical Pages 0 7:3173128 3327115 3327115 Regards

Hello, Andreas. I just faced the same situation. Found a technote about it, pretty old (2014), but it worked for me. Just dropped the whole dbspace instead of the chunk, and it worked. http://www-01.ibm.com/support/docview.wss?uid=swg21155564 The only concern you must check if you only have the rscompdicts table in your whole dbspace. If so, you can drop it (as I did). HTH Regards.

Hello together As you all write I have contacted the Informix Support, and they confirmed that "Our Problem" is a bug, which is treated as defect and will be fixed in the next Informix Release. I´ll try to explain where the matter is... The Problem occurs when the first Table which should be compressed in a DBSPACE is a AUTO COMPRESSED PARTITIONED TABLE. After initial filling the Table, you are not able to delete the .rsscompdict, and so it is not possible to drop the DBSPACE. The Support told us, that reinitialize (!!) is the only chance to solve this. But the Support told us also, that there is a much bigger Problem, when running into that special Bug... After server restart it could happen that other Compression Dictionaries (not related with this Table) are no longer accesable, and so also of course the Data is lost. We have not faced that Problem IBM mentioned, so I cannot say more about it. IBM also told us a workaround which is pretty simple. Just compress a single existing Table in the DBSPACE BEFORE creating a AUTO COMPRESSED PARTITIONED TABLE in the DBSPACE will protect you of this defect. But i would not count on it on a Live System, so we have decided to wait until we start to compress Tables at least until this bug is fixed. Andy Weis

Ok my friend, your case is much more complex than mine, of course. Could you please share your defect id, so that we can track it? Thanks a lot. Best regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 / v12.10 IBM Informix on Cloud - Database Administrator - 2017 IBM dashDB Managed Service for Analytics and Transactions - 2017 DB2 Advanced DBA - v10.5 for LUW IBM Information Management Informix Technical Professional IBM Certified Developer - Informix Genero Informix independent consultant ________________________________ De: ids-bounces@iiug.org <ids-bounces@iiug.org> em nome de ANDY W. <aweis@arz-emmendingen.de> Enviado: segunda-feira, 19 de março de 2018 06:53 Para: ids@iiug.org Assunto: Re: Deleting .rsccompdict from dbspace [40874] Hello together As you all write I have contacted the Informix Support, and they confirmed that "Our Problem" is a bug, which is treated as defect and will be fixed in the next Informix Release. I´ll try to explain where the matter is... The Problem occurs when the first Table which should be compressed in a DBSPACE is a AUTO COMPRESSED PARTITIONED TABLE. After initial filling the Table, you are not able to delete the .rsscompdict, and so it is not possible to drop the DBSPACE. The Support told us, that reinitialize (!!) is the only chance to solve this. But the Support told us also, that there is a much bigger Problem, when running into that special Bug... After server restart it could happen that other Compression Dictionaries (not related with this Table) are no longer accesable, and so also of course the Data is lost. We have not faced that Problem IBM mentioned, so I cannot say more about it. IBM also told us a workaround which is pretty simple. Just compress a single existing Table in the DBSPACE BEFORE creating a AUTO COMPRESSED PARTITIONED TABLE in the DBSPACE will protect you of this defect. But i would not count on it on a Live System, so we have decided to wait until we start to compress Tables at least until this bug is fixed. Andy Weis ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hello Alexandre Unfortunately I do not have the DEFECT ID. But I try to find it out for you, and post it as soon as I got it :)

Ok. You can ask for IBM support and they will send you, just in case. Thanks a lot. Best regards.