1.sql解析的過程

• oracle首先將SQL文本轉化為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語句時，將跳過硬解析的所有步驟。這種情況下，是最高效的解析方式，但是會消耗很大 的內存。

?

2.查看sql解析的過程、內部結構

3.sql解析過程統計

總結

以上是生活随笔為你收集整理的oracle 内存结构 share pool sql解析的过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。