Auto stats gathering is not sufficient - what now?

From: TJ Kiernan <tkiernan_at_pti-nps.com>
Date: Wed, 9 Feb 2011 13:50:07 -0600
Message-ID: <0EC85B1F3B2DF8409BF66DC182F495D9858C08_at_DEEDS.pti-nps.com>



10.2.0.3 on 32-bit Windows 2003 R2

I have a reporting table that is too large to grow by 10% very often - 66 million records growing by 250k per week = 24 weeks before stats go stale and are gathered, meanwhile queries against relatively recent data
(last month, last quarter) get horrible execution plans unless we hint
them. For instance, from the example below, we have an index on
(GROUP_KEY, DATE_PROCESSED) that would return this query in <1 second.
 

If my predicate values were in range of the statistics, then I expect to get better plans, so the first thing I'm considering is a periodic job
(probably weekly) to gather stats on this table.
 

My question: What sorts of considerations should I make when setting up a non-standard stats gathering job? Particularly METHOD_OPT, but with other parameters as well, what prompts you to step away from defaults?  

PLAN_TABLE_OUTPUT



SQL_ID 0udsqttt83syw, child number 0


  SELECT /*+ gather_plan_statistics */

         field1,

         field2,

         DATE_PROCESSED     FROM REPORTING_TABLE    WHERE GROUP_KEY = 1234      AND DATE_PROCESSED > to_date('25-DEC-2010', 'DD-MON-YYYY')

ORDER BY GROUP_KEY, DATE_PROCESSED   Plan hash value: 3444608443  



| Id  | Operation                   | Name              | Starts |
E-Rows | A-Rows | A-Time | Buffers | Reads |

|*  1 |  TABLE ACCESS BY INDEX ROWID| REPORTING_TABLE   |      1 |
1 |     28 |00:00:05.84 |     617K|    148K|

|*  2 |   INDEX RANGE SCAN          | RT_DATE_IDX       |      1 |
2 | 1599K|00:00:28.81 | 6065 | 5828 |

 

Predicate Information (identified by operation id):


 

   1 - filter("GROUP_KEY"=1234)

   2 - access("DATE_PROCESSED">TO_DATE('2010-12-25 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))

       filter("DATE_PROCESSED">TO_DATE('2010-12-25 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))  

****10053 trace*****

  Access Path: index (RangeScan)

    Index: RT_DATE_IDX

    resc_io: 4.00 resc_cpu: 31027

    ix_sel: 2.4406e-008 ix_sel_with_filters: 2.4406e-008

    Cost: 4.01 Resp: 4.01 Degree: 1

  Using prorated density: 2.4406e-008 of col #2 as selectivity of out-of-range value pred

  Using prorated density: 2.4406e-008 of col #2 as selectivity of out-of-range value pred

  Access Path: index (RangeScan)

    Index: RT_GROUP_DP_IDX

    resc_io: 5.00 resc_cpu: 36837

    ix_sel: 3.9615e-010 ix_sel_with_filters: 3.9615e-010

    Cost: 5.01 Resp: 5.01 Degree: 1

  Using prorated density: 2.4406e-008 of col #2 as selectivity of out-of-range value pred  

T. J. Kiernan

Database Administrator

Pharmaceutical Technologies, Inc.

(402) 965-8800 ext 1039

tkiernan_at_pti-nps.com    

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 09 2011 - 13:50:07 CST

Original text of this message