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