CSS?initialization事件溯源

IT那活兒發(fā)布于2023-01-11 13:20 / 3840人閱讀

本文章，給大家分享一個經(jīng)典的案例：負(fù)載很低的數(shù)據(jù)庫，日常使用正常，巡檢時發(fā)現(xiàn)等待事件異常，建議剛接觸oracle數(shù)據(jù)庫的DBA，檢查時一定要重點關(guān)注等待事件。

問題：

巡檢發(fā)現(xiàn)數(shù)據(jù)庫Top 5 Timed Events中CSS initialization事件排在第一

環(huán)境：

Aix 6.1

Oracle 10.2.0.5單機

分析：

CSS initialization 代表有進(jìn)程在向CSS進(jìn)行注冊。但數(shù)據(jù)庫是單實例，且數(shù)據(jù)庫也沒有使用ASM，那么為什么會出現(xiàn)CSS initialization？

該等待事件雖然等待的次數(shù)不多，但是每次等待的時間卻很長，對系統(tǒng)性能肯定會有影響，所以必須進(jìn)行處理。接下來分析為什么會出現(xiàn)該等待事件。

首先檢查了數(shù)據(jù)庫的alert日志，發(fā)現(xiàn)日志里面沒有出現(xiàn)相關(guān)的錯誤。

然后找到該事件對應(yīng)的sql

查看具體的sql

發(fā)現(xiàn)相關(guān)的sql都是對v$asm_diskgroup視圖進(jìn)行查詢，因為查詢針對系統(tǒng)視圖的，懷疑可能是系統(tǒng)自帶的job執(zhí)行的，接下來檢查是哪個用戶在執(zhí)行sql：

該用戶是XXX系統(tǒng)監(jiān)控模塊連接數(shù)據(jù)庫使用的賬號，判斷是數(shù)據(jù)庫監(jiān)控在執(zhí)行該sql。

雖然該庫沒有使用asm，也不是RAC環(huán)境，查詢v$asm_diskgroup視圖也不應(yīng)該有問題啊，繼續(xù)分析。

手動執(zhí)行sql一次耗時2分鐘，檢查該sql的執(zhí)行計劃，沒有發(fā)現(xiàn)異常。

查詢metalink，Bug 10024824 – Database/session hang with ‘CSS initialization’ ，版本是10.2.0.5，而我們的數(shù)據(jù)庫版本也正好是這個版本。

文檔提示該bug只出現(xiàn)在RAC環(huán)境，由于OH/log//client目錄權(quán)限不對導(dǎo)致，建議改為771。

故障數(shù)據(jù)庫不是RAC環(huán)境的，檢查該目錄權(quán)限755

檢查另一套環(huán)境一樣的數(shù)據(jù)庫，目錄權(quán)限也是755，執(zhí)行同樣的sql，沒有問題。

如果按照bug來說，是權(quán)限的問題，那么client目錄一定是不能被寫入，所以才hang住。我們繼續(xù)檢查目錄和目錄中的文件。

查看目錄client的下文件css*.log，共66667，每天生成251個文件。每次查詢v$asm_diskgroup一次，就出現(xiàn)一個新的文件。另一套正常的數(shù)據(jù)庫該目錄下的文件只有168個。

文件內(nèi)容

再次測試運行一個查詢，并且用truss追蹤該進(jìn)程，發(fā)現(xiàn)了問題的根源：進(jìn)程大部分的時間是花在遍歷client下cssN.log文件

判斷在每次查詢v$asm_diskgroup的時候，都會在client下生成一個新的cssN.log文件（10.2.0.5才有，其他版本沒發(fā)現(xiàn)），生成的命名規(guī)則是前一個數(shù)字加1。因此，生成新的cssN.log文件時，需要遍歷整個client目錄下的cssN.log文件，才能知道最大的數(shù)字是多少，才能生成第N+1的文件。而在client下不斷生成大量文件，這個和oracle的一個unpublish bug 6004127 有關(guān)（ID 729349.1）。目前沒有patch，文檔上說解決的方法是用crontab定期清理client下的cssN.log、

清理超過3天的日志，再次查詢v$asm_diskgroup，耗時低于0.01秒。

解決方案：