Explain Plan
一． 檢視執行計劃的三種方法
1.1 設定autotrace
序號
命令
解釋
1
SET AUTOTRACE OFF
此為預設值，即關閉Autotrace
2
SET AUTOTRACE ON EXPLAIN
只顯示執行計劃
3
SET AUTOTRACE ON STATISTICS
只顯示執行的統計資訊
4
SET AUTOTRACE ON
包含2,3兩項內容
5
SET AUTOTRACE TRACEONLY
與ON相似，但不顯示語句的執行結果
SQL> set autotrace on
SQL> select * from dave;
ID NAME
---------- ----------
8 安慶
1 dave
2 bl
1 bl
2 dave
3 dba
4 sf-express
5 dmm
已選擇8行。
執行計劃
----------------------------------------------------------
Plan hash value: 3458767806
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
609 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
1.2 使用SQL
SQL>EXPLAIN PLAN FOR sql語句;
SQL>SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
示例：
SQL> EXPLAIN PLAN FOR SELECT * FROM DAVE;
已解釋。
SQL> SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
或者：
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3458767806
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
已選擇8行。
執行計劃
----------------------------------------------------------
Plan hash value: 2137789089
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
統計資訊
----------------------------------------------------------
25 recursive calls
12 db block gets
168 consistent gets
0 physical reads
0 redo size
974 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
1.3 使用Toad,PL/SQL Developer工具
二． Cardinality（基數）/ rows
Cardinality值表示CBO預期從一個行源（row source）返回的記錄數，這個行源可能是一個表，一個索引，也可能是一個子查詢。 在Oracle 9i中的執行計劃中，Cardinality縮寫成Card。 在10g中，Card值被rows替換。
這是9i的一個執行計劃，我們可以看到關鍵字Card：
執行計劃
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=402)
1 0 TABLE ACCESS (FULL) OF 'TBILLLOG8' (Cost=2 Card=1 Bytes=402)
Oracle 10g的執行計劃，關鍵字換成了rows：
執行計劃
----------------------------------------------------------
Plan hash value: 2137789089
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Cardinality的值對於CBO做出正確的執行計劃來說至關重要。 如果CBO獲得的Cardinality值不夠準確（通常是沒有做分析或者分析資料過舊造成），在執行計劃成本計算上就會出現偏差，從而導致CBO錯誤的制定出執行計劃。
在多表關聯查詢或者SQL中有子查詢時，每個關聯表或子查詢的Cardinality的值對主查詢的影響都非常大，甚至可以說，CBO就是依賴於各個關聯表或者子查詢Cardinality值計算出最後的執行計劃。
對於多表查詢，CBO使用每個關聯表返回的行數（Cardinality）決定用什麼樣的訪問方式來做表關聯（如Nested loops Join 或 hash Join）。
多表連線的三種方式詳解 HASH JOIN MERGE JOIN NESTED LOOP
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5826546.aspx
對於子查詢，它的Cardinality將決定子查詢是使用索引還是使用全表掃描的方式訪問資料。
三． SQL 的執行計劃
生成SQL的執行計劃是Oracle在對SQL做硬解析時的一個非常重要的步驟，它制定出一個方案告訴Oracle在執行這條SQL時以什麼樣的方式訪問資料：索引還是全表掃描，是Hash Join還是Nested loops Join等。 比如說某條SQL通過使用索引的方式訪問資料是最節省資源的，結果CBO作出的執行計劃是全表掃描，那麼這條SQL的效能必然是比較差的。
Oracle SQL的硬解析和軟解析
http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5458896.aspx
示例：
SQL> SET AUTOTRACE TRACEONLY; -- 只顯示執行計劃，不顯示結果集
SQL> select * from scott.emp a,scott.emp b where a.empno=b.mgr;
已選擇13行。
執行計劃
----------------------------------------------------------
Plan hash value: 992080948
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 13 | 988 | 6 (17)| 00:00:01 |
| 1 | MERGE JOIN | | 13 | 988 | 6 (17)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| EMP | 14 | 532 | 2 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | PK_EMP | 14 | | 1 (0)| 00:00:01 |
|* 4 | SORT JOIN | | 13 | 494 | 4 (25)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | EMP | 13 | 494 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("A"."EMPNO"="B"."MGR")
filter("A"."EMPNO"="B"."MGR")
5 - filter("B"."MGR" IS NOT NULL)
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
11 consistent gets
0 physical reads
0 redo size
2091 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
13 rows processed
SQL>
圖片是Toad工具檢視的執行計劃。 在Toad 裡面，很清楚的顯示了執行的順序。 但是如果在SQLPLUS裡面就不是那麼直接。 但我們也可以判斷：一般按縮排長度來判斷，縮排最大的最先執行，如果有2行縮排一樣，那麼就先執行上面的。
3.1 執行計劃中欄位解釋：
ID: 一個序號，但不是執行的先後順序。執行的先後根據縮排來判斷。
Operation： 當前操作的內容。
Rows： 當前操作的Cardinality，Oracle估計當前操作的返回結果集。
Cost（CPU）：Oracle 計算出來的一個數值（代價），用於說明SQL執行的代價。
Time：Oracle 估計當前操作的時間。
3.2 謂詞說明：
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("A"."EMPNO"="B"."MGR")
filter("A"."EMPNO"="B"."MGR")
5 - filter("B"."MGR" IS NOT NULL)
Access: 表示這個謂詞條件的值將會影響資料的訪問路勁（表還是索引）。
Filter：表示謂詞條件的值不會影響資料的訪問路勁，只起過濾的作用。
在謂詞中主要注意access，要考慮謂詞的條件，使用的訪問路徑是否正確。
3.3 統計資訊說明：
db block gets ： 從buffer cache中讀取的block的數量
consistent gets： 從buffer cache中讀取的undo資料的block的數量
physical reads： 從磁碟讀取的block的數量
redo size： DML生成的redo的大小
sorts (memory) ：在記憶體執行的排序量
sorts (disk) ：在磁碟上執行的排序量
Physical Reads通常是我們最關心的，如果這個值很高，說明要從磁碟請求大量的資料到Buffer Cache裡，通常意味著系統裡存在大量全表掃描的SQL語句，這會影響到資料庫的效能，因此儘量避免語句做全表掃描，對於全表掃描的SQL語句，建議增 加相關的索引，優化SQL語句來解決。
關於physical reads ，db block gets 和consistent gets這三個引數之間有一個換算公式：
資料緩衝區的使用命中率=1 - ( physical reads / (db block gets + consistent gets) )。
用以下語句可以檢視資料緩衝區的命中率：
SQL>SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
查詢出來的結果Buffer Cache的命中率應該在90％以上，否則需要增加資料緩衝區的大小。
Recursive Calls： Number of recursive calls generated at both the user and system level.
Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call. In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL—all incur recursive SQL calls。
DB Block Gets： Number of times a CURRENT block was requested.
Current mode blocks are retrieved as they exist right now, not in a consistent read fashion. Normally, blocks retrieved for a query are retrieved as they existed when the query began. Current mode blocks are retrieved as they exist right now, not from a previous point in time. During a SELECT, you might see current mode retrievals due to reading the data dictionary to find the extent information for a table to do a full scan (because you need the "right now" information, not the consistent read). During a modification, you will access the blocks in current mode in order to write to them. (DB Block Gets:請求的資料塊在buffer能滿足的個數)
當前模式塊意思就是在操作中正好提取的塊數目，而不是在一致性讀的情況下而產生的塊數。正常的情況下，一個查詢提取的塊是在查詢開始的那個時間點上存在的資料塊，當前塊是在這個時刻存在的資料塊，而不是在這個時間點之前或者之後的資料塊數目。
Consistent Gets： Number of times a consistent read was requested for a block.
This is how many blocks you processed in "consistent read" mode. This will include counts of blocks read from the rollback segment in order to roll back a block. This is the mode you read blocks in with a SELECT, for example. Also, when you do a searched UPDATE/DELETE, you read the blocks in consistent read mode and then get the block in current mode to actually do the modification. (Consistent Gets: 資料請求總數在回滾段Buffer中的資料一致性讀所需要的資料塊)
這裡的概念是在處理你這個操作的時候需要在一致性讀狀態上處理多少個塊，這些塊產生的主要原因是因為由於在你查詢的過程中，由於其他會話對資料塊進行操 作，而對所要查詢的塊有了修改，但是由於我們的查詢是在這些修改之前呼叫的，所以需要對回滾段中的資料塊的前映像進行查詢，以保證資料的一致性。這樣就產 生了一致性讀。
Physical Reads： Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache. (Physical Reads:例項啟動後，從磁碟讀到Buffer Cache資料塊數量)
就是從磁碟上讀取資料塊的數量，其產生的主要原因是：
（1） 在資料庫快取記憶體中不存在這些塊
（2） 全表掃描
（3） 磁碟排序
它們三者之間的關係大致可概括為：
邏輯讀指的是Oracle從記憶體讀到的資料塊數量。一般來說是'consistent gets' + 'db block gets'。當在記憶體中找不到所需的資料塊的話就需要從磁碟中獲取，於是就產生了'physical reads'。
Sorts(disk):
Number of sort operations that required at least one disk write. Sorts that require I/O to disk are quite resource intensive. Try increasing the size of the initialization parameter SORT_AREA_SIZE.
bytes sent via SQL*Net to client:
Total number of bytes sent to the client from the foreground processes.
bytes received via SQL*Net from client:
Total number of bytes received from the client over Oracle Net.
SQL*Net roundtrips to/from client:
Total number of Oracle Net messages sent to and received from the client.
更多內容參考Oracle聯機文件：
Statistics Descriptions
http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/stats002.htm#i375475
3.4 動態分析
如果在執行計劃中有如下提示：
Note
------------
-dynamic sampling used for the statement
這提示使用者CBO當前使用的技術，需要使用者在分析計劃時考慮到這些因素。 當出現這個提示，說明當前表使用了動態取樣。 我們從而推斷這個表可能沒有做過分析。
這裡會出現兩種情況：
（1） 如果表沒有做過分析，那麼CBO可以通過動態取樣的方式來獲取分析資料，也可以或者正確的執行計劃。
（2） 如果表分析過，但是分析資訊過舊，這時CBO就不會在使用動態取樣，而是使用這些舊的分析資料，從而可能導致錯誤的執行計劃。
總結：
在看執行計劃的時候，除了看執行計劃本身，還需要看謂詞和提示資訊。 通過整體資訊來判斷SQL 效率。
1.1 設定autotrace
序號
命令
解釋
1
SET AUTOTRACE OFF
此為預設值，即關閉Autotrace
2
SET AUTOTRACE ON EXPLAIN
只顯示執行計劃
3
SET AUTOTRACE ON STATISTICS
只顯示執行的統計資訊
4
SET AUTOTRACE ON
包含2,3兩項內容
5
SET AUTOTRACE TRACEONLY
與ON相似，但不顯示語句的執行結果
SQL> set autotrace on
SQL> select * from dave;
ID NAME
---------- ----------
8 安慶
1 dave
2 bl
1 bl
2 dave
3 dba
4 sf-express
5 dmm
已選擇8行。
執行計劃
----------------------------------------------------------
Plan hash value: 3458767806
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
609 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
1.2 使用SQL
SQL>EXPLAIN PLAN FOR sql語句;
SQL>SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
示例：
SQL> EXPLAIN PLAN FOR SELECT * FROM DAVE;
已解釋。
SQL> SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
或者：
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3458767806
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8 | 64 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| DAVE | 8 | 64 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
已選擇8行。
執行計劃
----------------------------------------------------------
Plan hash value: 2137789089
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
統計資訊
----------------------------------------------------------
25 recursive calls
12 db block gets
168 consistent gets
0 physical reads
0 redo size
974 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
8 rows processed
SQL>
1.3 使用Toad,PL/SQL Developer工具
二． Cardinality（基數）/ rows
Cardinality值表示CBO預期從一個行源（row source）返回的記錄數，這個行源可能是一個表，一個索引，也可能是一個子查詢。 在Oracle 9i中的執行計劃中，Cardinality縮寫成Card。 在10g中，Card值被rows替換。
這是9i的一個執行計劃，我們可以看到關鍵字Card：
執行計劃
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=402)
1 0 TABLE ACCESS (FULL) OF 'TBILLLOG8' (Cost=2 Card=1 Bytes=402)
Oracle 10g的執行計劃，關鍵字換成了rows：
執行計劃
----------------------------------------------------------
Plan hash value: 2137789089
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Cardinality的值對於CBO做出正確的執行計劃來說至關重要。 如果CBO獲得的Cardinality值不夠準確（通常是沒有做分析或者分析資料過舊造成），在執行計劃成本計算上就會出現偏差，從而導致CBO錯誤的制定出執行計劃。
在多表關聯查詢或者SQL中有子查詢時，每個關聯表或子查詢的Cardinality的值對主查詢的影響都非常大，甚至可以說，CBO就是依賴於各個關聯表或者子查詢Cardinality值計算出最後的執行計劃。
對於多表查詢，CBO使用每個關聯表返回的行數（Cardinality）決定用什麼樣的訪問方式來做表關聯（如Nested loops Join 或 hash Join）。
多表連線的三種方式詳解 HASH JOIN MERGE JOIN NESTED LOOP
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5826546.aspx
對於子查詢，它的Cardinality將決定子查詢是使用索引還是使用全表掃描的方式訪問資料。
三． SQL 的執行計劃
生成SQL的執行計劃是Oracle在對SQL做硬解析時的一個非常重要的步驟，它制定出一個方案告訴Oracle在執行這條SQL時以什麼樣的方式訪問資料：索引還是全表掃描，是Hash Join還是Nested loops Join等。 比如說某條SQL通過使用索引的方式訪問資料是最節省資源的，結果CBO作出的執行計劃是全表掃描，那麼這條SQL的效能必然是比較差的。
Oracle SQL的硬解析和軟解析
http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5458896.aspx
示例：
SQL> SET AUTOTRACE TRACEONLY; -- 只顯示執行計劃，不顯示結果集
SQL> select * from scott.emp a,scott.emp b where a.empno=b.mgr;
已選擇13行。
執行計劃
----------------------------------------------------------
Plan hash value: 992080948
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 13 | 988 | 6 (17)| 00:00:01 |
| 1 | MERGE JOIN | | 13 | 988 | 6 (17)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| EMP | 14 | 532 | 2 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | PK_EMP | 14 | | 1 (0)| 00:00:01 |
|* 4 | SORT JOIN | | 13 | 494 | 4 (25)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | EMP | 13 | 494 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("A"."EMPNO"="B"."MGR")
filter("A"."EMPNO"="B"."MGR")
5 - filter("B"."MGR" IS NOT NULL)
統計資訊
----------------------------------------------------------
0 recursive calls
0 db block gets
11 consistent gets
0 physical reads
0 redo size
2091 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
13 rows processed
SQL>
圖片是Toad工具檢視的執行計劃。 在Toad 裡面，很清楚的顯示了執行的順序。 但是如果在SQLPLUS裡面就不是那麼直接。 但我們也可以判斷：一般按縮排長度來判斷，縮排最大的最先執行，如果有2行縮排一樣，那麼就先執行上面的。
3.1 執行計劃中欄位解釋：
ID: 一個序號，但不是執行的先後順序。執行的先後根據縮排來判斷。
Operation： 當前操作的內容。
Rows： 當前操作的Cardinality，Oracle估計當前操作的返回結果集。
Cost（CPU）：Oracle 計算出來的一個數值（代價），用於說明SQL執行的代價。
Time：Oracle 估計當前操作的時間。
3.2 謂詞說明：
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("A"."EMPNO"="B"."MGR")
filter("A"."EMPNO"="B"."MGR")
5 - filter("B"."MGR" IS NOT NULL)
Access: 表示這個謂詞條件的值將會影響資料的訪問路勁（表還是索引）。
Filter：表示謂詞條件的值不會影響資料的訪問路勁，只起過濾的作用。
在謂詞中主要注意access，要考慮謂詞的條件，使用的訪問路徑是否正確。
3.3 統計資訊說明：
db block gets ： 從buffer cache中讀取的block的數量
consistent gets： 從buffer cache中讀取的undo資料的block的數量
physical reads： 從磁碟讀取的block的數量
redo size： DML生成的redo的大小
sorts (memory) ：在記憶體執行的排序量
sorts (disk) ：在磁碟上執行的排序量
Physical Reads通常是我們最關心的，如果這個值很高，說明要從磁碟請求大量的資料到Buffer Cache裡，通常意味著系統裡存在大量全表掃描的SQL語句，這會影響到資料庫的效能，因此儘量避免語句做全表掃描，對於全表掃描的SQL語句，建議增 加相關的索引，優化SQL語句來解決。
關於physical reads ，db block gets 和consistent gets這三個引數之間有一個換算公式：
資料緩衝區的使用命中率=1 - ( physical reads / (db block gets + consistent gets) )。
用以下語句可以檢視資料緩衝區的命中率：
SQL>SELECT name, value FROM v$sysstat WHERE name IN ('db block gets', 'consistent gets','physical reads');
查詢出來的結果Buffer Cache的命中率應該在90％以上，否則需要增加資料緩衝區的大小。
Recursive Calls： Number of recursive calls generated at both the user and system level.
Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call. In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL—all incur recursive SQL calls。
DB Block Gets： Number of times a CURRENT block was requested.
Current mode blocks are retrieved as they exist right now, not in a consistent read fashion. Normally, blocks retrieved for a query are retrieved as they existed when the query began. Current mode blocks are retrieved as they exist right now, not from a previous point in time. During a SELECT, you might see current mode retrievals due to reading the data dictionary to find the extent information for a table to do a full scan (because you need the "right now" information, not the consistent read). During a modification, you will access the blocks in current mode in order to write to them. (DB Block Gets:請求的資料塊在buffer能滿足的個數)
當前模式塊意思就是在操作中正好提取的塊數目，而不是在一致性讀的情況下而產生的塊數。正常的情況下，一個查詢提取的塊是在查詢開始的那個時間點上存在的資料塊，當前塊是在這個時刻存在的資料塊，而不是在這個時間點之前或者之後的資料塊數目。
Consistent Gets： Number of times a consistent read was requested for a block.
This is how many blocks you processed in "consistent read" mode. This will include counts of blocks read from the rollback segment in order to roll back a block. This is the mode you read blocks in with a SELECT, for example. Also, when you do a searched UPDATE/DELETE, you read the blocks in consistent read mode and then get the block in current mode to actually do the modification. (Consistent Gets: 資料請求總數在回滾段Buffer中的資料一致性讀所需要的資料塊)
這裡的概念是在處理你這個操作的時候需要在一致性讀狀態上處理多少個塊，這些塊產生的主要原因是因為由於在你查詢的過程中，由於其他會話對資料塊進行操 作，而對所要查詢的塊有了修改，但是由於我們的查詢是在這些修改之前呼叫的，所以需要對回滾段中的資料塊的前映像進行查詢，以保證資料的一致性。這樣就產 生了一致性讀。
Physical Reads： Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache. (Physical Reads:例項啟動後，從磁碟讀到Buffer Cache資料塊數量)
就是從磁碟上讀取資料塊的數量，其產生的主要原因是：
（1） 在資料庫快取記憶體中不存在這些塊
（2） 全表掃描
（3） 磁碟排序
它們三者之間的關係大致可概括為：
邏輯讀指的是Oracle從記憶體讀到的資料塊數量。一般來說是'consistent gets' + 'db block gets'。當在記憶體中找不到所需的資料塊的話就需要從磁碟中獲取，於是就產生了'physical reads'。
Sorts(disk):
Number of sort operations that required at least one disk write. Sorts that require I/O to disk are quite resource intensive. Try increasing the size of the initialization parameter SORT_AREA_SIZE.
bytes sent via SQL*Net to client:
Total number of bytes sent to the client from the foreground processes.
bytes received via SQL*Net from client:
Total number of bytes received from the client over Oracle Net.
SQL*Net roundtrips to/from client:
Total number of Oracle Net messages sent to and received from the client.
更多內容參考Oracle聯機文件：
Statistics Descriptions
http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/stats002.htm#i375475
3.4 動態分析
如果在執行計劃中有如下提示：
Note
------------
-dynamic sampling used for the statement
這提示使用者CBO當前使用的技術，需要使用者在分析計劃時考慮到這些因素。 當出現這個提示，說明當前表使用了動態取樣。 我們從而推斷這個表可能沒有做過分析。
這裡會出現兩種情況：
（1） 如果表沒有做過分析，那麼CBO可以通過動態取樣的方式來獲取分析資料，也可以或者正確的執行計劃。
（2） 如果表分析過，但是分析資訊過舊，這時CBO就不會在使用動態取樣，而是使用這些舊的分析資料，從而可能導致錯誤的執行計劃。
總結：
在看執行計劃的時候，除了看執行計劃本身，還需要看謂詞和提示資訊。 通過整體資訊來判斷SQL 效率。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23490154/viewspace-1061692/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle執行計劃Explain Plan 如何使用OracleAI
- "The Alberta Plan for AI Research" - "Research Plan" from Richard SuttonAI
- MySQL explainMySqlAI
- [Mysql]ExplainMySqlAI
- PostgreSQL：EXPLAINSQLAI
- Virtualbox host plan
- 4.2.1.1 Plan the PDBs
- explain記錄AI
- MySQL 索引 +explainMySql索引AI
- sql_plan_baselineSQL
- 1030 Travel Plan (30分)
- 【Lintcode】1891. Travel Plan
- MySQL學習之explainMySqlAI
- MySQL explain命令詳解MySqlAI
- MySQL 中的 EXPLAIN 命令MySqlAI
- MySQL的Explain總結MySqlAI
- SQL PLAN Management的測試SQL
- PAT甲級1030 Travel Plan
- Study Plan For Algorithms - Part44Go
- Study Plan For Algorithms - Part45Go
- Study Plan For Algorithms - Part46Go
- Study Plan For Algorithms - Part38Go
- Study Plan For Algorithms - Part39Go
- Study Plan For Algorithms - Part40Go
- Study Plan For Algorithms - Part28Go
- Study Plan For Algorithms - Part19Go
- Study Plan For Algorithms - Part33Go
- Study Plan For Algorithms - Part37Go
- Study Plan For Algorithms - Part29Go
- Study Plan For Algorithms - Part12Go
- Study Plan For Algorithms - Part14Go
- Study Plan For Algorithms - Part11Go
- Study Plan For Algorithms - Part13Go
- Study Plan For Algorithms - Part15Go
- Study Plan For Algorithms - Part4Go
- Study Plan For Algorithms - Part1Go
- Study Plan For Algorithms - Part6Go
- Study Plan For Algorithms - Part16Go
- Study Plan For Algorithms - Part17Go