詳聊驗證Oracle SQL語句
學習Oracle時，你可能會遇到驗證Oracle SQL語句問題，這里將介紹驗證Oracle SQL語句問題的解決方法，在這里拿出來和大家分享一下。檢查共享池中是否有相同的語句存在。假如執行的SQL語句已經在共享池中存在同樣的副本，那么該SQL語句將會被軟解析，也就是可以重用已解析過的語句的執行計劃和優化方案，可以忽略語句解析過程中最耗費資源的步驟，這也是我們為什么一直強調避免硬解析的原因。這個步驟又可以分為兩個步驟：
（1）驗證Oracle 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語句就已經可以共享了。我們首先參考如下一個例子：假如用戶A有自己的一張表EMP，他要執行查詢語句：select * from emp；用戶B也有一張EMP表，同樣要查詢select * from emp；這樣他們兩條語句在文本上是一模一樣的，他們的HASH值也會一樣，但是由于涉及到查詢的相關表不一樣，他們事實上是無法共享的。假如這時候用戶 C又要查詢同樣一條語句，他查詢的表為scott下的公有同義詞，還有就是SCOTT也查詢同樣一張自己的表emp，情況會是如何呢？
我們可以看到這四個查詢的語句文本和HASH值都是一樣的，但是由于查詢的對象不同，只有后面兩個語句是可以共享的，不同情況的語句還是需要硬解析的。因此在檢查共享池共同SQL語句的時候，是需要根據具體情況而定的。
（2）驗證Oracle SQL語句執行環境是否相同。比如同樣一條SQL語句，一個查詢會話加了/*+ first_rows */的HINT，另外一個用戶加/*+ all_rows */的HINT，他們就會產生不同的執行計劃，盡管他們是查詢同樣的數據。我們下面就一個實例來說明SQL執行環境對解析的影響，我們通過將會話的 workarea_size_policy變更來查看對同樣一條SQL語句執行的影響。
Oracle根據提交的SQL語句再查詢相應的數據對象是否有統計信息。如果有統計信息的話，那么CBO將會使用這些統計信息產生所有可能的執行計劃（可能多達成千上萬個）和相應的Cost，最終選擇Cost最低的那個執行計劃。如果查詢的數據對象無統計信息，則按RBO的默認規則選擇相應的執行計劃。這個步驟也是解析中最耗費資源的，因此我們應該極力避免硬解析的產生。至此，解析的步驟已經全部完成，Oracle將會根據解析產生的執行計劃執行SQL語句和提取相應的數據。
【編輯推薦】
