这个特性减少了由于sql语句统计失效或陈旧而导致性能很差的可能性,通过提高查询优化器的最佳的输出提高sql执行的性能.
gather_stats_job
默认的,在数据库创建的时候就创建了gather_stats_job,执行dbms_stats.gather_database_stats_job_proc过程,使用schedular.
默认的定义了两个窗口.
weekenight_window定义在下午10点到上午六点.从周一到周五.
weekend_window定义从上午12点到周一12点.
调用DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC收集统计信息。
该过程首先检测统计信息缺失和陈旧的对象。然后确定优先级，再开始进行统计信息。
说明：当做完统计信息后，如果对对象的行数修改达到10%，DBMS_STATS就认为是统计信息过旧。
可以通过以下查询这个JOB的运行情况：
SQL> select * from Dba_Scheduler_Jobs where JOB_NAME ='GATHER_STATS_JOB'
其实同在10点运行的Job还有一个AUTO_SPACE_ADVISOR_JOB：
SQL> select JOB_NAME,LAST_START_DATE from dba_scheduler_jobs;
JOB_NAME LAST_START_DATE
------------------- ----------------------------------------
AUTO_SPACE_ADVISOR_JOB 04-DEC-07 10.00.00.692269 PM +08:00
GATHER_STATS_JOB 04-DEC-07 10.00.00.701152 PM +08:00
FGR$AUTOPURGE_JOB
PURGE_LOG 05-DEC-07 03.00.00.169059 AM PRC
默认的maintenance_window_group组包含这两个窗口.
gather_stats_job使用特定的计划任务叫auto_tasks_job_class.这个类是自动创建的,而且跟特定的资源组联系,这个组叫做auto_task_consumer_group.这样确保任务使用auto_task_consumer_group.如果想控制gather_stats_job的资源使用,之需要为maintenance_window_group定义一个资源管理者组来为auto_task_cousumer_group分配资源.
为了让gather_stats_job工作正常,必须确定statistics_level初始化参数设置为typical.
改变gather_stats_job的计划任务
可以为定义的管理窗口来自定义开放时间.例如,可以改变他们的时间间隔和重复的频度.也可以添加资源计划到这些窗口中,来控制gather_stats_job使用的资源.
从db control主页,点击管理标签,然后在scheduler部分点击windows链接.就让到了scheduler windows页.这里可以选中一个窗口,并且可以点edit来修改它的特性.在这页,还可以打开或关闭特定的窗口.只要在下拉框为特定的窗口选择相应的行为,点ok.
锁定统计
阻止自动收集
主要用在可变的表中
-没有统计的锁定,意味着动态的取样.
-锁定代表值的统计
在oracle10g,可以看到特定表的统计,通过新的dbms_stats包的lock_table_stats过程.可以锁定一个表的统计,来阻止自动统计收集,这样就可以使用动态的取样.也可以在某个时间点锁定可变的表的统计.
可以使用lock_schema_stats运行在sechma基本锁定统计.
可以查看user/all/dba_tab_statistics视图来看stattype_locked列来看一个表是不是被锁定.
然而这个自动化功能已经影响了很多系统的正常运行，晚上10点对于大部分生产系统也并非空闲时段。
而自动分析可能导致极为严重的闩锁竞争，进而可能导致数据库Hang或者Crash。
所以建议最好关闭这个自动统计信息收集功能：
exec DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
自动化永远而严重的隐患相伴随！
对于易变对象的变化，可以人工收集统计信息(DBMS_STATS)外 主要两种处理方式：
一种就是删除统计信息。使它的统计信息为空，对于任何统计信息缺失的表,oracle会用动态取样特性自动产生统计信息。如果使用久的统计信息 就可能产生错误的执行计划。
需要设置optimizer_dynamic_sampling为2（ORACLE10G默认值）或以上都可以启动此特性。
optimizer_dynamic_sampling ,提供在SQL分析的时候，自动根据不同的Level（0-10）以不同的准确度分析SQL中未被analyze过的表，意在为CBO提供更多的统计信 息。在Oracle9iR2中引入，默认为Level 1，10g默认为2 。
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch1135.htm#REFRN10140
Level 0: Do not dynamically sample the table(s)
Level 1：Sample tables that have not been analyzed if there is more than one table in the query,the table in question has not been analyzed and it has no indexes,and the optimizer determines that the query plan would be affected based on the size of this objects
Level 2:Sample all unanalyzed tables referenced in the query using default sampling amounts(small sample)
Level 3 -- Level 10 ........更详细的sample。
例如：dbms_stats.delete_table_stats('table_name' ,'VOLATILE_TABLE')
另一种就是设置为表进行锁定,这样就可以不更新统计信息（注意LOCK表以后，表就不能修改了）。
dbms_stats.lock_table_stats('table_name' ,'VOLATILE_TABLE')；
http://hi.baidu.com/dbatao/blog/item/f3effdae2791cccb7dd92a4a.html
Metalink 上的解释：
Subject: How to check what automatic statistics collection is scheduled on 10g
Doc ID: Note:377143.1 Type: BULLETIN
Last Revision Date: 16-FEB-2007 Status: PUBLISHED
This article is being delivered in Draft form. and may contain errors.
Please use the MetaLink "Feedback" button to advise Oracle of any issues related to this article.
PURPOSE
This Note provides information on the How to check what automatic statistics collection is scheduled on 10g
{
SCOPE AND APPLICATION
ME;S+a [4M289604Users collecting statistics on database objects for use by the Cost Based Optimizer (CBO)
How to check what automatic statistics collection is scheduled on 10g
With Oracle 10g, the gathering of statistics has become automated.
The GATHER_STATS_JOB that is built in the database creation process schedules automatic statistics collection.
The job initiates a 'program' of statistics gathering appropriate for the database in question.
j289604The job details can be viewed by querying the DBA_SCHEDULER_JOBS view:
select job_name, job_type, program_name, schedule_name, job_class
from dba_scheduler_jobs
where job_name = 'GATHER_STATS_JOB';
JOB_NAME JOB_TYPE PROGRAM_NAME SCHEDULE_NAME JOB_CLASS
------------------------------ ---------------- ------------------- ------------------------- ------------------------------
GATHER_STATS_JOB GATHER_STATS_PROG MAINTENANCE_WINDOW_GROUP AUTO_TASKS_JOB_CLASS
The output shows that the 'GATHER_STATS_JOB' schedules a program 'GATHER_STATS_PROG' in the 'MAINTENANCE_WINDOW_GROUP' time schedule.
The PROGRAM_NAME 'GATHER_STATS_PROG' starts the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC stored procedure: select PROGRAM_ACTION
from dba_scheduler_programs
where PROGRAM_NAME = 'GATHER_STATS_PROG';
PROGRAM_ACTION
dbms_stats.gather_database_stats_job_proc
The job is scheduled according to the value of the SCHEDULE_NAME field.
this example, the schedule being used is: 'MAINTENANCE_WINDOW_GROUP'.
This schedule is defined in the DBA_SCHEDULER_WINGROUP_MEMBERS view:
select *
from DBA_SCHEDULER_WINGROUP_MEMBERS
where WINDOW_GROUP_NAME = 'MAINTENANCE_WINDOW_GROUP';
WINDOW_GROUP_NAME WINDOW_NAME
------------------------- ------------------------------
MAINTENANCE_WINDOW_GROUP WEEKNIGHT_WINDOW MAINTENANCE_WINDOW_GROUP WEEKEND_WINDOW
The meaning of these 'windows' can be found in 'DBA_SCHEDULER_WINDOWS':
select window_name, repeat_interval, duration
from dba_scheduler_windows
where window_name in ('WEEKNIGHT_WINDOW', 'WEEKEND_WINDOW')
WINDOW_NAME REPEAT_INTERVAL DURATION
----------------- ------------------------------------------------------------- ------------- WEEKNIGHT_WINDOW freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0 +000 08:00:00
WEEKEND_WINDOW freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0 +002 00:00:00
The meaning of these entries is as follows
The WEEKNIGHT_WINDOW is scheduled each week day at 10PM. and should last a maximum of 8 hours.
The WEEKEND_WINDOW is scheduled each Saturday at 0AM and should last 2 days max
If the START_DATE and END_DATE columns (Not shown) are NULL, then this job will run continuously.
All these definitions can be found in the $ORACLE_HOME/rdbms/admin/catmwin.sql script.
Oracle 10g 版本最后不再支持（而不是反对）基于规则的优化器 (RBO)。因为 CBO 依靠准确的（或者说比较准确的）统计信息来产生优化的执行路径，所以 DBA 需要确保定期收集统计信息，创建另一个执行核对清单。在 10g 之前，这一过程可能由于多种原因而徒劳无功。在 10g 中已经消除了很多这类的顾虑，它能够自动收集统计信息。在 Oracle9i 中，您可以通过打开表监视选项 (ALTER TABLE ...MONITORING) 然后检查这些表的视图 DBA_TAB_MODIFICATIONS，检查表中的数据是否已明显更改过。
在 10g 中，已不再使用 MONITORING 语句了。而通过设置初始化参数 STATISTIC_LEVEL 为 TYPICAL 或 ALL，就可以自动收集统计信息。（默认值为 TYPICAL，因此可以随即启用自动收集统计信息的功能。）Oracle 数据库 10g 具有一个预定义的调度程序作业，名称为 GATHER_STATS_JOB，它由 STATISTIC_LEVEL 参数的适当数值所激活。
SQL> show parameter statistics_
NAME TYPE VALUE
------------------------------------ ----------- -----------------
statistics_level string TYPICAL
statistics_level 默认是typical，在10g中表监控是激活的，强烈建议在10g中此参数的值是typical。如果STATISTICS_LEVEL设置为basic，不仅不能监控表，而且将禁掉如下一些10g的新功能：
ASH(Active Session History)
ASSM(Automatic Shared Memory Management)
AWR(Automatic Workload Repository)
ADDM(Automatic Database Diagnostic Monitor)
统计信息的收集是资源相当密集的工作，因此您可能希望确保它不影响数据库的正常操作。在 10g 中，您可以使这一工作自动完成：可对一个名为 AUTO_TASK_CONSUMER_GROUP 的特定资源用户组进行预定义，用于自动执行一些任务，比如收集统计信息。该用户组确保这些统计信息收集作业的优先权低于默认用户组，因此减少或消除了自动化任务占用整个机器的风险。
这个自动任务默认情况下在工作日晚上10:00 - 6:00 和周末全天开启。调用 DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC 收集统计信息。该过程首先检测统计信息缺失和陈旧的对象。然后确定优先级，再开始进行统计信息。
可以通过以下查询这个JOB的运行情况：
SQL> set lines 256
SQL> col last_start_date format a40
SQL> col last_run_duration format a30
SQL> SELECT owner, enabled, auto_drop, restartable, state, run_count, failure_count, last_start_date, last_run_duration FROM dba_scheduler_jobs where job_name = 'GATHER_STATS_JOB';
OWNER ENABL AUTO_ RESTA STATE RUN_COUNT FAILURE_COUNT LAST_START_DATE LAST_RUN_DURATION
------------------------------ ----- ----- ----- --------------- ---------- ------------- ---------------------------------------- ------------------------------
SYS TRUE FALSE TRUE SCHEDULED 57 0 27-NOV-08 10.00.02.228110 PM +08:00 +000000000 00:00:25.870394
如果希望将参数 STATISTIC_LEVEL 设为 TYPICAL 却不希望自动收集统计信息时该怎么办？很简单。只需使用以下语句来禁用调度程序作业即可：
SQL> exec DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
那么您为什么要这样做呢？有很多原因 — 其中一个原因是，虽然表中大部分行发生了变化，但分布情况可能没有改变，这在数据仓库中很常见。在这种情况下，您不希望再次收集统计信息，而只是希望重用原来的统计信息。另一个原因可能是您正在使用分区交换功能来刷新物化视图 (MV)，并且不希望收集关于物化视图的统计信息，因为关于被交换表的统计信息也会被导入。但是，您也可以将特定的表排除在自动统计信息收集作业之外，而不需要禁止整个作业。
在优化器收集统计信息时可能出现的复杂情况之一是执行计划的改变 — 也就是说，原来的优化方法在收集统计信息之前一直工作良好，但是在此之后，由于新收集的统计信息产生了不良计划，导致查询突然出错。这种问题并不少见。
为避免这种灾难，统计信息的收集作业在收集新信息之前保存当前的统计信息。如果出现问题，您总可以返回到原有的统计信息，或者至少可以检查二者之间的不同之处，以便于解决问题。
例如，假设在 5 月 31 日晚上 10:00 开始运行表 REVENUE 上的统计信息收集作业，而随后查询的性能变差。Oracle 保存了原有的统计信息，您可以通过执行以下命令重新获取这些信息：
SQL> exec dbms_stats.restore_table_stats ( 'ARUP', 'REVENUE', '31-MAY-04 10.00.00.000000000 PM -04:00');
此命令恢复到 5 月 31 日晚上 10:00 为止的统计信息,时间信息是以 TIMESTAMP 数据类型提供。这样您就立即还原了由新的统计信息收集程序所作的更改。
您能够恢复的时间长度是由保留参数所决定的。要查看当前的保留参数，可使用以下查询：
SQL> select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual;
GET_STATS_HISTORY_RETENTION
---------------------------
31
在本示例中表示可以保存相当于 31 天的统计信息，但并不能予以保证。要了解统计信息所覆盖到的确切时间和日期，只需使用以下查询：
SQL> select DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY from dual;
GET_STATS_HISTORY_AVAILABILITY
----------------------------------------------------------------
27-10月-08 11.14.20.357622000 下午 +08:00
该查询表明可用的最陈旧统计信息日期为 10 月 27 日下午 11:14。
您可以通过执行内建的函数将保留时间设为不同的值。例如，要将其设为 45 天，可使用：
SQL> exec DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (45);
另外为什么有部分表没有被分析呢, 原因跟表DBA_TAB_MODIFICATIONS有关.
Oracle? Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-01
14.3.1.5 Determining Stale Statistics
Statistics must be regularly gathered on database objects as those database objects are modified over time. In order to determine whether or not a given database object needs new database statistics, Oracle provides a table monitoring facility. This monitoring is enabled by default when STATISTICS_LEVEL is set to TYPICAL or ALL. Monitoring tracks the approximate number of INSERTs, UPDATEs, and DELETEs for that table, as well as whether the table has been truncated, since the last time statistics were gathered. The information about changes of tables can be viewed in the USER_TAB_MODIFICATIONS view. Following a data-modification, there may be a few minutes delay while Oracle propagates the information to this view. Use the DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO procedure to immediately reflect the outstanding monitored information kept in the memory.
The GATHER_DATABASE_STATS or GATHER_SCHEMA_STATS procedures gather new statistics for tables with stale statistics when the OPTIONS parameter is set to GATHER STALE or GATHER AUTO. If a monitored table has been modified more than 10%, then these statistics are considered stale and gathered again.
默认情况下Oracle会记录数据库表的变化, 只有变化超过10%的表,才会做自动分析
来源：http://blog.chinaunix.net/uid-116213-id-3086069.html
