在你的经验中,Oracle数据库统计信息应该运行多久一次?我们的开发团队最近发现,在我们的生产环境中,统计信息已经超过2个半月没有更新了。对我来说听起来很长,但我不是DBA。
在你的经验中,Oracle数据库统计信息应该运行多久一次?我们的开发团队最近发现,在我们的生产环境中,统计信息已经超过2个半月没有更新了。对我来说听起来很长,但我不是DBA。
自 Oracle 11g 起,默认情况下会自动收集统计信息。
在安装 Oracle 数据库时,预定义了两个调度程序窗口:
最后一次收集统计信息是什么时候?
SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.
自动收集统计信息的状态如何?
SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';
Windows组?
SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;
窗口计划?
SELECT window_name, start_time, duration FROM dba_autotask_schedule;
手动收集此模式中的数据库统计信息:
EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.
手动收集所有模式下的数据库统计信息!
-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;
每当数据发生“显著”变化时。
如果一张表从1行变成200行,那就是一个显著的变化。当一张表从100,000行变成150,000行时,并不算是非常显著的变化。当一个表从1000行中常见查询列X的值相同,变成1000行中几乎唯一的列X值时,那就是一个显著的变化。
统计信息存储有关项目数量和相对频率的信息,这些信息可以让它“猜测”有多少行将符合给定条件。当它猜错时,优化器可能会选择一个非常次优的查询计划。
收集统计信息的推荐方法是允许Oracle自动收集统计信息。Oracle会自动收集所有数据库对象的统计信息,并在定期维护作业中维护这些统计信息。
我曾经管理过一个由Oracle支持的大型多用户规划系统,我们的DBA每周都会有一个任务来收集统计信息。此外,当我们推出可能会影响或受到统计数据影响的重大更改时,我们会强制运行该任务以使事情赶上。
在oracle的10g及更高版本中,优化器需要最新的表和索引统计信息来做出“好”的执行计划决策。收集统计信息的频率是一个棘手的问题。这取决于您的应用程序、模式、数据速率和业务实践。一些为与旧版oracle向后兼容而编写的第三方应用程序在使用新的优化器时表现不佳。这些应用程序要求表没有统计信息,以便数据库返回基于规则的执行计划。但通常情况下,Oracle建议对具有过期统计信息的表进行统计信息收集。您可以将表设置为监视并检查它们的状态,并在过期时分析它们。通常这就足够了,但有时候不够。这真的取决于您的数据库。对于我的数据库,我们有一组OLTP表需要每晚收集统计信息以维护性能。其他表每周分析一次。对于我们的大型DW数据库,我们根据需要进行分析,因为这些表太大了,无法定期分析,否则会影响整个数据库的负载和性能。所以正确的答案是,这取决于应用程序、数据变化和业务需求。
要平衡新鲜统计数据可能导致查询计划不良变化的风险与陈旧统计数据本身可能导致查询计划变化的风险。
假设您有一个带有ISSUE表和CREATE_DATE列的错误数据库,其中列中的值逐渐单调增加。现在,假设该列上有一个直方图,告诉Oracle该列的值在2008年1月1日至2008年9月17日期间均匀分布。这使优化器可以合理地估计如果您正在查找上周创建的所有问题(即9月7日至13日),将返回多少行。但是,如果应用程序继续使用且未更新统计信息,则此直方图将越来越不准确。因此,优化器会预期随着时间的推移,“上周创建的问题”的查询将变得越来越不准确,并最终可能导致Oracle对查询计划进行负面更改。