Kevin Kempf's Blog

July 27, 2009

Pulling the plug on 11i Advanced Data Compression

Filed under: 11g, advanced compression, Bugs, Dataguard — kkempf @ 10:49 am

This past weekend I uncompressed all my tables, rebuilt the associated indexes, and said adieu to Advanced Compression. Based on my (still open) Dataguard block corruption SR, the admin at work likes to call it Advanced Data Corruption. Regardless, I may have lived with the first issue as a beta tester, but after a second ORA-0600 related to the product cropped up last week, I gave up. When support admits that they have no documentation of the error internally, and begins suggesting the most inane course of action you can come up with, it’s time to give it the boot. It is my opinion that while this product works in the simplest environment, on the whole it is half-baked, not well tested, and not worth being a “guinea pig” or “production beta tester” for it.

Incidentally, the syntax to uncompress (and move, recreating the object completely uncompressed) is:

alter table BOM.MTL_MATERIAL_TRANSACTIONS move nocompress;

I have to say I really wanted this product to work. In principle, it’s a great idea, and in practice, it seems close to achieving what I would say was success:

  • Disk sat idle most of the day because everything was in the buffer cache
  • Most objects compressed extremely well, and total disk consumption fell significantly
  • With the exception of Dataguard (and the unknown OLTP ora-0600), it operated seamlessly with the apps

In the end, however, I’d tell anyone considering it to wait.  It’s not there yet.

*edit* Dataguard has been up and running just fine, for over 2 weeks now since I uncompressed all the database objects. Oracle development must be very close to what they think is a fix, based on my SR/bug. But I’m not putting compression back in anytime soon.

Create a free website or blog at