作者介紹：
蓋國強，曾任ITPUB MS 版版主，現任Oracle 數據庫管理版版主。曾任職於某國家大
型企業，服務於菸草行業，開發過基於Oracle 數據庫的大型ERP 系統，屬國家信息產業部
重點工程。同時負責Oracle 數據庫管理及優化，併爲多家菸草企業提供Oracle 數據庫管理、
優化及技術支持。目前任職於北京某電信增值業務系統提供商企業，負責數據庫業務。管
理全國30 多個省點數據庫平臺。實踐經驗豐富，長於數據庫診斷、優化與SQL 調整。希
望與大家共同學習提高Oracle 技術水平。
Mail: [email protected]
以下是一次SQL 優化分析的全過程，曾經在itpub 上發過相關的帖子，現在整理了一
下，添加了詳細的說明，希望對大家有些幫助。
環境說明:
數據庫版本:Oracle8.1.7.4
平臺:Hp-Ux11i
以下是從程序員處獲得的一段代碼，開發人員抱怨這段代碼執行緩慢，我執行該段代碼
獲得執行計劃，分析如下：
這是該段代碼的執行計劃及統計數據：
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
8 rows selected.
Elapsed: 00: 00: 00.51
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 NESTED LOOPS
2 1 NESTED LOOPS
3 2 TABLE ACCESS (FULL) OF 'SP_TRANS'
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB'
5 4 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE)
6 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM'
7 6 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
4 db block gets
323 consistent gets
0 physical reads
0 redo size
1809 bytes sent via SQL*Net to client
425 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
該段代碼用以按供貨商查詢2003 年開始的處理單據（當時的數據量很少），查詢時間大
約是0.51 秒。
此前這幾個表都沒有分析過，數據庫選擇的是RBO 優化器。
爲了加快代碼的執行，analyze 相關表：
SQL> analyze table sp_trans_sub compute statistics;
Table analyzed.
Elapsed: 00: 00: 30.64
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
8 rows selected.
Elapsed: 00: 00: 06.49
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=18577 Card=126726520
Bytes=30034185240)
1 0 MERGE JOIN (Cost=18577 Card=126726520 Bytes=30034185240)
2 1 SORT (JOIN) (Cost=14722 Card=310300 Bytes=20790100)
3 2 HASH JOIN (Cost=358 Card=310300 Bytes=20790100)
4 3 TABLE ACCESS (FULL) OF 'SP_TRANS' (Cost=43 Card=229 Bytes=8473)
5 3 TABLE ACCESS (FULL) OF 'SP_TRANS_SUB' (Cost=158 Card =135502 Bytes=4065060)
6 1 SORT (JOIN) (Cost=3855 Card=40840 Bytes=6942800)
7 6 TABLE ACCESS (FULL) OF 'SP_ITEM' (Cost=77 Card=40840 Bytes=6942800)
Statistics
----------------------------------------------------------
150 recursive calls
89 db block gets
1837 consistent gets
755 physical reads
60 redo size
1732 bytes sent via SQL*Net to client
425 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
1 sorts (disk)
8 rows processed
SQL>
SQL> analyze table sp_trans compute statistics;
Table analyzed.
Elapsed: 00: 00: 13.00
SQL>
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
8 rows selected.
Elapsed: 00: 00: 01.62
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1453 Card=447198 Bytes=101066748)
1 0 NESTED LOOPS (Cost=1453 Card=447198 Bytes=101066748)
2 1 HASH JOIN (Cost=358 Card=1095 Bytes=61320)
3 2 TABLE ACCESS (FULL) OF 'SP_TRANS' (Cost=43 Card=273 Bytes=7098)
4 2 TABLE ACCESS (FULL) OF 'SP_TRANS_SUB' (Cost=158 Card=135502 Bytes=4065060)
5 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM' (Cost=1 Card= 40840 Bytes=6942800)
6 5 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
8 db block gets
1344 consistent gets
0 physical reads
0 redo size
1824 bytes sent via SQL*Net to client
425 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
SQL> analyze table sp_item compute statistics
2 /
Table analyzed.
Elapsed: 00: 00: 11.67
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
8 rows selected.
Elapsed: 00: 00: 01.43
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=687 Card=1362 Bytes=128028)
1 0 HASH JOIN (Cost=687 Card=1362 Bytes=128028)
2 1 HASH JOIN (Cost=358 Card=1362 Bytes=76272)
3 2 TABLE ACCESS (FULL) OF 'SP_TRANS' (Cost=43 Card=273 Bytes=7098)
4 2 TABLE ACCESS (FULL) OF 'SP_TRANS_SUB' (Cost=158 Card=135502 Bytes=4065060)
5 1 TABLE ACCESS (FULL) OF 'SP_ITEM' (Cost=77 Card=29547 Bytes=1122786)
Statistics
----------------------------------------------------------
0 recursive calls
12 db block gets
1820 consistent gets
0 physical reads
0 redo size
1732 bytes sent via SQL*Net to client
425 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
8 rows processed
當分析了所有表以後，我們發現，最後Oracle 給我選擇了三個全表掃描。而且，從db
block gets 、consistent gets 全都“提高”了。
然後我在VENDOR_CODE 列上建了一個索引，試圖通過索引加快代碼的執行(在實際應用
中，通過添加適當的索引來加快SQL 執行是常用的方法，尤其是在RBO 模式下，但是添加索
引可能改變很多相關SQL 的執行計劃，是否獲得確切的性能提高，需要進行相應的測試來驗
證，Oracle9i 提供索引監視的功能，你可以通過ALTER INDEX .. MONITORING USAGE 語句
來收集索引的使用信息,以確認索引是否被正常使用):
SQL> create index idx_vendor on sp_trans(vendor_code);
索引已創建。
已用時間: 00: 00: 02.03
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
已選擇8 行。
已用時間: 00: 00: 01.42
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=646 Card=1362 Bytes= 128028)
1 0 HASH JOIN (Cost=646 Card=1362 Bytes=128028)
2 1 HASH JOIN (Cost=317 Card=1362 Bytes=76272)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS' (Cost=2 Card=273 Bytes=7098)
4 3 INDEX (RANGE SCAN) OF 'IDX_VENDOR' (NON-UNIQUE) (Cost=1 Card=273)
5 2 TABLE ACCESS (FULL) OF 'SP_TRANS_SUB' (Cost=158 Card=135502 Bytes=4065060)
6 1 TABLE ACCESS (FULL) OF 'SP_ITEM' (Cost=77 Card=29547 Bytes=1122786)
Statistics
----------------------------------------------------------
0 recursive calls
8 db block gets
1546 consistent gets
1 physical reads
0 redo size
1732 bytes sent via SQL*Net to client
425 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
現在數據庫使用了這個索引，執行計劃稍好了一點，可是效果仍然不讓人滿意。
然後我刪後來創建的索引，添加Rule 提示，這是我們得到了最初的執行計劃
SQL> SELECT /*+ rule */ "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
已選擇8 行。
已用時間: 00: 00: 00.71
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE
1 0 NESTED LOOPS
2 1 NESTED LOOPS
3 2 TABLE ACCESS (FULL) OF 'SP_TRANS'
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB'
5 4 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE)
6 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM'
7 6 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
4 db block gets
323 consistent gets
0 physical reads
0 redo size
1809 bytes sent via SQL*Net to client
426 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
然後我們再次創建這個索引，得出的時間大大縮短(爲存在性能問題的數據庫查詢添加
必要的索引，是DBA 解決問題的重要手段之一):
SQL> create index idx_vendor on sp_trans(vendor_code);
索引已創建。
已用時間: 00: 00: 02.43
SQL> SELECT /*+ rule */ "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_ITEM",
14 "SP_TRANS_SUB",
15 "SP_TRANS"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
已選擇8 行。
已用時間: 00: 00: 00.31
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=HINT: RULE
1 0 NESTED LOOPS
2 1 NESTED LOOPS
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS'
4 3 INDEX (RANGE SCAN) OF 'IDX_VENDOR' (NON-UNIQUE)
5 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB'
6 5 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE)
7 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM'
8 7 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
49 consistent gets
1 physical reads
0 redo size
1809 bytes sent via SQL*Net to client
426 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
然而這不是最快的，這是RBO
我們修改optimizer_index_cost_adj 這個初始化參數，然後再來查看該SQL 的執行計
劃。
SQL> alter session set optimizer_index_cost_adj=30
2 /
會話已更改。
已用時間: 00: 00: 00.20
SQL> SELECT "SP_TRANS"."TRANS_NO",
2 "SP_TRANS_SUB"."ITEM_CODE",
3 "SP_ITEM"."ITEM_NAME",
4 "SP_ITEM"."CHART_ID",
5 "SP_ITEM"."SPECIFICATION",
6 "SP_TRANS_SUB"."COUNTRY",
7 "SP_TRANS_SUB"."QTY",
8 "SP_TRANS_SUB"."PRICE",
9 "SP_TRANS"."VENDOR_CODE",
10 "SP_TRANS"."PAY_MODE",
11 NVL("SP_TRANS_SUB"."PAY_QTY",0),
12 0 as PAY_THIS
13 FROM "SP_TRANS",
14 "SP_ITEM",
15 "SP_TRANS_SUB"
16 WHERE ( "SP_TRANS_SUB"."TRANS_NO" = "SP_TRANS"."TRANS_NO" ) and
17 ( "SP_ITEM"."ITEM_CODE" = "SP_TRANS_SUB"."ITEM_CODE" ) and
18 ( ( "SP_TRANS"."VENDOR_CODE" = '20011021023') )
19 /
已選擇8 行。
已用時間: 00: 00: 00.11
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=658 Card=1095 Bytes= 102930)
1 0 NESTED LOOPS (Cost=658 Card=1095 Bytes=102930)
2 1 NESTED LOOPS (Cost=329 Card=1095 Bytes=61320)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS' (Cost=1 Card=273 Bytes=7098)
4 3 INDEX (RANGE SCAN) OF 'IDX_VENDOR' (NON-UNIQUE) (Cost=1 Card=273)
5 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB' (Cost= 2 Card=135502
Bytes=4065060)
6 5 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE) (Cost=3 Card=135502)
7 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM' (Cost=1 Card=29547 Bytes=1122786)
8 7 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
49 consistent gets
0 physical reads
0 redo size
1809 bytes sent via SQL*Net to client
426 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
我們來看看以下兩個參數對於CBO 的巨大影響：
OPTIMIZER_INDEX_CACHING
這個初始化參數代表一個百分比,取值範圍在0 到99 之間.
缺省值是0，代表當CBO 使用索引訪問數據時，在內存中發現數據的比率是0%，這
意味着通過索引訪問數據將需要產生物理讀取，代價昂貴。如果使用缺省設置，Oracle
評估成本的時候，很多時候就會錯誤的選擇全表掃描。
OPTIMIZER_INDEX_COST_ADJ
這個初始化參數代表一個百分比,取值範圍在1 到10000 之間.
該參數表示索引掃描和全表掃描成本的表較。缺省值100 表示索引掃描成本等於全
表掃描。
這些參數對於CBO 的執行具有重大影響，其缺省值對於數據庫來說通常需要調整。
一般來說對於OPTIMIZER_INDEX_CACHING 可以設置爲90 左右
對於大多數OLTP 系統，OPTIMIZER_INDEX_COST_ADJ 可以設置在10 到50 之間。對於數
據倉庫和DSS 系統，可能不能簡單的把OPTIMIZER_INDEX_COST_ADJ 設置爲50，通常我
們需要反覆調整取得一個合理值.
SQL> drop index idx_vendor;
索引已丟棄。
已用時間: 00: 00: 00.61
SQL> /
已選擇8 行。
已用時間: 00: 00: 00.11
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=700 Card=1095 Bytes= 102930)
1 0 NESTED LOOPS (Cost=700 Card=1095 Bytes=102930)
2 1 NESTED LOOPS (Cost=371 Card=1095 Bytes=61320)
3 2 TABLE ACCESS (FULL) OF 'SP_TRANS' (Cost=43 Card=273 Bytes=7098)
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'SP_TRANS_SUB' (Cost= 2 Card=135502
Bytes=4065060)
5 4 INDEX (RANGE SCAN) OF 'PK_SP_TRANS_SUB' (UNIQUE) (Cost=3 Card=135502)
6 1 TABLE ACCESS (BY INDEX ROWID) OF 'SP_ITEM' (Cost=1 Card= 29547 Bytes=1122786)
7 6 INDEX (UNIQUE SCAN) OF 'PK_SP_ITEM' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
4 db block gets
323 consistent gets
0 physical reads
0 redo size
1809 bytes sent via SQL*Net to client
426 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
相關文檔：
以下文檔都是相當好的閱讀材料，有興趣的可以仔細閱讀：
關於optimizer_index_cost_adj 等影響CBO 的參數及設置：
http://www.evdbt.com/SearchIntelligenceCBO.doc
關於成本的計算等，請參考以下文章：
http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%201
0053%20Event.pdf
http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%201
0053%20Event.ppt
關於CBO,請參考以下文檔：
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database
_id=NOT&p_id=35934.1
http://www.itpub.net/showthread.php?threadid=88905
關於執行計劃的設置，請參考：
http://osi.oracle.com/~tkyte/article1/autotrace.html
