CHM是Oracle11g的新特性,主要用来收集节点上的负载信息
[root@node3 ~]# ps -ef |grep crfroot 3127 1 1 22:10 ? 00:00:02 /u01/11.2.0/ghome/bin/ologgerd -M -d /u01/11.2.0/ghome/crf/db/node3
root 3488 3264 0 22:12 pts/0 00:00:00 grep crf
[root@node3 ~]# cd /u01/11.2.0/ghome/bin/
./crsctl stop res ora.crf -init
CRS-2673: Attempting to stop 'ora.crf' on 'node3'
CRS-2677: Stop of 'ora.crf' on 'node3' succeeded
[root@node3 bin]# ps -ef |grep crf
root 3609 3264 0 22:13 pts/0 00:00:00 grep crf
[root@node3 bin]#
感悟:通过这件事以后我会尝试发现问题解决问题
自己认为是共享磁盘不断通信造成的搞IO
想到了用另一种方法重建asm,比如openfile,SSD
这次因为前几天都是ok的,当然也有幸运成分,肯定是前几天没触发CHM进程
这次我就试着监控linux系统,然后试着找占用高的进程,然后再从rac方面找
也是幸运的我看到一篇文章,其实my support上应该也可以找到
本文介绍了如何通过监控系统找出占用高IO进程,并使用CRS控制停止ORA.CRF进程来解决Oracle11g系统中CHM特性导致的IO问题。通过分析ps-ef命令输出,发现并终止了不必要的进程,从而优化系统性能。
2017

被折叠的 条评论
为什么被折叠?



