开宗明义，咱先介绍下SCM0。
SCM0(Statistics Collection and Management)进程：
(Distributed Lock Management )DLM从属后台进程，负责收集和管理全局入队服务（GES）和全局缓存服务（GCS）的统计信息。如果在数据库中启用了DLM统计信息收集，此进程（scm0）才会存在。
今天本萎专家为啥单独把这个进程挑出来单练，是因为本萎专家觉得SCM0在Oracle12CR2版本中是鸡肋似的存在，摸之无感，弃之可惜。
SCM0存在消耗大量CPU资源的情况，点儿背的甚至遭遇SCM0导致实例关闭期间hang的BUG，具体BUG号大家去MOS上可以搜到，自己加强对MOS的搜索，对技能的提升也是一种促进，毕竟搜搜更健康啊，所以，这里就不浪费大家阅读时间了。
下面本萎专家正式介绍一下遇到的2次关于SCM的问题（注：以下问题均发生在12CR2）。
一、关闭数据库，实例停不下来（你说要是本萎专家能像SCM这样该多好啊）。
当晚我们准备打补丁，采取滚动升级方式进行。
在停节点1 DB实例时，过了10分钟都停不下来(正常耗时5分钟左右)。查看db alert日志发现scm0进程始终处于active状态，数据库无法shutdown。
截图如下：
这进程为啥一直这么坚挺着停不下来呢？
去MOS搜下发现有类似BUG：Bug 25348567 - Hang During Database Shutdown (Doc ID 25348567.8)
文章描述该BUG在18.1中才fixed。接下来看看有没有workround，发现并没有。。。
哎，站在男性的角度，真羡慕这进程。
时间紧迫，不能触景生情，果断采取KILL大法，把SCM0进程kill掉，数据库立马停下来了（想起了小时候的硬抓铁布衫被迫的镜头）。
二、ORA-00600
最近监控告警显示有个库报ORA-00600，这种内部报错往往跟BUG相关，是不能忽视大意的。
果断利用自己练了30多年的手速把相关日志都down了下来，依托日志平台再次检索了一遍这个库，发现该报错为首次，之前没有报过。不过报错也不频繁，一天也就个几次。
本着萎专家的态度，依托日志平台快速对全网的oracle数据库进行了一遍ORA-600的搜索，看看有无其他库报错，运气比较好，只有这一个库报600。
回到报600的这套库，查看等待事件，资源使用情况，集群状态均正常。
业务也没受影响，接下来可以节奏轻缓的分析到底啥原因导致的这个600？
啥？！又是SCM0。。。。。。
DB alert：
查看trace日志并未发现触发SQL：
继续查看堆栈信息发现ksliwat函数在调用VOS组件时报错
在MOS搜了下，没有找到对应堆栈信息的BUG，甚至都没ORA-00600 [ksliwat: bad wait time]类似的文章 。
好吧！看来本萎专家又撞大运了，碰到了SCM0触发的未知BUG。
技术是为生产创造价值，而非产生熵增，既然在当前版本没有对应修复SCM的补丁，那我们应该果断选择禁用DLM的统计信息收集。
通过设置如下参数实现，重启生效。
alter system set "_dlm_stats_collect" = 0 scope = spfile sid = '*';
注：禁用dlm_stats_collect(即设置为0)在12.2中没有负面影响。因为在12.2中还没有使用stats(默认情况下，将使用基于这些stats服务的关联和缓存预热的特性在12.2中也被禁用)。
好了，本次疑难分享到此结束，咱们下期再会。
