1.sql解析的過程

• oracle首先將SQL文本轉(zhuǎn)化為ASCII字符，然后根據(jù)hash函數(shù)計(jì)算其對應(yīng)的hash值（hash_value）。根據(jù)計(jì)算出的hash值到library cache中找到對應(yīng)的bucket，然后比較bucket里是否存在該SQL語句。
• 如果不存在，獲得shared pool latch，然后在shared pool中的可用chunk鏈表（也就是bucket）上找到一個(gè)可用的chunk，然后釋放shared pool latch。在獲得了chunk以后，這塊chunk就可以認(rèn)為是進(jìn)入了library cache。然后，進(jìn)行硬解析過程。
• 對SQL語句進(jìn)行語法檢查，看是否有語法錯(cuò)誤。比如沒有寫from等。如果有，則退出解析過程。?
• ?到數(shù)據(jù)字典里校驗(yàn)SQL語句涉及的對象和列是否都存在。如果不存在，則退出解析過程。?
• ?將對象進(jìn)行名稱轉(zhuǎn)換。比如將同名詞翻譯成實(shí)際的對象等。如果轉(zhuǎn)換失敗，則退出解析過程。?
• ?檢查游標(biāo)里用戶是否具有訪問SQL語句里所引用的對象的權(quán)限。如果沒有權(quán)限，則退出解析過程。
• ?通過優(yōu)化器創(chuàng)建一個(gè)最優(yōu)的執(zhí)行計(jì)劃。這一步是最消耗CPU資源的。?
• ?將該游標(biāo)所產(chǎn)生的執(zhí)行計(jì)劃、SQL文本等裝載進(jìn)library cache的若干個(gè)heap中。
• 在硬解析的過程中，進(jìn)程會(huì)一直持有l(wèi)ibrary cach latch，直到硬解析結(jié)束。硬解析結(jié)束以后，會(huì)為該SQL產(chǎn)生兩個(gè)游標(biāo)，一個(gè)是父游標(biāo)，另一個(gè)是子游標(biāo)。父游標(biāo)里主要包含兩種信息：SQL文本以及優(yōu)化 目標(biāo)（optimizer goal）。父游標(biāo)在第一次打開時(shí)被鎖定，直到其他所有的session都關(guān)閉該游標(biāo)后才被解鎖。當(dāng)父游標(biāo)被鎖定的時(shí)候是不能被交換出library cache的，只有在解鎖以后才能被交換出library cache，這時(shí)該父游標(biāo)對應(yīng)的所有子游標(biāo)也被交換出library cache。子游標(biāo)包括游標(biāo)所有的信息，比如具體的執(zhí)行計(jì)劃、綁定變量等。
• 子游標(biāo)隨時(shí)可以被交換出library cache，當(dāng)子游標(biāo)被交換出library cache時(shí)，oracle可以利用父游標(biāo)的信息重新構(gòu)建出一個(gè)子游標(biāo)來，這個(gè)過程叫reload。可以使用下面的方式來確定reload的比率：?
  SELECT 100*sum(reloads)/sum(pins) Reload_Ratio FROM v$librarycache;?
  一 個(gè)父游標(biāo)可以對應(yīng)多個(gè)子游標(biāo)。子游標(biāo)具體的個(gè)數(shù)可以從v$sqlarea的version_count字段體現(xiàn)出來。而每個(gè)具體的子游標(biāo)則全都在?v$sql里體現(xiàn)。當(dāng)具體的綁定變量的值與上次的綁定變量的值有較大差異（比如上次執(zhí)行的綁定變量的值的長度是6位，而這次執(zhí)行的綁定變量的值的長度是 200位）時(shí)或者當(dāng)SQL語句完全相同，但是所引用的對象屬于不同的schema時(shí)，都會(huì)創(chuàng)建一個(gè)新的子游標(biāo)。
• 如果在bucket中找到了該SQL語句，則說明該SQL語句以前運(yùn)行過，于是進(jìn)行軟解析。軟解析是相對于硬解析而言的，如果解析過程中，可以從硬解析的步驟中去掉一個(gè)或多個(gè)的話，這樣的解析就是軟解析。軟解析分為以下三種類型。?
  1) 第一種是某個(gè)session發(fā)出的SQL語句與library cache里其他session發(fā)出的SQL語句一致。這時(shí)，該解析過程中可以去掉硬解析中的5和6這兩步，但是仍然要進(jìn)行硬解析過程中的2、3、4步驟：也就是表名和列名檢查、名稱轉(zhuǎn)換和權(quán)限檢查。?
  2) 第二種是某個(gè)session發(fā)出的SQL語句與library cache里該同一個(gè)session之前發(fā)出的SQL語句一致。這時(shí)，該解析過程中可以去掉硬解析中的2、3、5和6這四步，但是仍然要進(jìn)行權(quán)限檢查，因 為可能通過grant改變了該session用戶的權(quán)限。?
  3) 第三種是當(dāng)設(shè)置了初始化參數(shù)session_cached_cursors時(shí)，當(dāng)某個(gè)session對相同的cursor進(jìn)行第三次訪問時(shí)，將在該 session的PGA里創(chuàng)建一個(gè)標(biāo)記，并且該游標(biāo)即使已經(jīng)被關(guān)閉也不會(huì)從library cache中交換出去。這樣，該session以后再執(zhí)行相同的SQL語句時(shí)，將跳過硬解析的所有步驟。這種情況下，是最高效的解析方式，但是會(huì)消耗很大 的內(nèi)存。

?

2.查看sql解析的過程、內(nèi)部結(jié)構(gòu)

3.sql解析過程統(tǒng)計(jì)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。