oracle dataguard archive gap后恢复
2018-07-08 14:28
375 查看
起因:源端数据库应用程序逻辑错误,导致重大量重试回滚,日产生归档300GB,异地备份在10Mbps的网速下,产生了archive gap;
解决流程:
1 查出备库当前的scn号
select current_scn from v$database; 1612480746
2 在主库生成基于备库scn的增量备份
--primary show all; run{ ALLOCATE CHANNEL d1 TYPE disk; set limit channel d1 kbytes=104857600; BACKUP INCREMENTAL FROM SCN 1612480746 DATABASE FORMAT 'J:\%U_for_stb.bk' include current controlfile for standby; }
3 传送日志到备库
--standby catalog start with 'e:\inc';
4 应用control file,增量备份集
restore standby controlfile to 'e:\control01.ctl' ; shutdown immediate; copy e:\control01.ctl E:\ORADATA\TCIS\CONTROL01.CTL copy e:\control01.ctl E:\ORADATA\TCIS\CONTROL02.CTL copy e:\control01.ctl E:\ORADATA\TCIS\CONTROL03.CTL
recover database noredo;
报错:
RMAN-03002: recover 命令 (在 07/08/2018 10:49:09 上) 失败 RMAN-06094: 数据文件5必须重新存储
启动原先的备库,select name from v$datafile
发现文件有重新rename的;有点梗;
5 修改数据文件位置
alter system set standby_file_management=manual; alter database rename file 'E:\ORADATA\TCIS\UBSS_INDX01.DBF' to 'd:\oradata\tcis\ubss_indx01.dbf'; alter database rename file 'E:\ORADATA\TCIS\UBSS_INDX02.DBF' to 'd:\oradata\tcis\ubss_indx02.dbf';
6 再次recover 5b4 database noredo
又报错,第16号文件不存在 RMAN-03002: recover 命令 (在 07/08/2018 10:49:09 上) 失败 RMAN-06094: 数据文件16必须重新存储
以老的控制文件启动,发现第16号文件是之后添加的
7 主库上备份16号文件
backup datafile 16 format 'j:\16.bak';
8 备库上恢复16文件
--primary catalog start with 'e:\inc'; restore datafile 16 ; recover database noredo;
RMAN-03002: recover 命令 (在 07/07/2018 10:44:11 上) 失败 ORA-19693: 已包括备份片段 E:\INC\CDT7BHIL_1_1_FOR_STB.BK recover失败,很名显,这个16号文件是之后恢复的,其scn大于之前做的备份片集
9 清理无效的备份片,再次重复2之后的步骤,backup ,restore controlfile,rename datafile,recover database ;
10 恢复完成后检查
复原参数
alter system set standby_file_management=auto;
启动recover
alter database recover managed standby database disconnect;
检查日志应用情况
SQL> select status,blocks,process,sequence# from v$managed_standby; STATUS BLOCKS PROCESS SEQUENCE# ------------ ---------- --------- ---------- CONNECTED 0 ARCH 0 CONNECTED 0 ARCH 0 CONN b60 ECTED 0 ARCH 0 CONNECTED 0 ARCH 0 IDLE 20480 RFS 45261 IDLE 20480 RFS 45262 IDLE 0 RFS 0 APPLYING_LOG 81560 MRP0 45248
检查归档,删除已应用的归档
select a.thread#, a.sequence#, a.applied,a.name from v$archived_log a, v$database d where a.activation# = d.activation# and a.applied='YES' order by 2;
相关文章推荐
- dos下用recover修复损坏的TXT文件
- 详谈innodb的锁(record,gap,Next-Key lock)
- go语言异常panic和恢复recover用法实例
- 一文读懂MySQL - MySQL必须掌握的技术点(上)
- mysql unique option prefix myisam_recover instead of myisam-recover-options的解决方法
- mysql中关于Myisam_recover自动修复的使用方法
- Bare Metal Recover
- dataguard 中standby有大量gap解决方法
- ORACLE恢复过程
- Recover through incarnations: RMAN-20208
- golang异常处理
- go panic与recover分析及错误处理
- 因修改SYS密码引起的gap问题修复
- Prime Gap
- Recover Rotated Sorted Array
- recover和restore的区别
- 手工消除dataguard的gap
- 解压缩报错tar: Error is not recoverable: exiting now
- 数据文件状态处于recover,恢复正常
- go语言之 panic, recover ——如何在go语言中优雅的处理错误