oracle技术之一次RMAN备份报错的诊断过程(五)

今天检查数据库中的备份输出脚本时,发现RMAN备份出现了错误。


通过清除racgimon以及racgmain check进程来尝试解决问题。




在上一篇文章中清除了大量的僵死进程,但是这个方法只能治标而不能治本。


除了操作系统中看到的大量racgmain check进程之外,数据库中还可以看到一些racgimon会话:


SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME


 2  FROM V$SESSION


 3  WHERE PROGRAM LIKE 'racg%';


      SID USERNAME PROGRAM                      EVENT                                TIME


---------- -------- ---------------------------- ------------------------------ ----------


      123 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138


      124 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276142


      130 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276123


      132 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145


      147 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145


      148 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276105


      150 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276111


      151 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276051


      156 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276123


      279 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276142


      284 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138


      290 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276102


      297 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276138


      298 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276132


      306 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276105


      314 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client             0


      319 SYS      racgimon@ahrac1 (TNS V1-V3)  SQL*Net message from client        276145


已选择17行。


可以看到,除了其中一个之外,其他所有racgimon会话的等待时间都要比刚才清除的僵死进程时间要长,那么数据库现在共享资源被锁定的“元凶”很可能就是这些会话。但是由于对这个会话的任务不了解,而且kill这些会话的进程后果也不清楚,因此一直没有碰这些会话。经过前面的步骤,清除了大量的占用锁的会话以及处于等待的会话,问题仍然没有解决,说明刚才清除的会话都不是造成问题的根本所在。


为了避免清除掉这个racgimon进程,导致实例崩溃,在一个RAC测试环境尝试了一下杀掉racgimon会话对应的进程,发现实例并不会报错,而是随后自动启动了一个新的racgimon进程。


SQL> SELECT 'kill -9 ' || SPID


 2  FROM V$PROCESS


 3  WHERE ADDR IN


 4  (SELECT PADDR FROM V$SESSION


 5  WHERE PROGRAM LIKE 'racgimon%'


 6  AND SECONDS_IN_WAIT > 86400);


'KILL-9'||SPID


--------------------


kill -9 8042


kill -9 8219


kill -9 8221


kill -9 23136


kill -9 19091


kill -9 23140


kill -9 19441


kill -9 22653


kill -9 22655


kill -9 22686


kill -9 19406


kill -9 23171


kill -9 21666


kill -9 22004


kill -9 23134


kill -9 23169


已选择16行。


SQL> HOST


$ kill -9 8042


$ kill -9 8219


$ kill -9 8221


$ kill -9 23136


$ kill -9 19091


$ kill -9 23140


$ kill -9 19441


$ kill -9 22653


$ kill -9 22655


$ kill -9 22686


$ kill -9 19406


$ kill -9 23171


$ kill -9 21666


$ kill -9 22004


$ kill -9 23134


$ kill -9 23169


$ exit


在另一个实例上执行同样的操作:


SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME


 2  FROM V$SESSION


 3  WHERE PROGRAM LIKE 'racg%';


      SID USERNAME PROGRAM                        EVENT                                TIME


---------- -------- ------------------------------ ------------------------------ ----------


      113 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        277028


      142 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        276532


      197 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client             3


      309 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        278230


      324 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        277631


      325 SYS      racgimon@ahrac2 (TNS V1-V3)    SQL*Net message from client        276592


已选择6行。


SQL> SELECT 'kill -9 ' || SPID


 2  FROM V$PROCESS


 3  WHERE ADDR IN


 4  (SELECT PADDR FROM V$SESSION


 5  WHERE PROGRAM LIKE 'racgimon%'


 6  AND SECONDS_IN_WAIT > 86400);


'KILL-9'||SPID


--------------------


kill -9 10059


kill -9 10219


kill -9 4510


kill -9 9827


kill -9 10217


SQL> HOST


$ kill -9 10059


$ kill -9 10219


$ kill -9 4510


$ kill -9 9827


$ kill -9 10217


$ exit


问题仍然没有完全解决,看来只能将实例1上大量的racgmain check进程杀掉。


进程杀掉之后问题仍然没有解决,看来是数据库的状态存在问题了,现在唯一的方法就只能重启实例了,好在是RAC环境,可以先重启一个节点,然后再重启另一个。


没想到问题远比我想象的还要复杂,实例1通过svrctl命令关闭数据库没有相应,随后使用SHUTDOWN IMMEDIATE,也没有响应,最终导致所有的用户都无法登陆到实例,但是数据库并没有关闭,后台日志显示:


Wed May 27 12:25:13 2009


Starting background process EMN0


Wed May 27 12:27:13 2009


ERROR: Emon failed to start.


Shutting down instance: further logons disabled


Wed May 27 12:27:16 2009


ksvcreate: Process(m001) creation failed


Wed May 27 12:27:16 2009


Errors in file /opt/oracle/admin/tradedb/bdump/tradedb1_pmon_7173.trc:


ORA-00443: background process "EMN0" did not start


Wed May 27 12:27:19 2009


ksvcreate: Process(m001) creation failed


Wed May 27 12:28:19 2009


ksvcreate: Process(m001) creation failed


Wed May 27 12:29:19 2009


ksvcreate: Process(m001) creation failed


Wed May 27 12:30:19 2009


ksvcreate: Process(m001) creation failed


只好通过操作系统kill进程的方式,杀掉ORACLE进程,这是实例1关闭,但是实例2仍然启动,在实例2节点上执行rman错误依旧,看来必须重启整个数据库才能解决问题。


在实例2上使用SHUTDOWN ABORT:


bash-3.00$ sqlplus "/ as sysdba"


SQL*Plus: Release10.2.0.3.0 - Production on星期三5月27 12:45:56 2009


Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.




连接到:


Oracle Database10gEnterprise Edition Release10.2.0.3.0 - 64bit Production


With the Partitioning, Real Application Clusters, OLAP and Data Mining options


SQL> shutdown abort


ORACLE例程已经关闭。


数据库的状态明显不对,显然是数据库或者是cluster状态不正常造成的,为了彻底的解决问题,只好将cluster一起重启,关闭cluster时发现关闭进程居然也hang住了:


# /etc/init.d/init.crs stop


Shutting down Oracle Cluster Ready Services (CRS):


没有别的办法,只有通过KILL进程的方法来杀掉CRS进程,由于CLUSTER进程被异常关闭,服务器自动重启:


# May 27 13:01:23 ahrac1 root: [ID 702911 user.alert] Oracle CSSD failure.  Rebooting for cluster integrity.


既然节点1已经重启,节点2上的cluster状态也是不对的,不如将节点2上的crs也重启:


# /etc/init.d/init.crs stop


Shutting down Oracle Cluster Ready Services (CRS):


May 27 12:48:03.461 | INF | daemon shutting down


同样的问题出现,关闭CLUSTER时被挂起。


只好再次采用kill进程的方法,节点2也进行了重启。


两个节点全部重启后,最不幸的事情发生了,节点1没有完成启动,随后通过ping可以看到节点1处于活动状态,但是由于网络服务没有启动,导致节点1无法正常登陆。


节点2虽然可以顺利启动,但是尝试执行/etc/init.d/init.crs start命令启动cluster时发现错误信息:


bash-3.00# /etc/init.d/init.crs start


Startup will be queued to init within 30 seconds.


bash-3.00#


bash-3.00# ps -ef|grep ora


 oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd


 oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh


   root  2713  2435   0 13:14:10 pts/1       0:00 grep ora


bash-3.00# ps -ef|grep ora


 oracle  2823  2820   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot


 oracle  2820  2727   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2727


 oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd


 oracle  2822  2821   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot


 oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh


 oracle  2821  2714   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2714


 oracle  2819  2718   0 13:14:13 ?           0:00 sh -c /opt/oracle/product/10.2/crs/bin/crsctl check boot > /tmp/crsctl.2718


 oracle  2824  2819   0 13:14:13 ?           0:00 /opt/oracle/product/10.2/crs/bin/crsctl.bin check boot


   root  2832  2435   0 13:14:15 pts/1       0:00 grep ora


bash-3.00# ps -ef|grep ora


 oracle  2177  2170   0 13:11:48 ?           0:00 /usr/lib/ssh/sshd


 oracle  2179  2177   0 13:11:48 pts/1       0:00 -sh


   root  2840  2435   0 13:14:17 pts/1       0:00 grep ora


检查后台进程,发现CLUSTER相关进程并没有启动,检查/tmp目录下的crsctl.2714文件,发现错误信息:


bash-3.00# more /tmp/crsctl.2714


OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [No such device or address] [6]




但是这次等待了将近30分钟,节点2仍然无法访问OCR设备,看来问题越来越复杂了。


oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html

你可能感兴趣的:(oracle,oracle,oracle,rman,rman备份,RMAN备份报错)