首页 > 代码库 > 一次goldengate故障引发的操作系统hang起,HA自动切换

一次goldengate故障引发的操作系统hang起,HA自动切换

现场:

跑着数据库的主机A报警应用连接不上数据库,我们无法ssh到主机。第一反应是通过telnet到远程控制口,发现数据库资源和硬件资源在被切换到HA架构的主机B(备机,通常性能比主机A的差,抗不住应用)。此时HA已经把数据库切到了备机上,勉强抗着应用。 

分析:

一、查看故障机(主机A)的操作系统日志和oracle alert日志有大量的如下报错:

OS:

Mar 17 14:20:00 mktdb1 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap space to grow stack for pid 21868 (oracle) 
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 972610 daemon.error] fork: Not enough space
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 837760 daemon.error] monitored processes forked failed (errno=12)
Mar 17 14:20:13 mktdb1 last message repeated 3 times
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 972610 daemon.error] fork: Not enough space
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 837760 daemon.error] monitored processes forked failed (errno=12)
Mar 17 14:20:13 mktdb1 last message repeated 3 times
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 972610 daemon.error] fork: Not enough space
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 837760 daemon.error] monitored processes forked failed (errno=12)
Mar 17 14:20:13 mktdb1 last message repeated 3 times
Mar 17 14:20:13 mktdb1 Cluster.PMF.pmfd: [ID 972610 daemon.error] fork: Not enough space
DB alert_log:
 Errors in file /oracle/admin/mktdb/bdump/mktdb_psp0_15535.trc:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3 
至此,断定是由于交换空间被耗尽而导致的系统挂起,HA自动切换。但是具体是什么原因导致swap耗尽,或者说具体什么进程消耗了大量的swap,swap相关参阅:
点击打开链接 (http://blog.csdn.net/yiyuf/article/details/21458957)
二、继续查找大量消耗swap分区的进程:
root@mktdb1 # root@mktdb1 # prstat 
Please wait...
 PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 22879 oracle     11G  273M cpu8     0    0   0:13:47 3.6% extract/6
 18091 oracle     48G   48G sleep   59    0   0:10:05 1.6% oracle/1
 26397 oracle     48G   48G cpu529  59    0   0:00:05 1.0% oracle/1
 25929 oracle     48G   48G sleep   51    0   0:00:27 0.7% oracle/11
 21656 oracle     48G   48G sleep   40    0   0:00:31 0.7% oracle/11
 19298 oracle     48G   48G cpu528  59    0   0:01:19 0.6% oracle/11
 21610 oracle     48G   48G sleep   59    0   0:00:29 0.6% oracle/11
 23695 oracle     48G   48G sleep   22    0   0:00:27 0.6% oracle/11
 19583 oracle     48G   48G cpu512  11    0   0:01:29 0.6% oracle/11
 18770 oracle     48G   48G sleep   31    0   0:01:56 0.6% oracle/11
 21688 oracle     48G   48G sleep   22    0   0:00:42 0.6% oracle/11
prstat命令解释参见:点击打开链接 (http://blog.csdn.net/yiyuf/article/details/21470073)
从上面prstat结果可以看出,22879进程确实使用了大量的swap分区,用ps -ef |grep 22879看具体是什么进程:
  oracle 22879 19596  4 16:02:45 ?       22:53 /oracle/oradata/u2/gg/extract PARAMFILE /oracle/oradata/u2/gg/dirprm/extcf.prm 
到此就很明确了。查看ogg状态,一直卡在一个某个大事物上,而分析读取队列(或归档日志)时需要(消耗)了大量的内存。
 
既然排查不是主机A的硬件问题,立即把库切回主机A,恢复业务

一次goldengate故障引发的操作系统hang起,HA自动切换