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

解决方案

回答

每当数据"显着"变化时。

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

统计信息存储有关项目计数和相对频率的信息，这些信息使它可以"猜测"与给定条件匹配的行数。当它猜错了时，优化器可以选择一个次优的查询计划。

回答

我们正在使用哪个Oracle版本？检查指向Oracle 10的页面：

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

它说：

The recommended approach to gathering statistics is to allow Oracle to automatically gather the statistics. Oracle gathers statistics on all database objects automatically and maintains those statistics in a regularly-scheduled maintenance job.

回答

当我管理由Oracle支持的大型多用户计划系统时，我们的DBA每周进行一次收集统计信息的工作。同样，当我们推出可能影响统计数据或者受统计数据影响的重大更改时，我们将迫使该工作周期不足以赶上进度。

回答

确保在过时的统计信息导致查询计划发生意外更改的风险与陈旧的统计信息本身可能导致查询计划发生更改的风险之间取得平衡。

假设我们有一个错误数据库，其中包含一个表ISSUE和一个列CREATE_DATE，其中该列中的值或者多或者少地单调增加。现在，假定此列上有一个直方图，它告诉Oracle该列的值在2008年1月1日至2008年9月17日之间是均匀分布的。这使优化程序可以合理地估计行数。如果我们正在查找上周(即9月7日至13日)创建的所有问题，则将被退回。但是，如果继续使用该应用程序并且永远不会更新统计信息，则此直方图的准确性将越来越低。因此，优化器将期望随着时间的推移，对"上周创建的问题"的查询越来越少，并且最终可能导致Oracle不利地更改查询计划。

回答

在我的上一份工作中，我们每周进行一次统计。如果我没记错的话，我们将它们安排在星期四晚上，而星期五，DBA会非常小心地监视运行时间最长的查询，以防意外。 (之所以选择星期五，是因为它通常只是在代码发布之后，并且往往是一个交通繁忙的日子。)当他们看到一个糟糕的查询时，他们会找到一个更好的查询计划并保存该计划，这样就不会再意外更改。 (Oracle有工具可以自动为我们执行此操作，我们可以告诉它要优化的查询，并且可以。)

许多组织避免运行统计信息，因为担心错误的查询计划会突然弹出。但这通常意味着他们的查询计划随着时间的推移而变得越来越差。当他们运行统计信息时，他们会遇到许多问题。解决这些问题的争执证实了他们对运行统计数据的危险的担忧。但是，如果他们定期运行统计数据，按预期使用监控工具，并在出现问题时加以解决，那么他们的头痛将减少，并且不会一次遇到所有麻烦。

回答

对于数据仓库类型的系统，我们可以考虑完全不收集统计信息，而是依靠动态采样(将optimizer_dynamic_sampling设置为2级或者更高级别)。

回答

对于10g及更高版本的oracle，优化器需要对表和索引进行最新统计，以制定"良好"的执行计划决策。我们多久收集一次统计信息是一个棘手的问题。这取决于应用程序，架构，数据速率和业务实践。某些与旧版本的oracle向后兼容的第三方应用程序在新的优化程序中无法正常运行。这些应用程序要求表没有统计信息，以便数据库重新使用规则库执行计划。但平均而言，oracle建议在具有过时统计信息的表上收集统计信息。我们可以将表设置为监视表并检查其状态，并让它们分析是否/何时失效。通常这足够了，有时候还不够。它实际上取决于数据库。对于我的数据库，我们有一组OLTP表，它们需要每晚收集统计信息以保持性能。其他表每周分析一次。在大型dw数据库上，由于表太大而无法进行常规分析，因此我们会根据需要进行分析，而不会影响总体数据库负载和性能。因此正确的答案是，它取决于应用程序，数据更改和业务需求。