我正在比较查询我的开发和生产数据库。
它们都是Oracle 9i，但几乎每个查询都有完全不同的执行计划，具体取决于数据库。
所有表/索引都相同，但dev数据库大约是每个表的1/10行。
在生产中，它为大多数查询选择的查询执行计划与开发不同，并且成本高出1000倍。在某些情况下，对生产的查询似乎也没有使用正确的查询索引（全表访问）。
我最近在两个数据库上都运行了dbms_utility.analyze架构，希望CBO可以解决这个问题。
是否有其他潜在的oracle配置可能导致此问题？
我主要是开发人员，所以这种DBA分析起初相当混乱......
答案 0 :(得分：5)
1）我要检查的第一件事是数据库参数是否与Prod和Dev相同。如果影响基于成本的优化程序决策的参数之一不同，则所有投注均已关闭。您可以在v $ parameter view中看到参数;
2）拥有最新的对象统计数据很棒，但请记住你指出的巨大差异--Dev有10％的Prod行。此行计数是CBO如何决定执行查询的最佳方式的因素。考虑到行数的巨大差异，我不希望计划是相同的。
根据具体情况，优化程序可以选择全表扫描具有20,000行（Dev）的表，在该表中可以确定索引在具有200,000行（Prod）的表上的成本较低。 （数字仅用于演示，CBO使用成本算法来确定FTS的内容和索引扫描的内容，而不是绝对值）。
3）系统统计也会影响到解释计划。这是一组表示CPU和磁盘I / O特征的统计信息。如果两个系统上的硬件不同，那么我希望您的系统统计信息不同，这会影响计划。 Jonathan Lewis的一些很好的讨论here 您可以通过sys.aux_stats $视图查看系统统计信息。
现在我不确定为什么不同的计划对你来说是件坏事...如果统计数据是最新的并且参数设置正确你应该从任何一个系统获得不错的表现，无论大小有什么不同......
但可以从Prod系统导出统计数据并将其加载到您的Dev系统中。这使您的Prod统计数据可用于您的Dev数据库。
检查Oracle文档中的DBMS_STATS包，特别是EXPORT_SCHEMA_STATS，EXPORT_SYSTEM_STATS，IMPORT_SCHEMA_STATS，IMPORT_SYSTEM_STATS过程。请记住，您可能需要在10g / 11g上禁用10pm夜间统计作业...或者您可以在导入后调查锁定统计信息，以便夜间作业不会更新它们。