-- 使用了三个正确的子查询
select
  book_title
from
  book
where
  book_title not in (
                select
                distinct
                  book_title
                from
                  book,
                  sales
                where
                  book.book_key = sales.book_key
                and
                  quantity > 0);

Execution Plan
----------------------------------------------------------
0   SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=59)
1  0  FILTER
2  1   TABLE ACCESS (FULL) OF ''''BOOK'''' (Cost=1 Card=1 Bytes=59)
3  1   FILTER
4  3     NESTED LOOPS (Cost=6 Card=1 Bytes=82)
5  4       TABLE ACCESS (FULL) OF ''''SALES'''' (Cost=1 Card=5 Bytes=90)
6  4       TABLE ACCESS (BY INDEX ROWID) OF ''''BOOK'''' (Cost=1 Card=1)
7  6         INDEX (UNIQUE SCAN) OF ''''PK_BOOK'''' (UNIQUE)

我们看到，正确的SQL语句写法产生的执行计划是如此的不同。明智的开发人员知道如何去编写能够产生最好执行计划的SQL语句，明智的Oracle应用系统也会主动训练开发人员去编写最有效的SQL语句。

下面是一些帮助开发人员优化SQL语句的技巧：
1、 使用 autotrace 和 TKPROF 功能去分析SQL语句的执行计划；
2、 保证所有生产环境中的SQL语句都是在测试环境中经过优化的；
3、 制定一个性能优化的标准，而不是只要求开发人员编写出最快的SQL语句。根据这种标准，好的开发人员应该能够写出最有效的SQL语句。

●谨慎管理CBO统计数据
成功的Oracle系统会谨慎管理他们的CBO统计数据，以保证CBO在测试环境和生产环境中以同样的方式工作。一个聪明的DBA会在得到高质量的CBO统计数据以后，把这些统计数据移植到测试环境中，这样SQL语句的执行计划在测试环境和生产环境中就是一样的了。

对DBA来说，一个重要的工作就是收集和发布CBO统计数据，并随时保持一套当前运行环境的最精确的统计数据。在一些情况下，可能会有不止一套的优化统计数据。比如，对OLTP运行的最好的统计数据可能对数据仓库运行却不是最好的，在这种情况下，DBA就需要保持两套统计数据，并根据不同的运行条件导入系统。

可以使用 dbms_stats 包中的 export_system_stats 存储过程来完成CBO统计数据的导出。下面的例子中，我们把当前CBO统计数据导出到一张名叫 stats_table_oltp的表中。
dbms_stats.export_system_stats(‘stats_table_oltp’)

导出以后，我们就可以把这张表拷贝到别的实例中，当系统的运行模式改变以后，使用 dbms_stats 包中的 import_system_stats 存储过程来完成CBO统计数据的导入。
dbms_stats.import_system_stats(‘stats_table_oltp’)

●千万不要随便改动CBO参数的值
改动CBO相关参数的值是非常危险的，因为一个小小的改动可能就会对整个系统的执行性能带来极大的负面影响，只有在经过严格的系统测试以后才能改动这些参数的值。可能带来极大影响的参数值包括：optimizer_mode, optimizer_index_cost_adj, and optimizer_index_caching。而其他参数，比如 hash_area_size , sort_area_size，参数值的改变就不是那么危险了，可以在会话级进行改变以帮助CBO优化查询。

●保证静态的执行计划
成功的CBO应用会通过谨慎管理统计数据来锁定SQL执行计划，同时保证存储的优化计划的稳定性，或者在具体的SQL语句中加入一些细节上的提示。
记住：重新分析一个系统的统计数据，可能会导致成千上万的SQL语句改变其执行计划。许多Oracle应用系统要求所有的SQL语句在测试环境中经过验证，保证在功能上和生产环境是一致的。

2.4.4  CBO的思考
尽管我们已经对CBO的不少细节有了了解，但是由于随着Oracle新版本的不断推出，CBO变得越来越强大，同时也越来越复杂，我们仍然有许多关于CBO的知识需要学习。
下面是一些关于CBO调整的提纲性的建议，供准备进行CBO调整的DBA们思考。

●DBA可以提供一些Oracle参数的配置对CBO进行控制，但是只能在有限的环境下谨慎的改变这些参数；

●CBO依靠统计数据来产生SQL语句的优化的执行计划，可以通过 dbms_stats 包来分析、产生统计数据；

●DBA们的一项重要任务就是收集、管理CBO统计数据，这些数据可以被收集、存储，也可以在相关的实例中进行移植，以保证执行计划的连贯性。

●在没有使用 export_system_stats 存储过程导出原来的统计数据以前，重新对系统的统计数据进行分析是十分危险的，因为成千上万的SQL语句的执行计划将可能全部改变，而你却不能恢复原来的 SQL性能。只有在系统的数据发生巨大变化时，才可能需要对整个系统的统计数据进行重新分析。

本小节是关于CBO的一些技术讨论，原文来自 Donald K. Burleson 在OTN上的一篇文章，具体URL路径是：
http://otn.oracle.com/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.html

注：以上内容来源http://www.cnblogs.com/binary/archive/2005/04/02/131033.html 葛宏宾的专栏

上一页  [1] [2] [3] [4] [5] [6] [7]