RAC中一个节点的LMD0进程 CPU一直100%
早晨看到一个进程cpu100%,业务那边经常有业务失败,检查发现该进程是 LMD0进程。但是告警日志没有任何问题,通过MOS和google,没搜到什么好的结论和解决办法。
附件是LMD0为100%的第一个节点的AWR报告和LMD0的TRACE,请刘大指点一下,如何诊断。
另外,机器本身系统配置应该也有问题,操作系统参数配置的内存为500G,实际SGA没有那么大,所以
操作系统本身内存在不断消耗,并且看不到回收。 还有,LMS进程的trace里面,是没有任何错误 感觉应用有点奇葩
例如 1jh42sn8hdfx8 这样的语句
平均等待 enq:TX 非常长的 行锁等待,其中必有蹊跷
EventWaitsTime(s)Avg wait (ms)% DB timeWait Class
enq: TX - row lock contention241,757,7577323985699.10Application
DB CPU12,4050.70
SQL*Net message from dblink341,9451,14930.06Network
DFS lock handle18,116597330.03Other
rdbms ipc reply15,775267170.02Other
SELECT * FROM CMQ_MSGLOCK WHERE ID = 1 FOR UPDATE
CMQ_MSGLOCK 表有多少行记录?其中ID=1的有多少行? Maclean Liu(刘相兵 发表于 2015-4-10 12:33 static/image/common/back.gif
SELECT * FROM CMQ_MSGLOCK WHERE ID = 1 FOR UPDATE
CMQ_MSGLOCK 表有多少行记录?其中ID=1的有多少行? ...
这个是一个常量锁定,会一直锁 Maclean Liu(刘相兵 发表于 2015-4-10 12:33 static/image/common/back.gif
SELECT * FROM CMQ_MSGLOCK WHERE ID = 1 FOR UPDATE
CMQ_MSGLOCK 表有多少行记录?其中ID=1的有多少行? ...
是应用中间件CMQ的一条语句,要一直锁定,所以这个是正常的 Segments by Row Lock Waits
% of Capture shows % of row lock waits for each top segment compared
with total row lock waits for all segments captured by the Snapshot
Owner Tablespace Name Object Name Subobject Name Obj. Type Row Lock Waits % of Capture
AMS AMS_IDX T_AMS_AC_IF_ADT_BNO_IDX INDEX 1,150 41.58
AIS AIS_IDX T_AIS_GL_DTL_D_IDX3 INDEX 184 6.65
AMS AMS_IDX AMS_TEST_T_AC_PMT_DTL_IDX INDEX 152 5.50
AIS AIS_IDX T_AIS_GL_DTL_D_IDX2 P201505 INDEX PARTITION 136 4.92
AMS AMS_IDX CMQ_MSGPROD_CCMMIDX INDEX 132 4.77
这个索引是不是有问题,查看一下。 T_AMS_AC_IF_ADT_BNO_IDX 在Segments by Row Lock Waits
是最大值,这个索引是不是有问题,查看一下。 T_AMS_AC_IF_ADT_BNO_IDX 是T_AMS_AC_IF的索引
是不是这个语句引起的row lock waits
UPDATE T_AMS_AC_IF N SET N.ADT=:1 , N.ADT_BNO=:2 , N.LAST_BL=N.SMT_BLK_AMT+N.BL+N.RC_BLK_AMT WHERE N.ADT=:3 AND N.ADT_BNO=:4 AND N.AC_NO=:5
页:
[1]