Oracle latch:library cache 致使 數據庫掛起 故障

收到一條手機告警短信,看了一下,放那沒管了,一天能收到上百條的告警信息,麻木掉了,過了幾分鐘,又收到一條相同庫的報警,仍是看了一眼,不過此時內心已經提升警戒了,第三次收到報警,知道這個庫確定出問題了,迅速連內網。數據庫

Sun 5.1 的系統,DB 11.2.0.2. 登錄的過程是個苦逼的過程,登錄30多秒才登錄成功,不用查看就知道CPU 確定100%了。session

oracle@h25k06dc$vmstat 5 5oracle

kthr memory page disk faults cpu運維

r b w swap free re mf pi pofr de sr m5 m6 m7 m1 in sycs us sy id函數

0 0 0120080864 63113000 122 721 266 175 174 0 0 5 24 0 5 1590 7847 3308 9 1 90對象

308 0 0117751600 66781304 194 616 0 9 9 0 0 3 0 1 3 2444 81080 46681 97 3 0進程

305 0 0117752440 66782280 160 556 0 6 6 0 0 5 0 0 4 2430 84445 40509 97 3 0事件

310 0 0117751872 66780480 165 718 0 2 2 0 0 3 0 0 3 2399 74438 42603 97 3 0io

307 0 0117752296 66782264 77 344 0 3 2 0 0 3 0 0 3 2319 82768 42063 97 3 0編譯

第一列300+的數字很顯眼,通常幾十就很緊張了。不過還見過600多的,也就沒什麼大驚小怪,按步驟來,看等待事件:

select event,count(*) fromv$session group by event;

命令敲下去,幾分鐘都沒反應,不過不能繼續等下去,新開了一個窗口,準備作個hanganalyze,杯具的一樣沒反應。

等了一會,仍是沒反應,這種事情遇到多了,也不那麼慌了,期間還接了局方的幾個電話,掛了電話,繼續奮鬥,開來只能用最後一招了,kill 進程。

本打算用一條命令搞定的:

ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9

保險期間,先ps了一下:

ps -ef|grepLOCAL=NO|grep -v grep|awk '{print $2}'

返回幾百個,有點多,通常來講,若是數據能正常鏈接和操做,最好先定位出具體的session,在把這個session對應的進程kill 掉就ok了,明顯今天早上人品欠佳,定位不出來。

這裏LOCAL=NO 的進程太多,不能所有kill 掉,也是沒辦法,一次kill 部分,看可能緩解一下。

每次隨機的kill 一批,kill 到第三批的時候,總算有反應了。

oracle@h25k06dc$vmstat 5 5

kthr memory page disk faults cpu

r b w swap free re mf pi pofr de sr m5 m6 m7 m1 in sycs us sy id

0 0 0 120078656 63119016 122 722 266 176 176 00 5 24 0 5 1597 7899 3333 9 1 90

0 0 0 118483144 67508104 61 1159 0 0 0 0 0 220 0 22 5349 28461 13297 55 4 42

0 0 0 118487648 67513760 38 726 0 0 0 0 0 0 0 0 0 4435 24430 10103 52 4 44

0 0 0 118488136 67514264 36 482 0 0 0 0 0 7 0 0 7 3451 22461 10015 51 3 47

0 0 0 118489392 67515480 58 630 0 0 0 0 0 1 0 0 14087 29228 12237 49 4 47

看了一下時間,處理過程大約花了20分鐘,有點長,反應速度還須要提升。迅速建立了一個快照,用來分析故障緣由:

這裏event 很明顯,latch:library cache。

當咱們對包,存儲過程,函數,視圖進行編譯的時候,Oracle就會在這些對象的handle上面首先得到一個library cache lock,而後再在這些對象的heap上得到pin,這樣就能保證在編譯的時候其它進程不會來更改這些對象的定義,或者將對象刪除。

當一個session對SQL語句進行硬解析的時候,這個session就必須得到librarycache lock。 這裏AWR也比較明顯,硬解析太高。

從v$active_session_history視圖裏抓了latch: library cache 的session 及SQL,有3個SQL 沒有使用綁定變量,致使硬解析太高。

SQL提交給運維,繼續關注數據庫,說不定這庫哪天又CPU 100%了。

相關文章
相關標籤/搜索