IDS V11.50FC6 and Compression

Hi All, I am just looking at the possibility of using IDS compression. I just wanted to know if anyone has experience with this and what your feelings are. Also i have a table that has 800+ million rows, so far it has taken about 10 hours and it is still not finished... I expect it would be quicker to unload the table, set compression on and reload, but will have to test this as well. The main issue i am facing is that compressing a table is very very log intensive, our TSM server can not keep up with the logs being filled. For now i have turned this off and the logs backup to /dev/null, but for obvious reasons this can not be done in a production environment. Has anyone encountered this and if so did you manage to get around it. Any information around this would be really appreciated.

Rick, I have experienced the compress in IDS 11.50.FC4 like yours 740 million rows (row size 196 bytes) it has taken 11:20 hours to finish. The compress is I/o Intensive and the engine updates all rows of your table generating lots of logical logs. I really discourage you to disable the logical log, because probably your database is doing other activities as well. The repack will take more time, if you run the repack online it will take 3 to 10 times longer and will lock the table and the related tables linked by foreign keys. And if those tables are intensively used the compress can be aborted. If you have maintenance window, you should drop the indexes, primary keys and foreign keys and run the repack offline. Best regards, Celso Cabral Coimbra Administrador de Banco de Dados ClearTech Ltda "Trust at the heart of Communications" Tel. (11) 3576-4509 -----Mensagem original----- De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Em nome de RICK HILL Enviada em: quinta-feira, 11 de março de 2010 04:59 Para: ids@iiug.org Assunto: IDS V11.50FC6 and Compression [19310] Hi All, I am just looking at the possibility of using IDS compression. I just wanted to know if anyone has experience with this and what your feelings are. Also i have a table that has 800+ million rows, so far it has taken about 10 hours and it is still not finished... I expect it would be quicker to unload the table, set compression on and reload, but will have to test this as well. The main issue i am facing is that compressing a table is very very log intensive, our TSM server can not keep up with the logs being filled. For now i have turned this off and the logs backup to /dev/null, but for obvious reasons this can not be done in a production environment. Has anyone encountered this and if so did you manage to get around it. Any information around this would be really appreciated. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.