dataguard ORA-16037: user requested cancel of managed recovery operation

今天用脚本检测到主库跟备库未同步,收到邮件如下,立刻登录到备库去查看,发现备库有大量的归档未应用
查询备库日志
tlog
Errors in file /u01/app/oracle/diag/rdbms/xyxdbdg/xyxdb/trace/xyxdb_pr00_13300.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Errors in file /u01/app/oracle/diag/rdbms/xyxdbdg/xyxdb/trace/xyxdb_pr00_13300.trc:
ORA-16037: user requested cancel of managed recovery operation
Waiting for MRP0 pid 13282 to terminate

查询进程状态mrp
检查发现1319序号日志丢失,其他日志都存在
THREAD#  SEQUENCE# APPLIED
---------- ---------- ---------
     1     1310 YES
     1     1311 YES
     1     1312 YES
     1     1313 YES
     1     1314 YES
     1     1315 YES
     1     1316 YES
     1     1317 YES
     1     1318 YES
     1     1320 NO
     1     1321 NO

   THREAD#  SEQUENCE# APPLIED
---------- ---------- ---------
     1     1322 NO
     1     1324 NO
     1     1323 NO
     1     1325 NO
     1     1326 NO
     1     1327 NO
     1     1328 NO
     1     1329 NO
由于主库下面的归档已经删除,直接在主库里面将1319归档还原.
MAN> restore archivelog from logseq 1319 until logseq 1320;

Starting restore at 14-SEP-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=228 device type=DISK

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=1319
channel ORA_DISK_1: reading from backup piece /backup/oracle/backupsets/arch_e9qguamq_1_1_20150912
channel ORA_DISK_1: piece handle=/backup/oracle/backupsets/arch_e9qguamq_1_1_20150912 tag=ARC_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=1320
channel ORA_DISK_1: reading from backup piece /backup/oracle/backupsets/arch_ehqh0v2q_1_1_20150913
channel ORA_DISK_1: piece handle=/backup/oracle/backupsets/arch_ehqh0v2q_1_1_20150913 tag=ARC_BAK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 14-SEP-15

RMAN> quit

将归档拷贝至备库并注册
[oracle@xyxdbmaster arch]$ scp 1_1319_881695127.dbf oracle@192.168.8.7:/backup/oracle/arch/
oracle@192.168.8.7's password:
1_1319_881695127.dbf  
 SQL> alter database register physical logfile '/backup/oracle/arch/1_1319_881695127.dbf';
alter database register physical logfile '/backup/oracle/arch/1_1319_881695127.dbf'
*
ERROR at line 1:
ORA-16089: archive log has already been registered
显示已经注册
重新查看日志
 RFS[20]: Assigned to RFS process 128117
RFS[20]: Identified database type as 'physical standby': Client is ARCH pid 44148
RFS[20]: Opened log for thread 1 sequence 1319 dbid -1821781228 branch 881695127
Archived Log entry 1343 added for thread 1 sequence 1319 rlc 881695127 ID 0x0 dest 2:
Mon Sep 14 14:15:04 2015
Media Recovery Log /backup/oracle/arch/1_1319_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1320_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1321_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1322_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1323_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1324_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1325_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1326_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1327_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1328_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1329_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1330_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1331_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1332_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1333_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1334_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1335_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1336_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1337_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1338_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1339_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1340_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1341_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1342_881695127.dbf          
Media Recovery Log /backup/oracle/arch/1_1343_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1344_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1345_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1346_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1347_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1348_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1349_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1350_881695127.dbf
Media Recovery Log /backup/oracle/arch/1_1351_881695127.dbf
Media Recovery Waiting for thread 1 sequence 1352 (in transit)

查看进程状态
SQL> select process,status,thread#,sequence# from v$managed_standby
  2  ;

PROCESS   STATUS       THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH       CLOSING          1     1351
ARCH       CONNECTED          0        0
ARCH       CLOSING          1     1349
ARCH       CLOSING          1     1350
RFS       IDLE               0        0
RFS       IDLE               0        0
MRP0       WAIT_FOR_LOG          1     1352
RFS       IDLE               1     1352
RFS       IDLE               0        0

9 rows selected.
已经正常

主库上查看已经正常
select name,sequence#,applied from v$archived_log a where a.sequence#=(select max(sequence#) from v$archived_log);
col dest_name format A40
select dest_name,status,error from v$archive_dest where rownum<3;

NAME                                  SEQUENCE# APPLIED
-------------------------------------------------- ---------- ---------
xyxdbdg                               1351 YES
/backup/oracle/arch/1_1351_881695127.dbf          1351 NO

SQL> SQL>
DEST_NAME                    STATUS    ERROR
---------------------------------------- --------- --------------------
LOG_ARCHIVE_DEST_1               VALID
LOG_ARCHIVE_DEST_2               VALID

SQL> archive log list;
Database log mode            Archive Mode
Automatic archival            Enabled
Archive destination            /backup/oracle/arch/
Oldest online log sequence     1350
Next log sequence to archive   1352
Current log sequence            1352
总结:
出现此错误原因应该是主库rman策略
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
管理员在配置此策略的时候没有生效
其实出现此错误如果归档过多可以考虑在备库基于scn恢复
参考文档

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24486203/viewspace-1799124/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/24486203/viewspace-1799124/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在 Oracle 数据库中,DataGuard 是一种数据保护和灾难恢复解决方案,可以实现将主数据库的数据实时同步到备库中,以保证数据的高可用性和可靠性。在 DataGuard 的使用过程中,可能会出现同步异常的问题,下面我将介绍一些处理同步异常的方法和步骤。 1. 查看 DataGuard 状态 执行以下命令查看 DataGuard 的状态: ``` DGMGRL> show configuration; ``` 如果主库和备库的状态都是 `SUCCESS`,则表示 DataGuard 同步正常;如果有一方的状态是 `ERROR`,则表示同步异常。 2. 查看 DataGuard 错误日志 执行以下命令查看 DataGuard 的错误日志: ``` DGMGRL> show database <database_name> log transport; ``` 其中 `<database_name>` 是指备库的名称。如果出现同步异常,可以从日志中查看具体的错误信息,比如网络连接异常或者磁盘空间不足等。 3. 检查网络连接 如果同步异常是由于网络连接异常引起的,可以执行以下命令检查网络连接: ``` tnsping <database_name> ``` 其中 `<database_name>` 是指备库的名称。如果出现网络连接异常,可以根据错误信息进行调整,比如修改 tnsnames.ora 文件中的网络配置或者检查防火墙设置等。 4. 检查磁盘空间 如果同步异常是由于磁盘空间不足引起的,可以执行以下命令检查磁盘空间: ``` df -h ``` 如果磁盘空间不足,可以考虑清理无用的文件或者增加磁盘容量等。 5. 重新启动 DataGuard 如果以上方法都无法解决同步异常问题,可以考虑重新启动 DataGuard,执行以下命令: ``` DGMGRL> disable database <database_name>; DGMGRL> enable database <database_name>; ``` 其中 `<database_name>` 是指备库的名称。重新启动 DataGuard 会重新建立同步连接,可以解决一些难以排查的同步异常问题。 综上所述,以上是处理 DataGuard 同步异常的一些方法和步骤,可以根据具体情况进行调整和优化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值