这篇文章主要讲解了“怎么处理11g RAC节点二MMON进程异常”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么处理11g RAC节点二MMON进程异常”
这篇文章主要讲解了“怎么处理11g RAC节点二MMON进程异常”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么处理11g RAC节点二MMON进程异常”吧!
一早发现核心系统的DBtime监控阈值一直在某一个点平移,感觉有点不对劲。
因为我们的脚本依托dba_hist_snapshot试图的SNIP来做的。遂进行AWR报告的生成查看其SNAP_ID是否有异常;
21220 19 Sep 2018 09:00 1
21221 19 Sep 2018 10:00 1
21222 19 Sep 2018 11:00 1
21223 19 Sep 2018 12:00 1
21224 19 Sep 2018 13:00 1
21225 19 Sep 2018 14:00 1
21226 19 Sep 2018 15:00 1
21227 19 Sep 2018 16:00 1
21228 19 Sep 2018 17:00 1
21229 19 Sep 2018 18:00 1
21230 19 Sep 2018 19:00 1
Specify the Begin and End Snapshot Ids
Enter value for begin_snap:
昨天晚上系统确实是有CBC相关的等待,不过很快就恢复了。这是什么情况,难道是数据库归档满了,或者是mm进程down了?试着手动生成个SNAP_ID试试。发现是可以的。
[oracle@bapdb2 trace]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Thu Sep 20 10:40:33 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
10:40:33 SYS@bapdb2(bapdb2)> set line 300 pages 1000
10:40:35 SYS@bapdb2(bapdb2)> BEGIN
10:40:37 2 DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
10:40:37 3 END;
10:40:37 4 /
PL/SQL procedure successfully completed.
系统内的归档目录也很充足,不存在归档异常导致进程异常的情况;
10:43:57 SYS@b2(db2)> select group_number,block_size,name,allocation_unit_size,state,type,total_mb,free_mb,offline_disks from v$asm_diskgroup;
GROUP_NUMBER BLOCK_SIZE NAME ALLOCATION_UNIT_SIZE STATE TYPE TOTAL_MB FREE_MB OFFLINE_DISKS
------------ ---------- ------------------------------ -------------------- ----------- ------ ---------- ---------- -------------
1 4096 SAS_ARCH 1048576 CONNECTED EXTERN 1024000 617921 0
节点一查看进程:
[oracle@db1 ~]$ ps -ef |grep mm
grid 6634 1 0 2017 ? 00:33:47 asm_mman_+ASM1
grid 6648 1 0 2017 ? 01:52:06 asm_mmon_+ASM1
grid 6650 1 0 2017 ? 2-00:53:46 asm_mmnl_+ASM1
oracle 8610 1 0 2017 ? 00:33:56 ora_mman_db1
oracle 8650 1 0 2017 ? 3-11:28:35 ora_mmon_db1
oracle 8655 1 1 2017 ? 4-07:20:56 ora_mmnl_db1
节点二查看进程:
[oracle@bapdb2 ~]$ ps -ef |grep mm
oracle 54354 53982 0 11:09 pts/1 00:00:00 grep mm
grid 105256 1 0 2017 ? 00:23:52 asm_mman_+ASM2
grid 105295 1 0 2017 ? 01:15:06 asm_mmon_+ASM2
grid 105312 1 0 2017 ? 1-03:49:26 asm_mmnl_+ASM2
oracle 106889 1 0 2017 ? 00:28:00 ora_mman_db2
oracle 106927 1 0 2017 ? 3-04:47:42 ora_mmnl_db2
发现节点二的MMON进程DOWN了。从ALERT日志进行搜索:
Tue Sep 19 03:49:00 2017
MMON started with pid=36, OS id=8650
Tue Sep 19 03:49:00 2017
MMNL started with pid=37, OS id=8655
Tue Sep 19 04:01:47 2017
MMON started with pid=36, OS id=106923
Tue Sep 19 04:01:47 2017
MMNL started with pid=37, OS id=106927
这个id为106923的进程确实是异常了。之前处理过类似的情况,可以在节点二直接启动MMON相关进程;
SQL> alter system enable restricted session;
System altered.
SQL> alter system disable restricted session;
System altered.
同时Alert日志也给出了反馈;
Thu Sep 20 11:10:28 2018
Stopping background process MMNL
Starting background process MMON
Starting background process MMNL
Thu Sep 20 11:10:29 2018
MMON started with pid=37, OS id=55936
Thu Sep 20 11:10:29 2018
MMNL started with pid=236, OS id=55938
ALTER SYSTEM enable restricted session;
minact-scn: Inst 2 is a slave inC#:16 mmon proc-id:55936 status:0x2
minact-scn status: grec-scn:0x0026.4dcf0d36 gmin-scn:0x0026.4dcf0d36 GCalc-scn:0x0026.4dcf1208
Thu Sep 20 11:11:05 2018
ALTER SYSTEM disable restricted session;
Thu Sep 20 11:13:25 2018
LGWR: Standby redo logfile selected for thread 2 sequence 154126 for destination LOG_ARCHive_DEST_3
再次查看进程启动正常
11:10:29 SYS@db2(xxxdb2)> !ps -ef |grep mm
oracle 55936 1 0 11:10 ? 00:00:00 ora_mmon_db2
oracle 55938 1 0 11:10 ? 00:00:00 ora_mmnl_db2
grid 105256 1 0 2017 ? 00:23:52 asm_mman_+ASM2
grid 105295 1 0 2017 ? 01:15:06 asm_mmon_+ASM2
grid 105312 1 0 2017 ? 1-03:49:26 asm_mmnl_+ASM2
oracle 106889 1 0 2017 ? 00:28:00 ora_mman_db2
追查了一下MMON进程的trc文件,发现最下面有这一条:
*** 2018-09-19 18:46:41.432
minact-scn slave-status: grec-scn:0x0026.4db016c0 gmin-scn:0x0026.4db016c0 gcalc-scn:0x0026.4db0273c
minact-scn slave-status: grec-scn:0x0026.4dbdde59 gmin-scn:0x0026.4dbdde59 gcalc-scn:0x0026.4dbdf492
*** 2018-09-19 18:56:44.302
minact-scn slave-status: grec-scn:0x0026.4dca45db gmin-scn:0x0026.4dca45db gcalc-scn:0x0026.4dca5990
*** 2018-09-19 19:01:37.026
error 28 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00028: your session has been killed
感谢各位的阅读,以上就是“怎么处理11g RAC节点二MMON进程异常”的内容了,经过本文的学习后,相信大家对怎么处理11g RAC节点二MMON进程异常这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是编程网,小编将为大家推送更多相关知识点的文章,欢迎关注!
--结束END--
本文标题: 怎么处理11g RAC节点二MMON进程异常
本文链接: https://www.lsjlt.com/news/64964.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0