2

我正在比较查询我的开发和生产数据库。

它们都是 Oracle 9i,但几乎每个查询都有完全不同的执行计划,具体取决于数据库。

所有表/索引都是相同的,但 dev 数据库中每个表的行数大约为 1/10。

在生产环境中,它为大多数查询选择的查询执行计划与开发环境不同,而且成本有时会高出 1000 倍。在某些情况下,生产中的查询似乎也没有使用正确的索引进行查询(全表访问)。

我最近也在这两个数据库上运行了 dbms_utility.analyze 模式,希望 CBO 能解决一些问题。

是否有其他一些潜在的 oracle 配置可能导致这种情况?

我主要是一名开发人员,所以这种 DBA 分析起初相当混乱。

4

1 回答 1

5

1) 我要检查的第一件事是数据库参数在 Prod 和 Dev 之间是否相同。如果影响基于成本的优化器决策的参数之一不同,则所有赌注都将取消。您可以在 v$parameter 视图中看到参数;

2)拥有最新的对象统计信息很棒,但请记住您指出的巨大差异 - Dev 拥有 10% 的 Prod 行。此行数被考虑到 CBO 如何决定执行查询的最佳方式。鉴于行数的巨大差异,我不希望计划是相同的。

根据具体情况,优化器可能会选择对具有 20,000 行 (Dev) 的表进行全表扫描,它可能会决定索引在具有 200,000 行 (Prod) 的表上的成本较低。(数字仅用于演示,CBO 使用成本计算算法来确定 FTS 和索引扫描的内容,而不是绝对值)。

3) 系统统计数据也纳入解释计划。这是一组代表 CPU 和磁盘 i/o 特征的统计数据。如果您在两个系统上的硬件不同,那么我希望您的系统统计信息会有所不同,这可能会影响计划。来自 Jonathan Lewis 的一些很好的讨论在这里 您可以通过 sys.aux_stats$ 视图查看系统统计信息。

现在我不确定为什么不同的计划对你来说是一件坏事......如果统计数据是最新的并且参数设置正确,那么无论大小差异如何,你都应该从任一系统获得不错的性能......

但是可以从您的 Prod 系统中导出统计数据并将它们加载到您的 Dev 系统中。这使您的 Prod 统计信息可用于您的开发数据库。

检查 DBMS_STATS 包的 Oracle 文档,特别是 EXPORT_SCHEMA_STATS、EXPORT_SYSTEM_STATS、IMPORT_SCHEMA_STATS、IMPORT_SYSTEM_STATS 过程。请记住,您可能需要在 10g/11g 上禁用晚上 10 点的夜间统计作业......或者您可以在导入后调查锁定统计信息,以便它们不会被夜间作业更新。

于 2010-04-21T17:49:14.937 回答