軟解析和硬解析

在Oracle中每條SQL語句在執行之前都需要經過解析，解析分為軟解析和硬解析。
在Oracle中存在兩種型別的SQL語句：
（1）DDL語句(資料定義語言)，該語句不會共享使用的，每次執行都需要進行硬解析，DDL包含：CREATE,DROP,ALTER。
（2）DML語句(資料操縱語言)，他們會根據情況選擇要麼進行硬解析，要麼進行軟解析。DML包含：INSERT,UPDATE,DELETE,SELECT
 
SQL 解析過程
Oracle對此SQL將進行幾個步驟的處理過程：
    1、語法檢查(syntax check): 檢查此sql的拼寫是否語法。
    2、語義檢查(semantic check): 諸如檢查sql語句中的訪問物件是否存在及該使用者是否具備相應的許可權。
    3、對sql語句進行解析(prase): 利用內部演算法對sql進行解析，生成解析樹(parse tree)及執行計劃(execution plan)。
    4、執行sql，返回結果(execute and return)
 
解析過程詳解
語法檢測
判斷一條SQL語句的語法是否符合SQL的規範，比如執行：
SQL> selet * from emp;
我們就可以看出由於Select關鍵字少了一個“c”，這條語句就無法通過語法檢驗的步驟了。
 
語義檢查
語法正確的SQL語句在解析的第二個步驟就是判斷該SQL語句所訪問的表及列是否準確？使用者是否有許可權訪問或更改相應的表或列？ 比如如下語句：
 
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
 
由於查詢使用者沒有可供訪問的emp物件，因此該SQL語句無法通過語義檢查。
 
解析(Parse)
Parse主要分為兩種：
    1、Hard Parse (硬解析)
    2、Soft Parse (軟解析)


 
Hard Parse： 就是上面提到的對提交的Sql完全重新從頭進行解析(當在Shared Pool中找不到時候將會進行此操作)，總共有一下5個執行步驟：
    1：語法分析
    2：許可權與物件檢查
    3： 在共享池中檢查是否有完全相同的之前完全解析好的. 如果存在，直接跳過4和5，執行Sql, 此時算soft parse.
    4：選擇執行計劃
    5：產生執行計劃
 
注：建立解析樹、生成執行計劃對於sql的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，儘量使用軟解析。這就是在很多專案中，倡導開發設計人員對功能相同的程式碼要努力保持程式碼的一致性，以及要在程式中多使用繫結變數的原因。
 
Soft Parse： 就如果是在Shared Pool中找到了與之完全相同的Sql解析好的結果後會跳過Hard Parse中的後面的兩個步驟。
 
解析的兩個步驟
 
1)　驗證SQL語句是否完全一致
  在這個步驟中，Oracle將會對傳遞進來的SQL語句使用HASH函式運算得出HASH值，再與共享池中現有語句的HASH值進行比較看是否一一對應。現有資料庫中SQL語句的HASH值我們可以通過訪問v$sql、v$sqlarea、v$sqltext等資料字典中的HASH_VALUE列查詢得出。
 
如果SQL語句的HASH值一致，那麼ORACLE事實上還需要對SQL語句的語義進行再次檢測，以決定是否一致。那麼為什麼Oracle需要再次對語句文字進行檢測呢？不是SQL語句的HASH值已經對應上了？事實上就算是SQL語句的HASH值已經對應上了，並不能說明這兩條SQL語句就已經可以共享了。
 
例如：假如使用者SYS有自己的一張表EMP，他要執行查詢語句：select * from emp; 使用者SYSTEM也有一張EMP表，同樣要查詢select * from emp；這樣他們兩條語句在文字上是一模一樣的，他們的HASH值也會一樣，但是由於涉及到查詢的相關表不一樣，他們事實上是無法共享的. 
 
SQL> conn / as sysdba
已連線。
SQL> show user
USER 為 "SYS"
SQL>  create table emp ( x int ) ;
表已建立。
SQL> select * from emp;
未選定行
SQL> conn system/admin;
已連線。
SQL>  create table emp ( x int );
表已建立。
SQL> select * from emp;
未選定行
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                                                                
-----------------------  ---------------------------------------------------------
2769AE64    1745700775     1         select * from emp                                                                                                                         
2769AE64    1745700775     1         select * from emp                                                    
2 rows selected.
 
從結果可以看到這2個查詢的語句文字和HASH值都是一樣的，但是由於查詢的物件不同，是無法共享的，不同情況的語句還是需要硬解析的。因此在檢查共享池共同SQL語句的時候，是需要根據具體情況而定的。
 
可以進一步查詢v$sql_shared_cursor以得知SQL為何不能共享的原因：
 
SQL>select address,auth_check_mismatch,translation_mismatch,optimizer_mismatch 
from v$sql_shared_cursor where address in ( select address from v$sql where upper(sql_text) like 'SELECT * FROM EMP%' )  
 
ADDRESS     A T O
----------------  ----- -- -- 
2769AE64     N N N
2769AE64     Y Y N
 
A T O 欄位說明：
（1）translation_mismatch： 表示sql遊標涉及到的資料物件是不同的；
（2）auth_check_mismatch： 表示對同樣一條sql語句轉換是不匹配的。
（3）optimizer_mismatch： 表示會話的優化器環境是不同的。
 
 2)  驗證SQL語句執行環境是否相同
比如同樣一條SQL語句，一個查詢會話加了/*+ first_rows */的HINT，另外一個使用者加/*+ all_rows */的HINT，他們就會產生不同的執行計劃，儘管他們是查詢同樣的資料。
 
通過如上檢查以後，如果SQL語句是一致的，那麼就會重用原有SQL語句的執行計劃和優化方案，也就是我們通常所說的軟解析。如果SQL語句沒有找到同樣的副本，那麼就需要進行硬解析了。
 
Oracle根據提交的SQL語句再查詢相應的資料物件是否有統計資訊。
如果有統計資訊的話，那麼CBO將會使用這些統計資訊產生所有可能的執行計劃(可能多達成千上萬個)和相應的Cost，最終選擇Cost最低的那個執行計劃。
如果查詢的資料物件無統計資訊，就會採用動態取樣， 這個結果不一定準確，但可以提供一定的參考。

執行sql
返回結果(execute and return)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/27500440/viewspace-1819093/，如需轉載，請註明出處，否則將追究法律責任。