客户的11.2 RAC环境中突然一个O002进程占用了100%的CPU，且一直不释放。
导致这个问题的原因应该是通过ASMCMD工具从ASM中拷贝了一个归档日志到本地磁盘，随后就发现一个ora_
[root@node-2 ~]# top top - 21:14:25 up 257 days, 4:33, 2 users, LOAD average: 1.69, 1.70, 1.56 Tasks: 994 total, 2 running, 991 sleeping, 0 stopped, 1 zombie Cpu(s): 2.2%us, 0.1%sy, 0.0%ni, 97.5%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 132060636k total, 131006336k used, 1054300k free, 535524k buffers Swap: 67108856k total, 1649936k used, 65458920k free, 39758892k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7622 oracle 25 0 50.6g 18m 16m R 100.0 0.0 9498:03 oracle 29924 root RT 0 304m 86m 54m S 2.0 0.1 5333:37 osysmond.bin 13804 root 15 0 13424 1844 828 R 1.6 0.0 0:00.16 top 29158 oracle 15 0 50.6g 10g 10g S 1.0 8.2 317:51.59 oracle 30337 root 15 0 971m 25m 13m S 1.0 0.0 1938:12 orarootagent.bi . . . 25 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/7 [root@node-2 ~]# ps -ef|grep 7622 oracle 7622 1 2 2011 ? 6-14:18:09 ora_o002_orcl2 root 13810 13645 0 21:14 pts/1 00:00:00 grep 7622 |
从数据库中查询，发现这个会话处于空闲等待状态：
[oracle@settle-2 ~]$ sqlplus / AS sysdba SQL*Plus: Release 11.2.0.2.0 Production ON Mon Apr 23 21:14:45 2012 Copyright (c) 1982, 2010, Oracle. ALL rights reserved. Connected TO: Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production WITH the Partitioning, REAL Application Clusters, Automatic Storage Management, OLAP, DATA Mining AND REAL Application Testing options SQL> SET pages 100 LINES 140 SQL> SELECT sid, username, program, STATUS, event FROM v$session WHERE paddr IN (SELECT addr FROM v$process WHERE spid = 7622); SID USERNAME PROGRAM STATUS EVENT ---------- ---------- ------------------------------ -------- ------------------------------ 529 oracle@node-2 (O002) ACTIVE class slave wait SQL> SELECT sql_id, prev_sql_id FROM v$session WHERE sid = 529; SQL_ID PREV_SQL_ID ------------- ------------- |
可以看到，这个会话一直处以空闲等待，而且没有执行任何SQL语句。
SQL> SELECT sid, serial# FROM v$session WHERE sid = 529; SID SERIAL# ---------- ---------- 529 43 SQL> EXEC dbms_monitor.session_trace_enable(529, 43, TRUE, TRUE) PL/SQL PROCEDURE successfully completed. SQL> EXEC dbms_monitor.session_trace_disable(529, 43) PL/SQL PROCEDURE successfully completed. |
通过设置TRACE，发现这个异常的会话并没有产生任何的TRACE文件。
由于ONNN进程是ASM连接池进程，当数据库在ASM上创建文件时，就会通过ONNN进程来完成，这个进程在日常很少会处于工作状态。
[oracle@node-2 ~]$ ps -ef|grep ora_o oracle 3831 1 0 Feb15 ? 00:00:03 ora_o004_orcl2 oracle 6350 1 0 2011 ? 00:00:08 ora_o000_orcl2 oracle 6358 1 0 2011 ? 00:00:08 ora_o003_orcl2 oracle 7475 1 0 2011 ? 00:00:00 ora_o001_orcl2 oracle 7622 1 2 2011 ? 6-15:38:56 ora_o002_orcl2 oracle 28211 28168 0 22:35 pts/1 00:00:00 grep ora_o [oracle@node-2 ~]$ KILL -9 7622 |
由于ONNN进程并非系统核心进程，且Oracle会在需要的时候自动分配ONNN进程，因此可以通过kill -9的方法来清除会话。结束进程后，top命令显示占用100%CPU资源的进程已经消失。
根据MOS的最新更新，这个问题属于BUG:12929268对应的文档为ora_o00n Process High CPU Usage in 11.2.0.2 [ID 1459376.1]。
根据文档的描述，如果ONNN进程空闲时间超过248.5天左右，也就是按照百分之一秒计算超过2G，就会导致ONNN进程陷入死循环中。Oracle对于进程的最大等待时间的定义并不是无符号的LONG，导致进程等待时间只有2G厘秒，而不是4G。
Oracle目前没有明确的fixed计划，而给出的解决方案和我上面的方法一致，就是KILL掉对应的进程。另外重启系统可以保证250天内不会再次出现同样的错误。