【文章內(nèi)容簡介】 _object_cache order by sharable_mem desc) where size_rank = 3 order by namespace, size_rank / 轉(zhuǎn)儲 library cache oracle提供了命令可以對 library cache中的內(nèi)容進行轉(zhuǎn)儲。于是我們可以對library cache進行轉(zhuǎn)儲，從而對上面所說的 library cache的內(nèi)容進行驗證。 ALTER SESSION SET EVENTS 39。immediate trace name library_cache level N39。 這里的 N可以取的值分別為： 1 轉(zhuǎn)儲 library cache的統(tǒng)計信息 2 轉(zhuǎn)儲 hash表的匯總信息 4 轉(zhuǎn)儲 library cache object的基本信息 8 轉(zhuǎn)儲 library cache object的詳細信息 16 轉(zhuǎn)儲 heap size的信息 32 轉(zhuǎn)儲 heap的詳細信息 在測試之前，我們先創(chuàng)建一個測試表，然后再顯示該表的數(shù)據(jù)。從而在 library cache中放入一些數(shù)據(jù)。 打開跟蹤文件可以看到類似這樣的信息，這實際就是 v$librarycache里記錄的信息，只不過 v$librarycache中記錄的是根據(jù)下面的信息合并匯總以后得到的。 我們分別以 level 1 32分別對 library cache進行轉(zhuǎn)儲，生成的轉(zhuǎn)儲文件分別以 16和 32來表示。 打開 4文件，然后直接查找“ select object_id,object_name from sharedpool_test”， 因為我們前面說到過，對于 SQL語句來說，整個 SQL語句的文本就是 library cache object的名稱。于是，我們可以發(fā)現(xiàn)類似下圖四所示的內(nèi)容： 這里是 BUCKET 105702。該 bucket上只掛了一個對象，其對象句柄號為2cd433f8。在這個對象句柄里存放了很多信息，這里可以看到該對象的namespace為 CRSR，也就是 SQL AREA。可以看到該 SQL語句的 hash值為4d57861815002bfb42d03c9d2ecb9ce6。我們還可以看到很復雜的 flags字段，它會包括很多標記，比如 RON表示只讀（ Read Only）， SML表示當前句柄尺寸比較?。?Small）等。而下面的 lwt則表示正在等待 lock的對象列表（ Lock Waiters），對應 “ Lock Waiters”； ltm則表示臨時正在持有 lock的對象列表（ Lock Temporary），對應 “ Lock Owners”； pwt則表示正在等待 pin的對象列表（ Pin Waiters）對應 “ Pin Waiters”； ptm則表示臨時正在持有 pin的對象列表（ Pin Temporary），對應圖“ Pin Owners”。再往下看，可以看到 CHILDREN部分，這部分就是前面所說過的子游標的信息了。實際上，指向 heap 0的指針也位于這一部分，這個指針也就是 2cd43314。 這里顯示的是一個handle 尋找定位 heap 0 我們打開 8文件，查找 2cd43314， 可以看到如下圖所示的內(nèi)容。這就是heap 0中所包含的內(nèi)容?？梢钥吹皆?heap 0的 handle正是 2cd43314， type為CRSR。 還可以看到幾個重要的 table， 這些 table都是我們前面介紹過的，包括 DEPENDENCIES、 ACCESSES、 TRANSACTIONS。 從前面我們已經(jīng)知道dependency table記錄的是 SQL語句所依賴的對象，這里我們可以看到我們的 SQL語句依賴一個對象，同時該對象的 handle為 2cd44348 ， 很明顯，它一定指向 sharedpool_test表。同時，我們可以看到 transaction table所記錄的 oracle底層解析的對象的 handle也是 2cd44348 ， 它與 dependency table所記錄的對象是一樣的，說明這個表是實實在在的表，而不是一個同名詞。 我們可以看到最后一部分是 DATA BLOCKS，從我們前面介紹過的內(nèi)容可以知道這部分的記錄指向了其他的 heap內(nèi)存塊。我們從 data列上可以知道，該 SQL存在兩個相關的 heap，編號為 0和 6。我們知道， heap 0存放了 SQL語句本身所涉及到的對象以及若干種表等的信息，而 heap 6則存放了 SQL語句的文本、執(zhí)行計劃等。 我們可以到 32文件中查找 33e8ff08 （ heap 0） 和 310ac968 （ heap 6） 我們繼續(xù)在 8文件里查找 2cd44348 ， 也就是找到 library cache中記錄 SQL所引用的對象的部分。 我們可以看到類似下圖所示的內(nèi)容。從 name列中可以看到，該對象正是 sharedpool_test表，同時該表所在的 schema為 COST。而且從 type為 TABL也可以看到，對象 sharedpool_test是一個表。 如下圖所示。我們同時可以看到 owner的值，實際上這正是在圖五中的 object的代號。同時從 heap的 name處也可以看到， heap 0為 Pcursor，而 heap 6為 sql area，這也說明了這兩個不同的 heap所存放的不同內(nèi)容。 dictionary cache概述 遞歸調(diào)用 dictionary cache專門用來存放 SYS schema所擁有的對象的內(nèi)存區(qū)域。使用dictionary cache時以行為單位，而不像其他比如 buffer cache以數(shù)據(jù)塊為單位，因此 dictionary cache也叫做 row cache。 構造 dictionary cache的目的是為了加快解析 SQL語句的速度，因為 dictionary cache里存放了所有表的定義、 Storage信息、用戶權限信息、約束定義、回滾段信息、表的統(tǒng)計信息等。 而這些信息都是在解析過程中必須用到的。 假設 oracle在解析 SQL的過程中，發(fā)現(xiàn) dictionary cache里沒有該 SQL所引用的表的定義信息，則 oracle必須到磁盤上 system表空間里找到這個引用表的定義信息，并將這些定義信息加載到 dictionary cache里。這個從磁盤上獲取數(shù)據(jù)字典數(shù)據(jù)的過程就叫做遞歸 SQL（ Recursive SQL）。 通常來說，當我們執(zhí)行一條新的 SQL語句時，都會產(chǎn)生很多次的遞歸調(diào)用，也會產(chǎn)生很多的遞歸 SQL。 比如我們來下面這個例子。 假設 oracle在解析 SQL的過程中，發(fā)現(xiàn) dictionary cache里沒有該 SQL所引用的表的定義信息，則 oracle必須到磁盤上 system表空間里找到這個引用表的定義信息，并將這些定義信息加載到 dictionary cache里。這個從磁盤上獲取數(shù)據(jù)字典數(shù)據(jù)的過程就叫做遞歸 SQL（ Recursive SQL）。 通常來說，當我們執(zhí)行一條新的 SQL語句時，都會產(chǎn)生很多次的遞歸調(diào)用，也會產(chǎn)生很多的遞歸 SQL。 比如我們來下面這個例子。 從這里可以很明顯看到執(zhí)行該 SQL產(chǎn)生了1227次的遞歸調(diào)用，這 227次的遞歸調(diào)用將表 sharedpool_test相關的信息，比如列定義、統(tǒng)計信息等，都加載到了 dictionary cache里。當我們再次執(zhí)行該 SQL時，會發(fā)現(xiàn) recursive calls變成了 0，因為 dictionary cache里已經(jīng)包含解析 SQL所需要參照的數(shù)據(jù)字典了。 轉(zhuǎn)儲 dictionary cache 我們可以使用如下命令對 dictionary cache進行轉(zhuǎn)儲。 ALTER SESSION SET EVENTS 39。immediate trace name row_cache level N39。 這里的 N可以取的值分別為： 1 轉(zhuǎn)儲 dictionary cache的統(tǒng)計信息 。 2 轉(zhuǎn)儲 hash表的匯總信息 。 8 轉(zhuǎn)儲 dictionary cache中的對象的結構信息 。 如果對 level 1進行轉(zhuǎn)儲，可以看到轉(zhuǎn)儲出來的內(nèi)容，很明顯，就是 v$rowcache里的內(nèi)容。每一種數(shù)據(jù)字典都有一行記錄來表示。比如有 tablespace相關的數(shù)據(jù)字典等。 如果以 level 2轉(zhuǎn)儲的話，可以看到類似如下的內(nèi)容。這里有 34個 hash表對dictionary cache中的對象進行管理，每個 hash表都對應了一種數(shù)據(jù)字典，同時有一個名為 row cache objects的 latch來控制并發(fā)訪問。可以看到，v$latch_children里名為“ row cache objects”的記錄數(shù)量也是 34。 解析 SQL語句的過程 解析分為硬解析和軟解析。當一句 SQL第一次被執(zhí)行時必須進行硬解析。 第一步 當客戶端發(fā)出一條 SQL語句（也可以是一個存儲過程或者一個匿名 PL/SQL塊）進入 shared pool時（注意，我們從前面已經(jīng)知道， oracle對這些 SQL不叫做SQL語句，而是稱為游標（ cursor）。因為 oracle在處理 SQL時，需要很多相關的輔助信息，這些輔助信息與 SQL語句一起組成了游標）， oracle首先將 SQL文本轉(zhuǎn)化為 ASCII字符，然后根據(jù) hash函數(shù)計算其對應的 hash（ hash_value）。根據(jù)計算出的 hash值到 library cache中找到對應的 bucket，然后比較 bucket里是否存在該 SQL語句。 第二步 如果不存在，則需要按照我們前面所描述的，獲得 shared pool latch， 然后在shared pool中的可用 chunk鏈表（也就是 bucket） 上找到一個可用的 chunk，然后釋放 shared pool latch。 在獲得了 chunk以后，這塊 chunk就可以認為是進入了 library cache。 然后，進行硬解析過程。 第三步 硬解析包括以下幾個步驟： 1) 對 SQL語句進行語法檢查，看是否有語法錯誤。比如沒有寫 from等。如果有，則退出解析過程。 2) 到數(shù)據(jù)字典里校驗 SQL語句涉及的對象和列是否都存在。如果不存在，則退出解析過程。 3) 將對象進行名稱轉(zhuǎn)換。比如將同名詞翻譯成實際的對象等。如果轉(zhuǎn)換失敗，則退出解析過程。 4) 檢查游標里用戶是否具有訪問 SQL語句里所引用的對象的權限。如果沒有權限，則退出解析過程。 5) 通過優(yōu)化器創(chuàng)建一個最優(yōu)的執(zhí)行計劃。這一步是最消耗 CPU資源的。 6) 將該游標所產(chǎn)生的執(zhí)行計劃、 SQL文本等裝載進 library cache的若干個 heap中。 第四步 在硬解析的過程中，進程會一直持有 library cache latch，直到硬解析結束。 硬解析結束以后，會為該 SQL產(chǎn)生兩個游標，一個是父游標，另一個是子游標。父游標里主要包含兩種信息： SQL文本以及優(yōu)化目標（ optimizer goal）。父游標在第一次打開時被鎖定，直到其他所有的 session都關閉該游標后才被解鎖。當父游標被鎖定的時候是不能被交換出 library cache的，只有在解鎖以后才能被交換出 library cache，這時該父游標對應的所有子游標也被交換出 library cache。子游標包括游標所有的信息，比如具體的執(zhí)行計劃、綁定變量等。 第五步 子游標隨時可以被交換出 library cache， 當子游標被交換出 library cache時，oracle可以利用父游標的信息重新構建出一個子游標來，這個過程叫 reload。 可以使用下面的方式來確定 reload的比率： 父游標句柄 子游標句柄 HEAP 0 HEAP 6 子游標信息 一個父游標可以對應多個子游標。子游標具體的個數(shù)可以從 v$sqlarea的version_count字段體現(xiàn)出來。而每個具體的子游標則全都在 v$sql里體現(xiàn)。當具體的綁定變量的值與上次的綁定變量的值有較大差異（比如上次執(zhí)行的綁定變量的值的長度是 6位，而這次執(zhí)行的綁定變量的值的長度是 200位）時或者當 SQL語句完全相同，但是所引用的對象屬于不同的 schema時，都會創(chuàng)建一個新的子游標。 軟解析分類 1) 第一種是某個 session發(fā)出的 SQL語句與 library cache里其他 session發(fā)出的 SQL語句一致。這時，該解析過程中可以去掉硬解析中的 5和 6這兩步，但是仍然要進行硬解析過程中的 4步驟：也就是表名和列名檢查、名稱轉(zhuǎn)換和權限檢查。 2) 第二種是某個 session發(fā)出的 SQL語句與 library cache里該同一個 session之前發(fā)出的SQL語句一致。這時，該解析過程中可以去掉硬解析中的 5和 6這四步，但是仍然要進行權限檢查，因為可能通過 grant改變了該 session用戶的權限。 3