联系:手机/微信(+86 17813235971) QQ(107644445)
标题:因v$archived_log视图记录异常导致dg MRP进程异常
作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
版本信息
操作系统Linux 4.8 x86 数据库版本ORACLE 9.2.0.4
alert日志报错
MRP进程出现异常报ORA-00310/ORA-00334错误
………… Media Recovery Log /u01/oracle/oradata/lunar/arch/1_75.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_76.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_77.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_78.dbf Media Recovery Log /u01/oracle/oradata/xifenfei/redo02.log MRP0: Background Media Recovery terminated with error 310 Thu Nov 8 07:44:39 2012 Errors in file /u01/oracle/admin/lunar/bdump/lunar_mrp0_25625.trc: ORA-00310: archived log contains sequence 85; sequence 79 required ORA-00334: archived log: '/u01/oracle/oradata/xifenfei/redo02.log' Recovery interrupted. MRP0: Background Media Recovery process shutdown
trace文件
*** SESSION ID:(17.13) 2012-11-08 07:24:12.986 Background Managed Standby Recovery process started *** 2012-11-08 07:24:18.023 Managed Recovery: Active posted. *** 2012-11-08 07:41:03.171 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_64.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_65.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_66.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_67.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_68.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_69.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_70.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_71.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_72.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_73.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_74.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_75.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_76.dbf *** 2012-11-08 07:41:39.083 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_77.dbf *** 2012-11-08 07:44:39.171 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_78.dbf Media Recovery Log /u01/oracle/oradata/xifenfei/redo02.log Background Media Recovery terminated with error 310 ORA-00310: archived log contains sequence 85; sequence 79 required ORA-00334: archived log: '/u01/oracle/oradata/xifenfei/redo02.log' ----- Redo read statistics for thread 1 ----- Read rate (ASYNC): 21990Kb in 1221.38s => 0.02 Mb/sec Longest record: 1Kb, moves: 0/92129 (0%) Change moves: 34869/213735 (16%), moved: 2Mb ---------------------------------------------- *** 2012-11-08 07:44:39.404 Managed Recovery: Not Active posted. Background Media Recovery process shutdown *** 2012-11-08 07:44:39.406
猜想数据库恢复需要sequence为79的归档日志,但是该归档日志对应的为文件为redo02.log,而该redo02的seq为85所以使得MRP进程异常
使用rman尝试恢复
RMAN> recover database ; Starting recover at 08-NOV-12 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=8 devtype=DISK starting media recovery unable to find archive log archive log thread=1 sequence=79 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 11/08/2012 08:12:48 RMAN-06054: media recovery requesting unknown log: thread 1 scn 12286829427051
测试证明rman也无法正常的恢复该异常问题
验证猜想
SQL> select name from v$archived_log where SEQUENCE#=79; NAME ------------------------------------------------------------------- /u01/oracle/oradata/lunar/arch/1_79.dbf /u01/oracle/oradata/xifenfei/redo02.log /u01/oracle/oradata/lunar/arch/1_79.dbf SQL> select dest_id,name from v$archived_log where SEQUENCE#=79; DEST_ID NAME ---------- --------------------------------------------------- 2 /u01/oracle/oradata/lunar/arch/1_79.dbf 1 /u01/oracle/oradata/xifenfei/redo02.log 1 /u01/oracle/oradata/lunar/arch/1_79.dbf SQL> select sequence#,group# from v$log; SEQUENCE# GROUP# ---------- ---------- 86 1 85 2 87 3 SQL> select member from v$logfile where group#=2; MEMBER --------------------------------------------------------------- /u01/oracle/oradata/xifenfei/redo02.log
通过查询上面相关视图,证实了猜想是因为redo log被注册进入了v$archived_log导致该故障,解决该问题的思路是把redo log file从备库控制文件的v$archived_log视图中拿掉.具体方法是:
1.如果主库正常,那直接生成standby controlfile来实现
2.如果主库也是相同情况,那么先重建主库控制文件,然后重建standby controlfile来实现(该方法需要维护窗口)
解决问题思路
--查询主库,确定主库正常 SQL> select name from v$archived_log where SEQUENCE#=79; NAME ------------------------------------------------------------ /u01/oracle/oradata/xifenfei/archive/1_79.dbf lunar --重新创建standby controlfile ############################################################### 注:如果主库和备库的数据文件路径不完全一致, 建议通过设置db_file_name_convert来直接实现备库数据文件路径的转换, 而不建议通过alter database rename file来实现重命名 ############################################################### SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 2 '/u01/oracle/oradata/lunar/control01.ctl' reuse; Database altered. --重新启动备库 SQL> startup nomount; ORACLE instance started. Total System Global Area 353441008 bytes Fixed Size 451824 bytes Variable Size 184549376 bytes Database Buffers 167772160 bytes Redo Buffers 667648 bytes SQL> alter database mount standby database; Database altered. --开启日志应用 SQL> alter database recover managed standby database disconnect from session; Database altered. --alert日志 Thu Nov 8 08:28:16 2012 Completed: alter database recover managed standby database di Thu Nov 8 08:28:20 2012 Restarting dead background process QMN0 QMN0 started with pid=13 Thu Nov 8 08:29:45 2012 Fetching gap sequence for thread 1, gap sequence 79-87 Trying FAL server: xifenfei Media Recovery Log /u01/oracle/oradata/lunar/arch/1_79.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_80.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_81.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_82.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_83.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_84.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_85.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_86.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_87.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_88.dbf Media Recovery Waiting for thread 1 seq# 89
可以尝试在rman中使用
delete archivelog logseq 79;删除79号归档日志
然后在sqlplus中使用
ALTER DATABASE REGISTER LOGFILE ‘1_79.dbf’;
来注册归档日志