{ "date": "2016-12-07T10:48:55", "slug": "oracle-12cr2-statistics-advisor", "link": "https://www.dbi-services.com/blog/oracle-12cr2-statistics-advisor/", "title": { "rendered": "Oracle 12cR2: Statistics Advisor" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nToday at #ukoug_tech16 12:30 in hall 11A I’ll talk about Statistics Gathering Best Practice & 12cR2 Statistics Advisor
\nRather than taking the Optimizer Statistics Advisor rules one by one I’ll show the things to take care (some people may call it best practices) when gathering statistics and they mention the Statistics Advisor Rule.
\nIf you need a reference about all rules, you can get it from V$STATS_ADVISOR_RULES
\n

\n
09:41:19 SQL> select to_char(rule_id,99)||' '||description||' ('||name||')' from V$STATS_ADVISOR_RULES where rule_id>0 order by rule_id;\n&nbsp\nTO_CHAR(RULE_ID,99)||''||DESCRIPTION||'('||NAME||')'\n----------------------------------------------------------------------------------------------------
\n

I’ll explain them briefly here.

\n

You should always enable to automatic statistic gathering job. You may manage special cases manually, but do not disable it.

\n
  1 Use Auto Job for Statistics Collection (UseAutoJob)
\n

For sure if the job does not complete successfully, the advisor detects the probable cause.

\n
  2 Auto Statistics Gather Job should complete successfully (CompleteAutoJob)
\n

Statistics history may save your life in case of a regression. But be sure the retention is not too large and purge occurs or SYSAUX will grow

\n
  3 Maintain Statistics History (MaintainStatsHistory)
\n

The faster the statistics gathering run, the more statistics you can gather. Use all your server resources for it.

\n
  4 Use Concurrent preference for Statistics Collection (UseConcurrent)
\n

Default options for global preferences are what the optimizer developers think are the best for most cases.

\n
  5 Use Default Preference for Stats Collection (UseDefaultPreference)
\n

Humm.. this one was introduced before the decision not to activate SPD by default
\n(see http://dbi-services.com/blog/oracle-12cr2-optimizer-adaptive-statistics/)

\n
  6 SQL Plan Directives should not be disabled (TurnOnSQLPlanDirective)
\n

Setting statistics manually may be used as a workaround but not the general case

\n
  7 Avoid Set Statistics Procedures (AvoidSetProcedures)
\n

When you run dbms_stats.gather_…_stats manually, default options are what the optimizer developers think are the best for most cases.

\n
  8 Use Default Parameters in Statistics Collection Procedures (UseDefaultParams)
\n

And in those cases, better to run it for a schema so that you are sure to include newly created tables

\n
  9 Use gather_schema_stats procedure (UseGatherSchemaStats)
\n

You waste time and ressources if you gather statistics in a addition to what is done with online statistics gathering

\n
 10 Avoid inefficient statistics operation sequences (AvoidInefficientStatsOprSeq)
\n

You waste time and ressources if you gather statistics when nothing has changed

\n
 11 Avoid unnecessary statistics collection (AvoidUnnecessaryStatsCollection)
\n

You need statistics for all tables

\n
 12 Avoid objects with stale or no statistics (AvoidStaleStats)
\n

Statistics gathered before bulk inserts will be immediately stale

\n
 13 Do not gather statistics right before bulk DML (GatherStatsAfterBulkDML)
\n

You don’t want the automatic statistics gathering run on a table between a truncate and an insert

\n
 14 Statistics for objects with volatile data should be locked (LockVolatileTable)
\n

But let it run for tables with no massive change

\n
 15 Statistics for objects with non-volatile should not be locked (UnlockNonVolatileTable)\n 16 Statistics of dependent objects should be consistent (MaintainStatsConsistency)
\n

Better truncate, make indexes unusable, and insert /*+ append */ than drop and recreate the table (which removes statistics).

\n
 17 Avoid drop and recreate object seqauences (AvoidDropRecreate)
\n

Statistics advisor may detect when incremental statistics gathering is me efficient for partitioned tables

\n
 18 Statistics should be maintained incrementally when it is beneficial (UseIncremental)\n 19 Statistics should not be maintained incrementally when it is not beneficial (NotUseIncremental)
\n

Stale statistics may lead to under-estimation because of linear decay

\n
 20 Avoid Out of Range Histogram endpoints (AvoidOutOfRange)
\n

Large tables can be scanned in parallel, recommendation is default degree

\n
 21 Use Auto Degree for statistics collection (UseAutoDegree)
\n

As we have seen about global preferences, table preference should be default for most cases (rolling invalidation, auto sample size, auto histogram size)

\n
 22 Use Default Object Preference for statistics collection (UseDefaultObjectPreference)
\n

And for sure dbms_stats is the way to gather statistics for the optimizer. ANALYZE is deprecated for that since 91

\n
 23 Avoid using analyze table commands for statistics collection (AvoidAnalyzeTable)
\n

Those are only my interpretation. 12.2 is new (and cloud first) and I’ve not observed all those recommandations yet. But there are properly described by the advisor.
\nThis is the kind of output we can get:

\n
\n----------------------------------------------------------------------------------------------------\nGENERAL INFORMATION\n-------------------------------------------------------------------------------\n \n Task Name       : MY_TASK\n Execution Name  : EXEC_52\n Created         : 12-07-16 11:31:40\n Last Modified   : 12-07-16 11:32:37\n-------------------------------------------------------------------------------\nSUMMARY\n-------------------------------------------------------------------------------\n For execution EXEC_52 of task MY_TASK, the Statistics Advisor has 6\n finding(s). The findings are related to the following rules: USECONCURRENT,\n AVOIDSETPROCEDURES, USEDEFAULTPARAMS, USEGATHERSCHEMASTATS, AVOIDSTALESTATS,\n UNLOCKNONVOLATILETABLE. Please refer to the finding section for detailed\n information.\n-------------------------------------------------------------------------------\nFINDINGS\n-------------------------------------------------------------------------------\n Rule Name:         UseConcurrent\n Rule Description:  Use Concurrent preference for Statistics Collection\n Finding:  The CONCURRENT preference is not used.\n \n Recommendation:  Set the CONCURRENT preference.\n Example:\n dbms_stats.set_global_prefs('CONCURRENT', 'ALL');\n Rationale:  The system's condition satisfies the use of concurrent statistics\n             gathering. Using CONCURRENT increases the efficiency of statistics\n             gathering.\n----------------------------------------------------\n...\n
\n", "protected": false } }