这篇文章主要讲解了“怎么处理11g RAC节点二MMON进程异常”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么处理11g RAC节点二MMON进程异常”吧！

一早发现核心系统的DBtime监控阈值一直在某一个点平移，感觉有点不对劲。
因为我们的脚本依托dba_hist_snapshot试图的SNIP来做的。遂进行AWR报告的生成查看其SNAP_ID是否有异常；

2122019Sep201809:0012122119Sep201810:0012122219Sep201811:0012122319Sep201812:0012122419Sep201813:0012122519Sep201814:0012122619Sep201815:0012122719Sep201816:0012122819Sep201817:0012122919Sep201818:0012123019Sep201819:001

Specify the Begin and End Snapshot Ids

Entervalueforbegin_snap:昨天晚上系统确实是有CBC相关的等待，不过很快就恢复了。这是什么情况，难道是数据库归档满了，或者是mm进程down了？试着手动生成个SNAP_ID试试。发现是可以的。[oracle@bapdb2trace]$sqlplus/assysdbaSQL*Plus:Release11.2.0.4.0ProductiononThuSep2010:40:332018Copyright(c)1982,2013,Oracle.Allrightsreserved.Connectedto:OracleDatabase11gEnterpriseEditionRelease11.2.0.4.0-64bitProductionWiththePartitioning,RealApplicationClusters,AutomaticStorageManagement,OLAP,DataMiningandRealApplicationTestingoptions10:40:33SYS@bapdb2(bapdb2)>setline300pages100010:40:35SYS@bapdb2(bapdb2)>BEGIN10:40:372DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();10:40:373END;10:40:374/PL/SQLproceduresuccessfullycompleted.系统内的归档目录也很充足，不存在归档异常导致进程异常的情况；10:43:57SYS@b2(db2)>selectgroup_number,block_size,name,allocation_unit_size,state,type,total_mb,free_mb,offline_disksfromv$asm_diskgroup;GROUP_NUMBERBLOCK_SIZENAMEALLOCATION_UNIT_SIZESTATETYPETOTAL_MBFREE_MBOFFLINE_DISKS--------------------------------------------------------------------------------------------------------------------------14096SAS_ARCH1048576CONNECTEDEXTERN10240006179210节点一查看进程：[oracle@db1~]$ps-ef|grepmmgrid6634102017?00:33:47asm_mman_+ASM1grid6648102017?01:52:06asm_mmon_+ASM1grid6650102017?2-00:53:46asm_mmnl_+ASM1oracle8610102017?00:33:56ora_mman_db1oracle8650102017?3-11:28:35ora_mmon_db1oracle8655112017?4-07:20:56ora_mmnl_db1节点二查看进程：[oracle@bapdb2~]$ps-ef|grepmmoracle5435453982011:09pts/100:00:00grepmmgrid105256102017?00:23:52asm_mman_+ASM2grid105295102017?01:15:06asm_mmon_+ASM2grid105312102017?1-03:49:26asm_mmnl_+ASM2oracle106889102017?00:28:00ora_mman_db2oracle106927102017?3-04:47:42ora_mmnl_db2发现节点二的MMON进程DOWN了。从ALERT日志进行搜索：TueSep1903:49:002017MMONstartedwithpid=36,OSid=8650TueSep1903:49:002017MMNLstartedwithpid=37,OSid=8655TueSep1904:01:472017MMONstartedwithpid=36,OSid=106923TueSep1904:01:472017MMNLstartedwithpid=37,OSid=106927这个id为106923的进程确实是异常了。之前处理过类似的情况，可以在节点二直接启动MMON相关进程；SQL>altersystemenablerestrictedsession;Systemaltered.SQL>altersystemdisablerestrictedsession;Systemaltered.同时Alert日志也给出了反馈；ThuSep2011:10:282018StoppingbackgroundprocessMMNLStartingbackgroundprocessMMONStartingbackgroundprocessMMNLThuSep2011:10:292018MMONstartedwithpid=37,OSid=55936ThuSep2011:10:292018MMNLstartedwithpid=236,OSid=55938ALTERSYSTEMenablerestrictedsession;minact-scn:Inst2isaslaveinc#:16mmonproc-id:55936status:0x2minact-scnstatus:grec-scn:0x0026.4dcf0d36gmin-scn:0x0026.4dcf0d36gcalc-scn:0x0026.4dcf1208ThuSep2011:11:052018ALTERSYSTEMdisablerestrictedsession;ThuSep2011:13:252018LGWR:Standbyredologfileselectedforthread2sequence154126fordestinationLOG_ARCHIVE_DEST_3再次查看进程启动正常11:10:29SYS@db2(xxxdb2)>!ps-ef|grepmmoracle559361011:10?00:00:00ora_mmon_db2oracle559381011:10?00:00:00ora_mmnl_db2grid105256102017?00:23:52asm_mman_+ASM2grid105295102017?01:15:06asm_mmon_+ASM2grid105312102017?1-03:49:26asm_mmnl_+ASM2oracle106889102017?00:28:00ora_mman_db2追查了一下MMON进程的trc文件，发现最下面有这一条：***2018-09-1918:46:41.432minact-scnslave-status:grec-scn:0x0026.4db016c0gmin-scn:0x0026.4db016c0gcalc-scn:0x0026.4db0273cminact-scnslave-status:grec-scn:0x0026.4dbdde59gmin-scn:0x0026.4dbdde59gcalc-scn:0x0026.4dbdf492***2018-09-1918:56:44.302minact-scnslave-status:grec-scn:0x0026.4dca45dbgmin-scn:0x0026.4dca45dbgcalc-scn:0x0026.4dca5990***2018-09-1919:01:37.026error28detectedinbackgroundprocessOPIRIP:Uncaughterror447.Errorstack:ORA-00447:fatalerrorinbackgroundprocessORA-00028:yoursessionhasbeenkilled

感谢各位的阅读，以上就是“怎么处理11g RAC节点二MMON进程异常”的内容了，经过本文的学习后，相信大家对怎么处理11g RAC节点二MMON进程异常这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！