Delete Column Histograms to Improve SQL Plan Stability ↗

Carlos Sierra:

If you are on 10g, or if on 11g but ACS (Adaptive Cursor Sharing) is not an option, then deleting column Histograms may be your best option to improve your plan stability. Like any other change, you rather test first on a non-production environment. Even in such test environment, you may want to restrict your test to only those tables accessed by your SQL. On 11g, DBMS_STATS.DELETE_COLUMN_STATS provides an option to delete just the Histograms while preserving all other column statistics. This is by using parameter COL_STAT_TYPE with value HISTOGRAM. If you want to do the same on 10g, you may want to use the SQLT HGRM module. In any case you can always restore column statistics using DBMS_STATS.RESTORE_TABLE_STATS.

Carlos gives us a tip on how to disable the use of Histograms with a hidden parameter:

If you are considering deleting Histograms to test the effect on an execution plan and the performance of your SQL, you may want to test first asking the CBO to simply ignore them. If patch for bug 9550277 has been applied in your system then you can command below.
ALTER SESSION SET “_FIX_CONTROL”=’9550277:1′;

Worth noting that Jonathan Lewis was very successful in tuning a customer’s query by simply deleting histograms:

The most critical piece of advice I had given them was to get rid of ALL the histograms they had on their system, and then watch very carefully for any signs that they might need to re-introduce a handful of histograms over the next few weeks. One of their critical queries completed in less that 2 seconds when histograms were removed, but took 33 seconds to complete when histograms were in place.