Kevin Kempf's Blog

January 20, 2010

Advanced Compression, Take 2

Filed under: 11g, 11i, advanced compression, Oracle — kkempf @ 9:14 am

Throw Away Hours of Work

It’s been almost a year, and I have an SR open that long to prove it.  It’s been in “Waiting on Customer” status for quite some time now.  In fact, they tend to ping me every month or two, in hopes of  closing the ticket.  Fair play, I’d say, since I was waiting on Oracle for a fix for months while they officially acknowledged they even had a problem.  I continue to tell them that once I have a viable environment in which to test this problem and their fix, I will do so.

Turns out, the time has arrived.  We’ve finished regression testing database patch 8277580; this is what support told me to apply last August.  The real problem with testing this patch is twofold.  First, I don’t have the luxury ($) of a TEST environment which includes a physical standby database.  On top of that, making the actual corruption happen is problematic.  The table which was corrupted, every time, on the standby was  BOM.CST_ITEM_COST_DETAILS.  There simply isn’t enough traffic/volume of work going on in any but my non production environment, to cause the corruption to happen in anywhere but PROD.  If money were no object, perhaps I could use some kind of load simulator (Oracle’s or otherwise) to reproduce this failure, but realistically, how much money do I want to spend to implement this product?  So my solution is pretty simple.  Apply the patch on both sides (Primary/Standby) of my PROD system, and wait and see what happens to the standby.  Like clockwork, I always had alert log entries, followed by the database shutdown within 24 hours of compressing this table.  If I continue to get corruption, I don’t know what I’ll do, besides have a long, unpleasant talk with my sales rep.

Regardless, I hope to apply the patch during the next maintenance window in February, which means within a month I should have some solid results to report on this issue.


Blog at