Oracle数据库统计信息应该多久运行一次？

Question

根据您的经验，Oracle数据库统计信息应该多久运行一次？ 我们的开发团队最近发现，在超过2个半月的时间里，我们的生产箱没有运行统计数据。 这对我来说听起来很长，但我不是DBA。

Answer 1

由于默认情况下会自动收集Oracle 11g统计信息。

安装Oracle数据库时预定义了两个Scheduler窗口：

• WEEKNIGHT_WINDOW从晚上10点开始，每周一到周五早上6点结束。
• WEEKEND_WINDOW涵盖周六和周日的整天。

上次收集统计数据时？

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;

Answer 2

每当数据“显着”变化时。

如果一个表从1行到200行，那是一个重大变化。 当一个表从100,000行变为150,000行时，这不是一个非常重要的变化。 当一个表从常见查询列X中的所有具有相同值的1000行到X列中具有几乎唯一值的1000行时，这是一个重大变化。

统计信息存储有关项目计数和相对频率的信息 - 这些信息可以“猜测”符合给定条件的行数。 当它猜错时，优化器可以选择一个非常不理想的查询计划。

Answer 3

在我上一份工作中，我们每周进行一次统计。 如果我没记错的话，我们会在星期四晚上安排它们，并且在星期五，DBA非常小心地监视运行时间最长的查询以查找任何意外情况。 （星期五被选中是因为它通常只是在代码发布之后，并且往往是一个相当低的流量日。）当他们看到一个错误的查询时，他们会找到一个更好的查询计划并保存它，以便它不会再次意外地改变。 （Oracle有自动为您执行此操作的工具，您告诉它要优化的查询，它确实如此。）

许多组织因为担心错误地突然出现查询计划而避免运行统计信息。 但这通常意味着他们的查询计划随着时间的推移变得越来越糟。 当他们运行统计数据时，他们会遇到许多问题。 由此产生的纠正这些问题的争论证实了他们对运行统计数据的危险性的担忧。 但是，如果他们定期运行统计数据，按照预期使用监控工具，并在问题出现时修复问题，那么他们就会有更少的麻烦，并且他们不会立即遇到这些问题。

Answer 4

您使用的是什么Oracle版本？ 查看此页面引用Oracle 10：

http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

它说：

收集统计信息的建议方法是允许Oracle自动收集统计信息。 Oracle自动收集有关所有数据库对象的统计信息，并在定期计划的维护作业中维护这些统计信息。

Answer 5

使用10g及更高版本的oracle，优化器需要有关表和索引的最新统计信息，以便做出“良好”的执行计划决策。 您收集统计信息的频率是一个棘手的问题。 这取决于您的应用程序，架构，数据速率和业务实践。 编写为与旧版本oracle向后兼容的某些第三方应用程序与新优化程序的性能不佳。 这些应用程序要求表没有统计信息，以便db返回到规则库执行计划。 但平均而言，oracle建议在具有陈旧统计数据的表上收集统计数据。 您可以将表设置为监视并检查其状态，并让它们分析是否/何时过时。 通常这是足够的，有时它不是。 这真的取决于你的数据库。 对于我的数据库，我们有一组OLTP表，需要每晚收集统计数据以保持性能。 其他表格每周分析一次。 在我们的大型dw数据库中，我们根据需要进行分析，因为这些表对于常规分析来说太大而不会影响整体数据库负载和性能。 所以正确的答案是，它取决于应用程序，数据变化和业务需求。

Answer 6

当我管理由Oracle支持的大型多用户计划系统时，我们的DBA每周都有一份收集统计数据的工作。 此外，当我们推出可能影响或受统计数据影响的重大变化时，我们会强制这项工作耗尽周期以使事情陷入困境。

Answer 7

确保平衡新鲜统计信息导致查询计划出现不良更改的风险与过时统计信息本身可能导致查询计划更改的风险。

想象一下，你有一个带有表ISSUE和列CREATE_DATE的bug数据库，其中列中的值或多或少地单调增加。 现在，假设此列上有一个直方图，告诉Oracle此列的值在2008年1月1日到2008年9月17日之间均匀分布。这使得优化器可以合理地估计出的行数。如果您正在寻找上周（即9月7日至13日）创建的所有问题，请退回。 但是，如果继续使用应用程序并且永远不会更新统计数据，则此直方图将越来越不准确。 因此，优化器将期望对“上周创建的问题”的查询随着时间的推移变得越来越不准确，并最终可能导致Oracle负面地更改查询计划。

Answer 8

通常不建议在整个数据库中如此频繁地收集统计信息，除非您有充分的理由，例如批量插入或数据库上经常发生大数据更改。 以这个频率收集数据库的统计数据可能会将查询执行计划更改为新的糟糕执行计划，这可能会花费您很多时间来尝试调整受新计划影响的每个查询，这就是为什么您应该测试收集的影响关于测试数据库的新统计数据，或者如果你没有时间或人力，至少你应该通过在收集新的静态数据之前备份原始静态数据来保留后备计划，所以如果你收集了一个新的统计信息然后查询没有按预期执行，您可以轻松还原原始统计信息。

有一个非常有用的脚本可以帮助您备份原始统计信息并收集新的统计信息，并为您提供SQL命令，您可以使用它来恢复原始静态，以防收集新统计信息后事物没有按预期运行。 您可以在以下链接中找到该脚本： http ： //dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html

Answer 9

对于数据仓库类型系统，您可以考虑根本不收集统计信息，并依赖于动态采样（将optimizer_dynamic_sampling设置为2级或更高级别）。