這篇文章主要介紹“怎么診斷SQL中l(wèi)ibrary cache: mutex X等待”，在日常操作中，相信很多人在怎么診斷SQL中l(wèi)ibrary cache: mutex X等待問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么診斷SQL中l(wèi)ibrary cache: mutex X等待”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
該機(jī)制是用于保護(hù)內(nèi)存結(jié)構(gòu)，在 library cache 中有許多內(nèi)存結(jié)構(gòu)需要 library cache: mutex X 的保護(hù)。
library cache 用來保存解析過的 cursor 相關(guān)的內(nèi)存結(jié)構(gòu)。
等待 library cache: mutex X 與之前版本的 latch:library cache 等待相同。library cache: mutex X 可以被很多因素引起，例如：（包括應(yīng)用問題，執(zhí)行計(jì)劃不能共享導(dǎo)致的高版本的游標(biāo)等），本質(zhì)上都是某個(gè)進(jìn)程持有 library cache: mutex X 太長時(shí)間，導(dǎo)致后續(xù)的進(jìn)程必須等待該資源。如果在 library cache 的 latch 或者 mutex 上有等待，說明解析時(shí)有很大的壓力，解析 SQL 的時(shí)間變長（由于 library cache 的 latch 或者 mutex 的等待）會(huì)使整個(gè)數(shù)據(jù)庫的性能下降。
由于引起 library cache: mutex X 的原因多種多樣，因此找到引起問題的根本原因很重要，才能使用正確的解決方案。
*大量的硬解析：過于頻繁的硬解析，會(huì)導(dǎo)致該等待。
*高版本的游標(biāo)：當(dāng)發(fā)生 High version count 時(shí)，大量的子游標(biāo)需要檢索，從而會(huì)引起該等待。
*游標(biāo)失效：游標(biāo)失效是指，保存在 library cache 中的游標(biāo)由于不可用，而從 library cache 中刪除。游標(biāo)失效是指某些改變導(dǎo)致內(nèi)存中的游標(biāo)不再有效。例如：游標(biāo)相關(guān)對象的統(tǒng)計(jì)信息搜集；游標(biāo)關(guān)聯(lián)表，視圖等對象的修改等。發(fā)生游標(biāo)失效會(huì)導(dǎo)致接下來的進(jìn)程需要重新載入該游標(biāo)。當(dāng)游標(biāo)失效過多時(shí)，會(huì)導(dǎo)致 ‘library cache: mutex X’ 等待。
*游標(biāo)重新載入：游標(biāo)重新載入是指本來已經(jīng)存在于 library cache 中，但是當(dāng)再次查找時(shí)已經(jīng)被移出 library cache（例如：由于內(nèi)存壓力），這時(shí)就需要重新解析并且載入該游標(biāo)。游標(biāo)重新載入操作不是一件好事，它表明您正在做一件本來不需要做的事情，如果您設(shè)置的 library cache 大小適當(dāng)，是可以避免游標(biāo)重新載入的。游標(biāo)重新載入的時(shí)候是不可以被進(jìn)程使用的，這種情況會(huì)導(dǎo)致 library cache: mutex X 等待。
*已知的 Bug。
library cache: mutex X – 用于保護(hù) handle。
library cache: bucket mutex X – 用于保護(hù) library cache 中的 hash buckets。
library cache: dependency mutex X – 用于保護(hù)依賴。
確認(rèn)是否存在一些改變：
a. 負(fù)載是否增長？
b. 是否有應(yīng)用、操作系統(tǒng)、中間件的改變？
該等待的出現(xiàn)的趨勢：
a. 確認(rèn)該等待是否在每天的固定時(shí)刻產(chǎn)生？
b. 是否做了一些操作觸發(fā)該等待？
生成問題發(fā)生時(shí)刻的 AWR 和 ADDM 報(bào)告，與基線或者正常時(shí)間段的 AWR 和 ADDM 報(bào)告比較，是否有負(fù)載，參數(shù)等的改變和不同。
有時(shí)使用systemstate dump 可以用來匹配已知的問題，例如：在 AWR 中沒有發(fā)現(xiàn)明顯的 SQL 時(shí)、通過 systemstate dump 捕獲阻塞進(jìn)程和被阻塞進(jìn)程的信息，可幫助發(fā)現(xiàn)潛在的問題。
當(dāng)systemstate dump 不適合收集時(shí)(因?yàn)樗馁Y源較多)。這時(shí)定期執(zhí)行如下 SQL，來確定哪些進(jìn)程和 SQL 在等待 library cache: mutex X。
select s.sid, t.sql_text
from vvsql t
where s.event like ‘%mutex%’
and t.sql_id = s.sql_id
正常情況下，我們可以從 AWR 中看到 library cache: mutex X 是 TOP 事件：
定位出硬解析和高版本的 SQL，點(diǎn)擊“Main Report”下的“SQL Statistics”鏈接
定位解析比較高的 SQL：
注意比較高的解析比例的 SQL，理想情況下解析和執(zhí)行的比例應(yīng)該很低，如果該比例很高說明應(yīng)用中沒有很好的使用游標(biāo)，游標(biāo)解析并且打開之后應(yīng)該保持打開狀態(tài)，與開發(fā)人員確認(rèn)如何保持游標(biāo)打開，避免下次執(zhí)行該 SQL 時(shí)重復(fù)解析。
下一步檢查 SQL 高版本：
檢查是否存在較高的硬解析，因?yàn)橛步馕鰰?huì)引起 SQL AREA 的重新裝載，通過 load profile 確定硬解析的數(shù)量。
2.對于 SQL AREA 的重新加載也要進(jìn)行檢查：
如果在 SQL AREA 上的重新加載次數(shù)很高，那么需要檢查游標(biāo)是否被有效共享（重新加載的次數(shù)是指被緩存在 shared pool 中，但是使用時(shí)已經(jīng)不在 shared pool 中）。如果游標(biāo)已經(jīng)有效共享，那么需要確認(rèn) shared pool 和 sga_target 是否足夠大，如果 shared pool 有壓力而沒有足夠的空間，那么有些緩存的游標(biāo)會(huì)被從 shared pool 中清除。如果游標(biāo)共享不充分，shared pool 會(huì)被這些不能被重用的游標(biāo)占滿，從而把那些可以重用的游標(biāo)擠出 shared pool，進(jìn)而引起在這些 SQL 重新執(zhí)行時(shí)需要重新加載。游標(biāo)共享充分，但由于 shared pool 空間過小也會(huì)引起可重用的游標(biāo)被清除從而引發(fā)硬解析。
在“Library Cache Activity”下檢查 invalidations，如果 invalidations 過高，需要確認(rèn)是否有大量的 DDL 操作，例如: truncate, drop, grants, dbms_stats 等
4.對于 11G，確認(rèn) cursor_sharing 不是 similar，因?yàn)樵撝狄呀?jīng)不建議使用，并且會(huì)引起 mutex X 等待
到此，關(guān)于“怎么診斷SQL中l(wèi)ibrary cache: mutex X等待”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
