建议在10g收集优化器统计
适用于:
Oracle服务器-标准版-版本:10.1.0.2到10.1.0.2-发行:10.1至10.1
Oracle服务器-企业版-版本:10.1.0.2到10.1.0.2[发行:10.1 - 10.1];
目标:
本文件概述建议的方法,收集成本的优化器在Oracle 10g中使用的优化器统计的一套标准。
解决方案:
快速重新创建的建议:
为了实现快速删除并重新对单个表的统计和它的索引(添加任何倾斜列的统计信息),在这篇文章中使用的建议:
exec dbms_stats.delete_table_stats(ownname=>’user_name’,-
tabname=>’table_name’,cascade_indexes=>true);
exec dbms_stats.gather_table_stats(ownname=>’user_name’,-
tabname=>’table_name’,-
estimate_percent=>100,-
cascade=>true,-
method_opt=>’for all columns size skewonly’);
对于这些建议的说明,见下文。如需使用范例,请参阅本文结尾。
请注意,从10gR2的统计数据可以恢复使用:
注:452011.1*10G起恢复表的统计信息
重要信息:请注意:
这些建议适用于大多数的数据库。
这些建议旨在生成统计时尽可能地统计准确性。为此,提出了100%的样本大小样本量的减少,是因为总是让步的准确性。这是公认的,如100%的样本是潜在的耗时和需要做出考虑,以适应现有的维护窗口内的统计信息收集活动。
新的优化器统计信息的收集应保持或改善现有的执行计划,但它可能使某些查询的性能降低。注意以前的副本在默认情况下从10gR1统计时,保存过去30天的信息,可以在出现问题的时候恢复。见:
注:452011.1*10G起恢复表的统计信息
收集新的优化器统计也许无效在共享池中的游标,所以在数据库中它是审慎限制所有收集作业执行的低活动期,如定期维护窗口。
对于非常大的系统,统计信息的收集可以是一个非常耗时和资源密集的活动。在这种环境下,样本量需要严格加以控制,以确保收集完成在可接受的时间表和资源约束的养护的窗口。对于这一主题的指导下见:
注:44961.1统计数据收集频率和战略指导方针
在这些环境中,它还建议利用变化统计信息收集,以避免不必要的重复收集。请参见:
注:237901.1自动收集图解或数据库统计-范例
注:377152.1在Oracle 10g中自动统计收藏的最优方法
收集对象统计:
基于成本的优化器(CBO)使用统计信息来确定一个特定的查询执行计划。潜在的,抽样与样本量减少,可以产生不同的机会分组数据的统计,可能是不同的加载方法等造成的结果。
在10g,建议:
使用定期统计收集脚本收集统计。在大多数情况下,默认的脚本提供适当水平的抽样考虑以下建议:
使用足够大的样本大小。10g建议支持估计样本大小的100%(如果它在适应维护窗口内是可能的),即使这意味着在统计数据上降低频率。如果100%是不可行的,请尝试使用至少30%的估计。一般来说,统计数据的准确性远远超过大多数应用程序中的每一天的更改。这样设置是因为默认的AUTO_SAMPLE_SIZE使用了一个非常小的估计百分比,这可能会导致贫困的估计。
确保所有对象(表和索引)的统计收集。实现这一目标的一个简单方法是使用级联参数。
确保任何柱倾斜的数据分布有直方图收集起来,并有足够的分辨率使用METHOD_OPT参数。支持建议保守和更稳定的计划,“添加一个直方图只有当它是已知的需要”,而不是收集所有列的列统计直方图的方法。这样就可以实现手动或通过使用SKEWONLY选项自动添加列的统计信息,包含了非均匀分布的数据列。使用默认的列统计自动设置,这意味着使用DBMS_STATS将决定哪些列添加直方图,它认为它们可能有助于产生一个更好的计划。如果统计数字不完全是最新的,那么在场的直方图可能会引起麻烦时,解析值超出范围或为“频率”直方图之间的值。在这些情况下,优化器必须做出的猜测可能是不准确的,有时,会导致贫困的计划。
请注意在早期版本的METHOD_OPT参数的默认设置是“为所有列的大小1”,这将收集只有高和低价值和有效的意思,也没有详细的列统计信息。众所周知,在某些情况下,一个直方图的效果不利于一个更好的计划,因此移动在版本之间的用户最初可能希望将此参数设置为预升级版本价值,后来调整到升级后释放的默认值。见:
注:465787.1在升级到10g或11g管理CBO的统计信息
一如既往,测试与应用程序的不同的价值观会产生最好的结果。
如果使用分区,收集全球统计数据,有可能存在时间限制。全球的统计是非常重要的,但聚会往往避免由于涉及的大小和时间长短所必需。如果100%的样本是不可能的那么支持将推荐为至少1%。收集小样本大小(如0.001,0.0001,0.00001等),可以是非常有效的,但同样大的比例,数据不会被审查,这可能证明是决定性优化的计划选择。请注意,可用范围为ESTIMATE_PERCENT的参数可利用的范围是非常灵活的[0.000001->100],哪些可能为巨大的分区表可以使用适当小的样本大小。每个系统的测试将显示最合适的设置。
见:
注:236935.1全球统计-说明
收集系统的统计数据,以反映系统CPU负载和提高提供了CPU成本估计除了正常的I/O成本估计在CBO的估计的准确性。参见:
注:470316.1使用实际系统的统计(收集CPU和IO信息)
注:149560.1收集和显示系统统计(CPU和IO)为CBO使用
注:153761.1缩放系统,以提高CBO优化
注意,默认为收集不同版本的甲骨文不一定相同,例如:
ESTIMATE_PERCENT:默认值:
9i:100%
10g:DBMS_STATS.AUTO_SAMPLE_SIZE(使用非常小的比例估计)
11g:DBMS_STATS.AUTO_SAMPLE_SIZE(使用较大的估计百分比-100%)
METHOD_OPT:默认值:
9i:“所有列的大小1”有效没有详细列的统计信息。
10g和11g:“所有列的大小自动”-此设置意味着使用DBMS_STATS决定哪些列添加直方图,它认为,它们可能有助于产生一个更好的计划。
在11g中,使用100%ESTIMATE_PERCENT的默认值自动调整大小,因此,尽可能准确。此外,即使是100%的样本收集,收集过程也是非常快的,因为它是用一个新的哈希算法来计算,而不是统计排序(9g和10g的“慢”的一部分,是典型的排序)。在10g中的默认ESTIMATE_PERCENT样本大小是非常小的,这往往导致贫困统计,因此不建议使用。
样本统计量的采集命令
统计信息收集个人表
exec dbms_stats.gather_table_stats(-
ownname=>’Schema_name’,-
tabname=>’Table_name’,-
estimate_percent=>100,-
cascade=>TRUE,-
method_opt=>’FOR ALL COLUMNS SIZE 1’);
注意:架构名称取代的‘SCHEMA_NAME’和‘TABLE_NAME’和表分别收集统计。
聚集在一个模式的所有对象的统计信息
exec dbms_stats.gather_schema_stats(-
ownname=>’Schema_name’,-
cascade=>TRUE,-
method_opt=>’FOR ALL COLUMNS SIZE 1’);
注意:所需的架构的名称取代‘SCHEMA_NAME’。
收集在数据库中所有对象的统计:
exec dbms_stats.gather_database_stats(-
cascade=>TRUE,-
method_opt=>’FOR ALL COLUMNS SIZE 1’);
注意:
对于被称为列数据被扭曲和被称为是有益的列统计的情况下,替换:
method_opt=>’FOR ALL COLUMNS SIZE 1’
同
method_opt=>’FOR ALL COLUMNS SIZE AUTO’
或
method_opt=>’FOR ALL COLUMNS SIZE SKEWONLY’
自动添加列的统计信息,包含了非均匀分布的数据列。