最近一套12C庫出現(xiàn)大量cursor:mutex X異常等待的故障，借此機(jī)會在這里和大家分享下分析過程及后續(xù)處理。先簡單介紹下故障過程，一天數(shù)據(jù)庫突然等待事件異常告警，登上數(shù)據(jù)庫查看異常等待事件發(fā)現(xiàn)大量cursor:mutex X，基于優(yōu)先恢復(fù)業(yè)務(wù)的原則，將其kill之后數(shù)據(jù)庫恢復(fù)正常。后續(xù)開始對故障進(jìn)行分析及進(jìn)行后續(xù)處理，欲知詳情，請聽下面分解。

1、查看故障時(shí)段AWR：

發(fā)現(xiàn)cursor:mutex X異常等待事件占了54%的DBTIME

2、cursor：mutexx等待事件原理：

cursor正在被解析并嘗試以獨(dú)占(exclusive)模式獲取cursormutex時(shí)產(chǎn)生的等待即為cursor：mutexx。

引起問題的原因包括頻繁硬解析、highversioncount、cursor失效及未知BUG等。但本質(zhì)上是一些會話長時(shí)間持有互斥鎖，以至于其他會話不得不等待資源。如果在保護(hù)庫緩存結(jié)構(gòu)的latches/mutexes上發(fā)生爭用，這意味著解析面臨壓力。解析SQL需要更長的時(shí)間，因?yàn)樗鼰o法獲得所需的資源。這會延遲其他操作，并且通常會降低系統(tǒng)的速度。

查看問題剛出現(xiàn)時(shí)的歷史會話(DBA_HIST_ACTIVE_SESS_HISTORY)如下：

從上圖我們可以看到多個(gè)會話同時(shí)執(zhí)行SQL_ID:3t5xt2hkrchpy，a9xqubd880h5n，且堵塞源不停在變，會話相互之間發(fā)生cursor:mutex X等待。

3、查看故障時(shí)段的AWR：

從以上圖我們可以看到SQL_ID:3t5xt2hkrchpy執(zhí)行時(shí)間及CPU消耗TOP1，其SQL及其他SQL的版本數(shù)都很高。

4、查看故障時(shí)段做的hang分析日志如下：

通過hang分析日志我們可以看到Blcoking其他session的會話操作是查找子Currsor，所以故障大概率是由于子Cursor過多,進(jìn)行查找時(shí)發(fā)生等待導(dǎo)致。而產(chǎn)生大量的子Cursor的原因是NLSSettings。

普及下什么是versioncount？

一個(gè)SQL第一次執(zhí)行時(shí)，會進(jìn)行硬解析，同時(shí)創(chuàng)建parentcursor和childcursor。

當(dāng)這個(gè)SQL時(shí)再次執(zhí)行時(shí)，首先會對SQL語句進(jìn)行特殊的hash運(yùn)算，對應(yīng)生成一個(gè)hashvalue。Hashvalue存放在parentcursor中，然后會用這個(gè)hashvalue到paranetcursor的bucket中匹配，如果相同的hashvalue 已存在parentcursor里，則繼續(xù)遍歷這個(gè)childcursor，如果可重用，那么就沿用childcursor的信息，如果不能重用，就會重新生成一個(gè)新的childcursor。一個(gè)parentcursor下childcursor的總數(shù)，就是這個(gè)SQL的versioncount。

highversion count指的就是childcursor總數(shù)很高。在AWR報(bào)告中，默認(rèn)verioncount超過20的SQL就會顯示在orderby version count中。根據(jù)經(jīng)驗(yàn)versioncount如果超過100，可能就需要引起注意了。

5、綜上所述，我們發(fā)現(xiàn)本次故障大概率是由于highversion count導(dǎo)致，那為啥這么多SQL的versioncount都這么高呢，初步懷疑是觸發(fā)BUG了，我們這庫是CDB模式，并且多個(gè)PDB的字符集不一致，通過MOS查找到一篇類似的文章：

通過SR確認(rèn)有可能觸發(fā)BUG25054064，該BUG在2020年1月份的DBRU中fixed了，我們只需要打上

Patch31741641: DATABASE OCT 2020 RELEASEUPDATE12.2.0.1.201020即可，因?yàn)镈BRU都是累積的。

查看其readme提供的BUG修復(fù)的連接發(fā)現(xiàn)BUG25054064已在補(bǔ)丁集中。

6、打完補(bǔ)丁之后截止目前為止再沒出現(xiàn)過類似的故障，我們查看SQL的versioncount發(fā)現(xiàn)降低了一個(gè)數(shù)量級。

另外由于字符集不匹配導(dǎo)致的highversion count在DocID 2542447.1也詳細(xì)介紹了處理方法，用于緩解子Cursor過多查找緩慢導(dǎo)致的等待：

1)通過具體SQL_ID將其從sharedpool清除掉。

SQL>select address,hash_value,version_count from v$sqlarea wheresql_id=a9x5sbz88kmfh;

ADDRESSHASH_VALUE VERSION_COUNT
---------------- -----------------------
000000006BFFAC00 3498659280 2

SQL>exec dbms_shared_pool.purge(,C);
Ex:
SQL>exec dbms_shared_pool.purge(000000006BFFAC00,3498659280,C);

PL/SQLprocedure successfully completed.

2)將_cursor_obsolete_threshold參數(shù)設(shè)置為較低的值減少子Cursor數(shù)量，不過這個(gè)取決于應(yīng)用程序需求，_cursor_obsolete_threshold的默認(rèn)值是8192，可以將其設(shè)置為2048或1024，重啟生效。