開宗明義，咱先介紹下SCM0。

SCM0(Statistics Collection and Management)進程：

(Distributed Lock Management )DLM從屬后臺進程，負責收集和管理全局入隊服務(wù)（GES）和全局緩存服務(wù)（GCS）的統(tǒng)計信息。如果在數(shù)據(jù)庫中啟用了DLM統(tǒng)計信息收集，此進程（scm0）才會存在。

今天本萎專家為啥多帶帶把這個進程挑出來單練，是因為本萎專家覺得SCM0在Oracle12CR2版本中是雞肋似的存在，摸之無感，棄之可惜。

SCM0存在消耗大量CPU資源的情況，點兒背的甚至遭遇SCM0導(dǎo)致實例關(guān)閉期間hang的BUG，具體BUG號大家去MOS上可以搜到，自己加強對MOS的搜索，對技能的提升也是一種促進，畢竟搜搜更健康啊，所以，這里就不浪費大家閱讀時間了。

下面本萎專家正式介紹一下遇到的2次關(guān)于SCM的問題（注：以下問題均發(fā)生在12CR2）。

一、關(guān)閉數(shù)據(jù)庫，實例停不下來（你說要是本萎專家能像SCM這樣該多好?。?/span>

當晚我們準備打補丁，采取滾動升級方式進行。

在停節(jié)點1 DB實例時，過了10分鐘都停不下來(正常耗時5分鐘左右)。查看db alert日志發(fā)現(xiàn)scm0進程始終處于active狀態(tài)，數(shù)據(jù)庫無法shutdown。

截圖如下：

這進程為啥一直這么堅挺著停不下來呢？

去MOS搜下發(fā)現(xiàn)有類似BUG：Bug 25348567 - Hang During Database Shutdown (Doc ID 25348567.8)

文章描述該BUG在18.1中才fixed。接下來看看有沒有workround，發(fā)現(xiàn)并沒有。。。

哎，站在男性的角度，真羨慕這進程。

時間緊迫，不能觸景生情，果斷采取KILL大法，把SCM0進程kill掉，數(shù)據(jù)庫立馬停下來了（想起了小時候的硬抓鐵布衫被迫的鏡頭）。

二、ORA-00600

最近監(jiān)控告警顯示有個庫報ORA-00600，這種內(nèi)部報錯往往跟BUG相關(guān)，是不能忽視大意的。

果斷利用自己練了30多年的手速把相關(guān)日志都down了下來，依托日志平臺再次檢索了一遍這個庫，發(fā)現(xiàn)該報錯為首次，之前沒有報過。不過報錯也不頻繁，一天也就個幾次。

本著萎專家的態(tài)度，依托日志平臺快速對全網(wǎng)的oracle數(shù)據(jù)庫進行了一遍ORA-600的搜索，看看有無其他庫報錯，運氣比較好，只有這一個庫報600。

回到報600的這套庫，查看等待事件，資源使用情況，集群狀態(tài)均正常。

業(yè)務(wù)也沒受影響，接下來可以節(jié)奏輕緩的分析到底啥原因?qū)е碌倪@個600？

啥？！又是SCM0。。。。。。

DB alert：

查看trace日志并未發(fā)現(xiàn)觸發(fā)SQL：

繼續(xù)查看堆棧信息發(fā)現(xiàn)ksliwat函數(shù)在調(diào)用VOS組件時報錯

在MOS搜了下，沒有找到對應(yīng)堆棧信息的BUG，甚至都沒ORA-00600 [ksliwat: bad wait time]類似的文章 。

好吧！看來本萎專家又撞大運了，碰到了SCM0觸發(fā)的未知BUG。

技術(shù)是為生產(chǎn)創(chuàng)造價值，而非產(chǎn)生熵增，既然在當前版本沒有對應(yīng)修復(fù)SCM的補丁，那我們應(yīng)該果斷選擇禁用DLM的統(tǒng)計信息收集。

通過設(shè)置如下參數(shù)實現(xiàn)，重啟生效。

alter system set "_dlm_stats_collect" = 0 scope = spfile sid = *;

注：禁用dlm_stats_collect(即設(shè)置為0)在12.2中沒有負面影響。因為在12.2中還沒有使用stats(默認情況下，將使用基于這些stats服務(wù)的關(guān)聯(lián)和緩存預(yù)熱的特性在12.2中也被禁用)。

好了，本次疑難分享到此結(jié)束，咱們下期再會。