情况一：大量crsctl.bin 等待crs all completion
情况描述：
12.2的RAC环境， CPU使用率高，使用top可以看到有大量crsctl.bin进程导致， sys cpu占用了大部分， 如果从数据库内查看等待会伴随着wait event “crs call completion”, 有时还会级联堵塞出现wait event “library cache lock”。crs call completion是当db instance layer 通知 CRS daemon process。
在11G时有时会因为 bug 10019726, bug 12615394, bug 12767563 出现这样的情况， 但是在11.2.0.3 已修复，解决方式：
12C r2 给这个问题可以尝试配置hidden parameter “_notify_crs”=false， 调过crs通知等待，理论该调整不会给数据库性能问题带来影响。但是调整这个参数还是有一定的影响需要了解，下面整理一下”_notify_crs” 参数相关注意事项。修改参数影响
1、 将_notify_crs设置为 false 可防止 ASM 实例在挂载磁盘组时通知 CRS 守护进程。磁盘组在 ASM 中成功创建，但它不会反映在 OCR （crsctl stat res -t） 中。
2、当隐藏参数"_notify_crs"设置为 FALSE 时，数据库不使用在注册到 CRS 的数据库资源中指定其位置的password文件。因此，作为 sysdba 进行连接失败与 ORA-1017
当"_notify_crs"设置为 FALSE 时，数据库不使用数据库资源指定的password文件，而是使用默认位置，在默认位置创建或复制password文件，$ORACLE_HOME/dbs/orapw<ORACLE_SID>
情况二：多个StrictHostKeyChecking=no
$ ps -ef|grep ifconfig
root 19141 1 0 06:25 ? 00:00:00 sh -c /bin/su -l grid -c "/usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a" 2>&1
root 13442 18941 99 06:25 ? 06:07:08 /bin/su -l grid -c /usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a
grid 26911 23166 0 12:32 pts/1 00:00:00 grep ifconfig
root 23231 1 0 Jan23 ? 00:00:00 sh -c /bin/su -l grid -c "/usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a" 2>&1
root 62143 23231 99 Jan23 ? 14:29:31 /bin/su -l grid -c /usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a
root 77112 1 0 10:30 ? 00:00:00 sh -c /bin/su -l grid -c "/usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a" 2>&1
root 75443 77170 99 10:30 ? 02:02:37 /bin/su -l grid -c /usr/bin/ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=5 ANBOB2 /sbin/ifconfig -a
$top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
62254 root 25 0 98.8m 1392 1104 R 100.0 0.0 851:33.36 su
57942 root 25 0 98.8m 1400 1104 R 99.9 0.0 349:10.86 su
52171 root 25 0 98.8m 1404 1104 R 99.9 0.0 104:39.33 su解决方案
根据MOS note# 2340905.1记录是Bug 24692439 : LNX64-12.2-DIAGSNAP: AUXILIARY CMDS GENERATED BY DIAGSNAP WOULD HOG CPU FOREVER。
解决方法是禁用diagsnap,然后手动kill掉这些su 进程。
禁用diagsnap
以GI owner身份执行.(grid)
$GI_HOME/bin/oclumon manage -disable diagsnap
Diagsnap option is successfully Disabled on ANBOB1
Diagsnap option is successfully Disabled on ANBOB2
Successfully Disabled diagsnap
如果12.1 版本上执行不成功，需要以root身份执行diagsnap.pl deregister” ，手动编辑每个节点的$GI_HOME/crf/admin/crf<hostname>.ora文件，确认PSTACK=DISABLE 和DIAGSNAP=DISABLE什么是diagsnap？
为了当分析节点重启和节点驱逐故障时，避免因缺少网络和操作系统级信息无法定位，引入diagsnap并与GI集成，diagsnap是12.1.0.2 GI引入的新进程，CHM的osysmod管理diagsnap资源，该资源收集弥补CHM通常不收集的其他OS统计信息。diagsnap采集是每15分钟自动运行一次， 有些特列情况也会触发diagsnap, 如下：
1. cssd发现丢失网络心跳时
2. gipcd发现 interfaces启停变化时
3. gipcd rank events
diagsnap会调用执行下面的操作系统命令：
iostat
netstat
lsof <gipcd pid/ocssd pid/crsd pid/ohasd pid>
arp
ifconfig
ping over the private interconnect
tcpdump
top情况三：SCM0
(Distributed Lock Management )DLM Statistics Collection and Management从属（SCM0）后台进程负责收集和管理全局入队服务（GES）和全局缓存服务（GCS）的统计信息。如果在数据库中启用了DLM统计信息收集此进程（scm0）才会存在， 但是官方描述在12.2版本，默认即使收集了DLM statistics在12.2版本中的use these stats service based affinity and cache warmup功能也是禁用的，只是为了后续版本准备，所以在禁用该进程不会影响12C r2版本。解决方式：
原因是bug 24590018 – RAC PERF: SCM0 PROCESS USING 100% CPU, FG’S USING ~80% SYS CPU POSTING SCM0
要解决此问题，必须停用DLM统计信息收集，或者手动kill scm0进程并此进程会自动启动。
禁用DLM统计信息收集方法:
SQL> alter system set "_dlm_stats_collect" = 0 scope = spfile sid = '*';
注意_dlm_stats_collect参数更改需要重新启动数据库。
另一种是确定相应scm0进程的进程id，并用kill -9关闭它。关闭后，此进程将自动重启。
[root@anbob01 ~]# ps -ef|grep scm
oracle 11762 1 0 May22 ? 00:02:28 ora_scm0_ANBOB1
[root@anbob01 ~]# kill -9 11762
建议在安装12C R2时就配置如下参数：
alter system set “_dlm_stats_collect” = 0 scope = spfile sid = ‘*’;
