oracle中bind peeking問題的解決方案

使用綁定變數可以減少SQL PARSE，但是使用綁定變數有一個不好的地方，就是對於訪

問具有傾斜的列，可能使用錯誤的執行計畫。在Oracle 9i之前，如果WHERE 條件裡面全

部使用綁定變數，那麼只能使用固定的選擇性參數來確定執行計畫。

=操作和>=操作的選擇性為5%，範圍掃描的選擇性為25%。預設值的方式可能產生不好的執

行計劃。所以Oracle 9i就出現了一個新的技術，bind peeking。什麼是bind peeking呢

？當SQL第一次執行的時候，最佳化器會根據綁定變數來確定執行計畫（如果存在柱狀圖）

。BIND PEEKING只有當該SQL第一次執行的時候，進行HARD PARSE的時候才進行，第二次

調用該SQL，就不會再次進行BIND PEEKING。這種情況下，就存在另外一個風險，如果某

個列的傾斜性很厲害，那麼使用BIND PEEKING就是不安全的，因為不同的參數代入，只能

走第一次執行時的執行計畫，那麼執行計畫就像擲色子一樣，要靠運氣了。碰到這種情況

，應用就不應該使用綁定變數，而應該改為直接值了。
  這時可以使用重新整理一下共用池alter system flush shared_pool;
  或者alter session set "_optim_peek_user_binds"=false;

   我們可以通過隱含的參數來調整資料庫預設的bind peeking行為：

_OPTIM_PEEK_USER_BINDS。 如果我們想關閉Bind Variable Peeking，我們可以設定該參

數為 False 即可。

SQL>alter session set "_optim_peek_user_binds"=false

使用了Bind Var能提高效能主要是因為這樣做可以盡量避免不必要的硬分析(Hard Parse)

而節約了時間，同時節約了大量的CPU資源。

    當一個Client提交一條Sql給Oracle後，Oracle 首先會對其進行解析(Parse)，然後

將解析結果提交給最佳化器(Optimiser)來進行最佳化而取得Oracle認為的最優的Query Plan

，然後再按照這個最優的Plan來執行這個Sql語句(當然在這之中如果只需要軟解析的話會

少部分步驟)。

當Oracle接到 Client提交的Sql後會首先在共用池(Shared Pool)裡面去尋找是否有之前

已經解析好的與剛接到的這一個Sql完全相同的Sql(注意這裡說的是完全相同，既要求語

句上的字元層級的完全相同，又要求涉及的對象也必須完全相同)。當發現有相同的以後

解析器就不再對新的Sql在此解析而直接用之前解析好的結果了。這裡就節約瞭解析時間

以及解析時候消耗的CPU資源。尤其是在OLTP中運行著的大量的短小Sql，效果就會比較明

顯了。因為一條兩條Sql的時間可能不會有多少感覺，但是當量大了以後就會有比較明顯

的感覺了。

但是，使用綁定變數的一個缺點是，給出的執行計畫並不一定就是SQL在真正應用程式裡

所使用的執行計畫。這時我們就可以通過 event 10053 事件來查看。