我正在比较查询我的开发和生产数据库。
它们都是 Oracle 9i，但几乎每个查询都有完全不同的执行计划，具体取决于数据库。
所有表/索引都是相同的，但 dev 数据库中每个表的行数大约为 1/10。
在生产环境中，它为大多数查询选择的查询执行计划与开发环境不同，而且成本有时会高出 1000 倍。在某些情况下，生产中的查询似乎也没有使用正确的索引进行查询（全表访问）。
我最近也在这两个数据库上运行了 dbms_utility.analyze 模式，希望 CBO 能解决一些问题。
是否有其他一些潜在的 oracle 配置可能导致这种情况？
我主要是一名开发人员，所以这种 DBA 分析起初相当混乱。
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 点的夜间统计作业......或者您可以在导入后调查锁定统计信息，以便它们不会被夜间作业更新。