SQL 解析的過程

tolywang發表於2010-08-08

 

  • 首先將文字轉化為ASCII字元,然後根據hash函式計算其對應的hash值(hash_value)。根據計算出的hash值到library cache中找到對應的bucket,然後比較bucket裡是否存在該SQL語句。
  • 如果不存在,獲得shared pool latch,然後在shared pool中的可用chunk連結串列(也就是bucket)上找到一個可用的chunk,然後釋放shared pool latch。在獲得了chunk以後,這塊chunk就可以認為是進入了library cache。然後,進行硬解析過程。
  • 對SQL語句進行語法檢查,看是否有語法錯誤。比如沒有寫from等。如果有,則退出解析過程。 
  •  到資料字典裡校驗SQL語句涉及的物件和列是否都存在。如果不存在,則退出解析過程。 
  •  將物件進行名稱轉換。比如將同名詞翻譯成實際的物件等。如果轉換失敗,則退出解析過程。
  •  檢查遊標裡使用者是否具有訪問SQL語句裡所引用的物件的許可權。如果沒有許可權,則退出解析過程。
  •  透過最佳化器建立一個最優的執行計劃。這一步是最消耗CPU資源的。 
  •  將該遊標所產生的執行計劃、SQL文字等裝載進library cache的若干個heap中。
  • 在硬解析的過程中,程式會一直持有library cach latch,直到硬解析結束。硬解析結束以後,會為該SQL產生兩個遊標,一個是父遊標,另一個是子游標。父遊標裡主要包含兩種資訊:SQL文字以及最佳化目標(optimizer goal)。父遊標在第一次開啟時被鎖定,直到其他所有的session都關閉該遊標後才被解鎖。當父遊標被鎖定的時候是不能被交換出library cache的,只有在解鎖以後才能被交換出library cache,這時該父遊標對應的所有子游標也被交換出library cache。子游標包括遊標所有的資訊,比如具體的執行計劃、繫結變數等。
  • 子游標隨時可以被交換出library cache,當子游標被交換出library cache時,oracle可以利用父遊標的資訊重新構建出一個子遊標來,這個過程叫reload。可以使用下面的方式來確定reload的比率:
    SELECT 100*sum(reloads)/sum(pins) Reload_Ratio FROM v$librarycache;
    一個父遊標可以對應多個子遊標。子游標具體的個數可以從v$sqlarea的version_count欄位體現出來。而每個具體的子游標則全都在v$sql裡體現。當具體的繫結變數的值與上次的繫結變數的值有較大差異(比如上次執行的繫結變數的值的長度是6位,而這次執行的繫結變數的值的長度是 200位)時或者當SQL語句完全相同,但是所引用的物件屬於不同的schema時,都會建立一個新的子游標。
  • 如果在bucket中找到了該SQL語句,則說明該SQL語句以前執行過,於是進行軟解析。軟解析是相對於硬解析而言的,如果解析過程中,可以從硬解析的步驟中去掉一個或多個的話,這樣的解析就是軟解析。軟解析分為以下三種型別。
    1) 第一種是某個session發出的SQL語句與library cache裡其他session發出的SQL語句一致。這時,該解析過程中可以去掉硬解析中的5和6這兩步,但是仍然要進行硬解析過程中的2、3、4步驟:也就是表名和列名檢查、名稱轉換和許可權檢查。
    2) 第二種是某個session發出的SQL語句與library cache裡該同一個session之前發出的SQL語句一致。這時,該解析過程中可以去掉硬解析中的2、3、5和6這四步,但是仍然要進行許可權檢查,因為可能透過grant改變了該session使用者的許可權。
    3) 第三種是當設定了初始化引數session_cached_cursors時,當某個session對相同的cursor進行第三次訪問時,將在該 session的PGA裡建立一個標記,並且該遊標即使已經被關閉也不會從library cache中交換出去。這樣,該session以後再執行相同的SQL語句時,將跳過硬解析的所有步驟。這種情況下,是最高效的解析方式,但是會消耗很大的記憶體。

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

相關文章