我們都知道在Oracle中每條SQL語(yǔ)句在執行之前都需要經(jīng)過(guò)解析，這里面又分為軟解析和硬解析。那么這兩種解析有何不同之處呢？它們又分別是如何進(jìn)行解析呢？Oracle內部解析的步驟又是如何進(jìn)行的呢？下面我們就這些話(huà)題進(jìn)行共同探討。
在Oracle中存在兩種類(lèi)型的SQL語(yǔ)句，一類(lèi)為DDL語(yǔ)句，他們是從來(lái)不會(huì )共享使用的，也就是每次執行都需要進(jìn)行硬解析。還有一類(lèi)就是DML語(yǔ)句，他們會(huì )根據情況選擇要么進(jìn)行硬解析，要么進(jìn)行軟解析。在Oracle 8i OCP教材的023中1-12有說(shuō)明SQL語(yǔ)句的解析步驟，當一條SQL語(yǔ)句從客戶(hù)端進(jìn)程傳遞到服務(wù)器端進(jìn)程后，需要執行如下步驟：
• 在共享池中搜索 SQL 語(yǔ)句的現有副本
• 驗證 SQL 語(yǔ)句的語(yǔ)法是否準確
• 執行數據字典查找來(lái)驗證表和列的定義
• 獲取對象的分析鎖以便在語(yǔ)句的分析過(guò)程中對象的定義不會(huì )改變
• 檢查用戶(hù)訪(fǎng)問(wèn)引用方案對象的權限
• 確定語(yǔ)句的最佳執行計劃
• 將語(yǔ)句和執行計劃載入共享的 SQL 區
這個(gè)先入為主的概念一直占據著(zhù)我的腦海，我認為硬解析就是上面幾個(gè)步驟。相對于硬解析，軟解析的步驟就是上面第一步找到現有SQL語(yǔ)句的副本后，只需要驗證用戶(hù)是否有權限執行就是了，這樣省略上面好幾個(gè)步驟，相對硬解析來(lái)說(shuō)性能開(kāi)銷(xiāo)就非常小了。即使是在論壇上和大家討論時(shí)，我也一直堅持這個(gè)看法。直到前一天看了Tom的《Effective Oracle By Design》中關(guān)于語(yǔ)句處理的章節后，我才知道這個(gè)自己一直堅持的觀(guān)點(diǎn)事實(shí)上是錯誤的。
事實(shí)上，在Oracle中SQL語(yǔ)句的解析步驟如下：
1、 語(yǔ)法檢測。判斷一條SQL語(yǔ)句的語(yǔ)法是否符合SQL的規范，比如執行：SQL> selet * from emp；我們就可以看出由于Select關(guān)鍵字少了一個(gè)“c”，這條語(yǔ)句就無(wú)法通過(guò)語(yǔ)法檢驗的步驟了。
2、 語(yǔ)義檢查。語(yǔ)法正確的SQL語(yǔ)句在解析的第二個(gè)步驟就是判斷該SQL語(yǔ)句所訪(fǎng)問(wèn)的表及列是否準確？用戶(hù)是否有權限訪(fǎng)問(wèn)或更改相應的表或列？比如如下語(yǔ)句：
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
由于查詢(xún)用戶(hù)沒(méi)有可供訪(fǎng)問(wèn)的emp對象，因此該SQL語(yǔ)句無(wú)法通過(guò)語(yǔ)義檢查。
3、 檢查共享池中是否有相同的語(yǔ)句存在。假如執行的SQL語(yǔ)句已經(jīng)在共享池中存在同樣的副本，那么該SQL語(yǔ)句將會(huì )被軟解析，也就是可以重用已解析過(guò)的語(yǔ)句的執行計劃和優(yōu)化方案，可以忽略語(yǔ)句解析過(guò)程中最耗費資源的步驟，這也是我們?yōu)槭裁匆恢睆娬{避免硬解析的原因。這個(gè)步驟又可以分為兩個(gè)步驟：
?。?）驗證SQL語(yǔ)句是否完全一致。在這個(gè)步驟中，Oracle將會(huì )對傳遞進(jìn)來(lái)的SQL語(yǔ)句使用HASH函數運算得出HASH值，再與共享池中現有語(yǔ)句的HASH值進(jìn)行比較看是否一一對應?，F有數據庫中SQL語(yǔ)句的HASH值我們可以通過(guò)訪(fǎng)問(wèn)v$sql、v$sqlarea、v$sqltext等數據字典中的HASH_VALUE列查詢(xún)得出。如果SQL語(yǔ)句的HASH值一致，那么ORACLE事實(shí)上還需要對SQL語(yǔ)句的語(yǔ)義進(jìn)行再次檢測，以決定是否一致。那么為什么Oracle需要再次對語(yǔ)句文本進(jìn)行檢測呢？不是SQL語(yǔ)句的HASH值已經(jīng)對應上了？事實(shí)上就算是SQL語(yǔ)句的HASH值已經(jīng)對應上了，并不能說(shuō)明這兩條SQL語(yǔ)句就已經(jīng)可以共享了。我們首先參考如下一個(gè)例子：假如用戶(hù)A有自己的一張表EMP，他要執行查詢(xún)語(yǔ)句：select * from emp；用戶(hù)B也有一張EMP表，同樣要查詢(xún)select * from emp；這樣他們兩條語(yǔ)句在文本上是一模一樣的，他們的HASH值也會(huì )一樣，但是由于涉及到查詢(xún)的相關(guān)表不一樣，他們事實(shí)上是無(wú)法共享的。假如這時(shí)候用戶(hù)C又要查詢(xún)同樣一條語(yǔ)句，他查詢(xún)的表為scott下的公有同義詞，還有就是SCOTT也查詢(xún)同樣一張自己的表emp，情況會(huì )是如何呢？
SQL> connect a/a
Connected.
SQL> create table emp ( x int );
Table created.
SQL> select * from emp;
no rows selected
SQL> connect b/b
Connected.
SQL> create table emp ( x int );
Table created.
SQL> select * from emp;
no rows selected
SQL> conn scott/tiger
Connected.
SQL> select * from emp;
SQL> conn c/c
Connected.
SQL> select * from emp;
SQL> conn/as sysdba
Connected.
SQL> select address,hash_value, executions, sql_text
2 from v$sql
3 where upper(sql_text) like ’SELECT * FROM EMP%’
4 /
ADDRESS HASH_VALUE EXECUTIONS SQL_TEXT
-------- ---------- ---------- ------------------------
78B89E9C 3011704998 1 select * from emp
78B89E9C 3011704998 1 select * from emp
78B89E9C 3011704998 2 select * from emp
我們可以看到這四個(gè)查詢(xún)的語(yǔ)句文本和HASH值都是一樣的，但是由于查詢(xún)的對象不同，只有后面兩個(gè)語(yǔ)句是可以共享的，不同情況的語(yǔ)句還是需要硬解析的。因此在檢查共享池共同SQL語(yǔ)句的時(shí)候，是需要根據具體情況而定的。
我們可以進(jìn)一步查詢(xún)v$sql_shared_cursor以得知SQL為何不能共享的原因：
SQL> select kglhdpar, address,
2 auth_check_mismatch, translation_mismatch
3 from v$sql_shared_cursor
4 where kglhdpar in
5 ( select address
6 from v$sql
7 where upper(sql_text) like ’SELECT * FROM EMP%’ )
8 /
KGLHDPAR ADDRESS A T
-------- -------- - -
78B89E9C 786C9D78 N N
78B89E9C 786AC810 Y Y
78B89E9C 786A11A4 Y Y
TRANSLATION_MISMATCH表示SQL游標涉及到的數據對象是不同的；AUTH_CHECK_MISMATCH表示對同樣一條SQL語(yǔ)句轉換是不匹配的。
?。?、）驗證SQL語(yǔ)句執行環(huán)境是否相同。比如同樣一條SQL語(yǔ)句，一個(gè)查詢(xún)會(huì )話(huà)加了/*+ first_rows */的HINT，另外一個(gè)用戶(hù)加/*+ all_rows */的HINT，他們就會(huì )產(chǎn)生不同的執行計劃，盡管他們是查詢(xún)同樣的數據。我們下面就一個(gè)實(shí)例來(lái)說(shuō)明SQL執行環(huán)境對解析的影響，我們通過(guò)將會(huì )話(huà)的workarea_size_policy變更來(lái)查看對同樣一條SQL語(yǔ)句執行的影響：
SQL> alter system flush shared_pool;
System altered.
SQL> show parameter workarea_size_policy
NAME TYPE VALUE
------------------------------------ ----------- --------------
workarea_size_policy string AUTO
SQL> select count(*) from t;
COUNT(*)
----------
5736
SQL> alter session set workarea_size_policy=manual;
Session altered.
SQL> select count(*) from t;
COUNT(*)
----------
5736
SQL> select sql_text, child_number, hash_value, address
2 from v$sql
3 where upper(sql_text) = ’SELECT COUNT(*) FROM T’
4 /
SQL_TEXT CHILD_NUMBER HASH_VALUE ADDRESS
------------------------------ ------------ ---------- --------
select count(*) from t 0 2199322426 78717328
select count(*) from t 1 2199322426 78717328
可以看到由于不同會(huì )話(huà)workarea_size_policy設置得不同，即使是同樣一條SQL語(yǔ)句還是無(wú)法共享的。通過(guò)進(jìn)一步查詢(xún)v$sql_shared_cursor我們可以發(fā)現兩個(gè)會(huì )話(huà)的優(yōu)化器環(huán)境是不同的：
SQL> select optimizer_mismatch
2 from v$sql_shared_cursor
3 where kglhdpar in
4 ( select address
5 from v$sql
6 where upper(sql_text) = ’SELECT COUNT(*) FROM T’ );
O
-
N
Y
通過(guò)如上三個(gè)步驟檢查以后，如果SQL語(yǔ)句是一致的，那么就會(huì )重用原有SQL語(yǔ)句的執行計劃和優(yōu)化方案，也就是我們通常所說(shuō)的軟解析。如果SQL語(yǔ)句沒(méi)有找到同樣的副本，那么就需要進(jìn)行硬解析了。
4、 Oracle根據提交的SQL語(yǔ)句再查詢(xún)相應的數據對象是否有統計信息。如果有統計信息的話(huà)，那么CBO將會(huì )使用這些統計信息產(chǎn)生所有可能的執行計劃（可能多達成千上萬(wàn)個(gè)）和相應的Cost，最終選擇Cost最低的那個(gè)執行計劃。如果查詢(xún)的數據對象無(wú)統計信息，則按RBO的默認規則選擇相應的執行計劃。這個(gè)步驟也是解析中最耗費資源的，因此我們應該極力避免硬解析的產(chǎn)生。至此，解析的步驟已經(jīng)全部完成，Oracle將會(huì )根據解析產(chǎn)生的執行計劃執行SQL語(yǔ)句和提取相應的數據。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
