使用基于scn的增量备份恢复DG备库

By 清欢 2018年04月25日

场景：主库定时清理归档任务失败，报错备库仍需要这些归档来应用不可删除，以下是报错信息:

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

查看备库alert日志出现了gap，如下：

Fetching gap sequence in thread 1, gap sequence 26-31

正常情况下，只需将主库未传送的归档copy到备库手工注册即可，但发现主库也没有有这部分归档，所以需要对备库进行恢复。以下将使用增量备份来恢复故障备库。

强制删除归档
RMAN> DELETE FORCE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
手工注册日志
SQL> ALTER DATABASE REGISTER LOGFILE '<PATH>';

在备库上关闭日志应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;Database altered.

确定增量备份的起始scn号（取以下查询结果中的最小SCN）

SQL> SELECT CURRENT_SCN FROM V$DATABASE;CURRENT_SCN
-----------
     917051SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN>0;MIN(FIRST_NONLOGGED_SCN)
------------------------SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0;no rows selected

创建增量备份

[oracle@odd backup]$ rman target /Recovery Manager: Release 11.2.0.3.0 - Production on Mon Mar 12 15:06:40 2018Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.connected to target database: PROD (DBID=382173196)RMAN> backup format '/home/oracle/backup/sdb_incre_%U.bkp' incremental from scn 917051 database;Starting backup at 12-MAR-18using channel ORA_DISK_1
backup will be obsolete on date 19-MAR-18
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/PROD/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/PROD/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/PROD/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/PROD/users01.dbf
channel ORA_DISK_1: starting piece 1 at 12-MAR-18
channel ORA_DISK_1: finished piece 1 at 12-MAR-18
piece handle=/home/oracle/backup/sdb_incre_07stjtq9_1_1.bkp tag=TAG20180312T151209 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35using channel ORA_DISK_1
backup will be obsolete on date 19-MAR-18
archived logs will not be kept or backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 12-MAR-18
channel ORA_DISK_1: finished piece 1 at 12-MAR-18
piece handle=/home/oracle/backup/sdb_incre_08stjtrc_1_1.bkp tag=TAG20180312T151209 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-MAR-18RMAN> backup format '/home/oracle/backup/sdb_%U.ctl' current controlfile for standby;Starting backup at 12-MAR-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including standby control file in backup set
channel ORA_DISK_1: starting piece 1 at 12-MAR-18
channel ORA_DISK_1: finished piece 1 at 12-MAR-18
piece handle=/home/oracle/backup/sdb_09stjtsc_1_1.ctl tag=TAG20180312T151316 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-MAR-18

传输至备库

[oracle@odd backup]$ ls
sdb_09stjtsc_1_1.ctl  sdb_incre_07stjtq9_1_1.bkp  sdb_incre_08stjtrc_1_1.bkp
[oracle@odd backup]$ scp * even:/home/oracle/backup/
oracle@even's password:
sdb_09stjtsc_1_1.ctl                                                                              100% 9632KB   9.4MB/s   00:00
sdb_incre_07stjtq9_1_1.bkp                                                                        100% 3344KB   3.3MB/s   00:01
sdb_incre_08stjtrc_1_1.bkp                                                                        100% 9632KB   9.4MB/s   00:00

手动注册备份文件记录入备库（如有catalog忽略此步骤，但主备备份目录需一致）

[oracle@even backup]$ rman target /Recovery Manager: Release 11.2.0.3.0 - Production on Mon Mar 12 15:15:10 2018Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.connected to target database: PROD (DBID=382173196)RMAN> catalog start with '/home/oracle/backup';using target database control file instead of recovery catalog
searching for all files that match the pattern /home/oracle/backupList of Files Unknown to the Database
=====================================
File Name: /home/oracle/backup/sdb_incre_08stjtrc_1_1.bkp
File Name: /home/oracle/backup/sdb_09stjtsc_1_1.ctl
File Name: /home/oracle/backup/sdb_incre_07stjtq9_1_1.bkpDo you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging doneList of Cataloged Files
=======================
File Name: /home/oracle/backup/sdb_incre_08stjtrc_1_1.bkp
File Name: /home/oracle/backup/sdb_09stjtsc_1_1.ctl
File Name: /home/oracle/backup/sdb_incre_07stjtq9_1_1.bkp

恢复备库控制文件

RMAN> startup force nomount;Oracle instance startedTotal System Global Area     627732480 bytesFixed Size                     1346756 bytes
Variable Size                499123004 bytes
Database Buffers             121634816 bytes
Redo Buffers                   5627904 bytesRMAN> restore standby controlfile from '/home/oracle/backup/sdb_09stjtsc_1_1.ctl';Starting restore at 12-MAR-18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISKchannel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
output file name=/u01/app/oracle/oradata/SBDB/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/SBDB/control02.ctl
Finished restore at 12-MAR-18

恢复数据库

RMAN> alter database mount;database mounted
released channel: ORA_DISK_1RMAN> recover database noredo;Starting recover at 12-MAR-18
Starting implicit crosscheck backup at 12-MAR-18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=55 device type=DISK
Crosschecked 7 objects
Finished implicit crosscheck backup at 12-MAR-18Starting implicit crosscheck copy at 12-MAR-18
using channel ORA_DISK_1
Finished implicit crosscheck copy at 12-MAR-18searching for all files in the recovery area
cataloging files...
cataloging doneList of Cataloged Files
=======================
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_11_fbcoqrjw_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_24_fbd9fs6y_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_16_fbd8p0xs_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_21_fbd8p3gh_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_25_fbd9mgvl_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_14_fbcoqv8f_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_23_fbd9fs8g_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_20_fbd8p0xy_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_18_fbd8p0f3_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_10_fbcoqrjb_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_32_fbd9nbfw_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_9_fbcorw11_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_13_fbcoqrkc_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_19_fbd8p0f8_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_15_fbd8p0y3_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_22_fbd9fsgt_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_17_fbd8p113_.arc
File Name: /u01/app/oracle/fast_recovery_area/SBDB/archivelog/2018_03_12/o1_mf_1_12_fbcoqrk7_.arcusing channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oracle/oradata/SBDB/system01.dbf
destination for restore of datafile 00002: /u01/app/oracle/oradata/SBDB/sysaux01.dbf
destination for restore of datafile 00003: /u01/app/oracle/oradata/SBDB/undotbs01.dbf
destination for restore of datafile 00004: /u01/app/oracle/oradata/SBDB/users01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/sdb_incre_07stjtq9_1_1.bkp
channel ORA_DISK_1: piece handle=/home/oracle/backup/sdb_incre_07stjtq9_1_1.bkp tag=TAG20180312T151209
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03Finished recover at 12-MAR-18

打开数据库，开启日志实时应用

SQL> alter database open;Database altered.SQL> alter database recover managed standby database using current logfile disconnect;Database altered.

使用基于scn的增量备份恢复DG备库相关推荐

oracle增量恢复dg备库,rman增量恢复DG备库出现GAP的情况
主库归档被意外删除,备库复制出现问题,alter日志如下: Wed Apr 01 10:16:15 2015 Media Recovery Log /tol/archivelog/1_587399_7 ...
oracle的scn增量备份,【Oracle】基于SCN的增量备份修复DataGuard GAP
1. 首先来模拟 Gap 的产生 1.1. 备库关闭: SYS@dgtest_sshutdown immediate; 1.2. 主库切换日志 SYS@dgtestselect SEQUENCE#,A ...
使用增量备份修复DG中的GAP
问题描述 oracle中DG出现主备不同步现象,alert日志报警有gap信息,但是v$archive_gap视图查不到任何信息.同时主库上的对应归档已经删除且没有备份解决方案 1.查询备库的scn ...
MySQL-日志、完全备份恢复和增量备份恢复
MySQL-日志.完全备份恢复和增量备份恢复一.MySQL日志管理 1.MySQL日志文件错误日志二进制日志中继日志慢查询日志二.查看日志状态命令三.备份的重要性 1.造成数据丢失的原因 ...
基于VMware应用环境的备份恢复解决方案思路
基于VMware应用环境的备份恢复解决方案思路 https://mp.weixin.qq.com/s?__biz=MjM5NTk0MTM1Mw==&mid=2650635166&idx ...
MySQL基于mysqldump及lvmsnapshot备份恢复
一.备份对象数据配置文件代码:存储过程,存储函数,触发器跟复制相关的配置二进制日志文件二.备份工具 mysqldump:逻辑备份工具 InnoDB热备.MyISAM温备.Aria温备备份 ...
实验——MySQL数据库增量备份恢复
目录一.MySQL数据库增量备份恢复 1.1 物理冷备份,开启服务 1.2 开启二进制日志文件 1.3 创建库和表,进行完全备份和增量备份 1.4 进行正常操作和误操作,进行增量备份 1.5 查看增 ...
转基于MySQL MEB的备份恢复
几种备份方式的介绍 mysqlbackup是一个热备份工具.也就是说它不像mysqldump那样给表上一个全局锁,由于mysqldump上了这个锁,所以就造成客户端只能对数据库进行读操作不能写,这也 ...
Linux系统快照一键备份恢复、不同机器恢复、增量备份恢复
Linux系统快照一键备份恢复.不同机器恢复.增量备份恢复前言由于前段时间在做一个自动化部署开发环境的项目需要重复安装多种服务以及中间件,但是生产环境的服务器不像自己的虚拟机可以使用快照,如果直接 ...

使用基于scn的增量备份恢复DG备库

在备库上关闭日志应用

确定增量备份的起始scn号（取以下查询结果中的最小SCN）

创建增量备份

传输至备库

手动注册备份文件记录入备库（如有catalog忽略此步骤，但主备备份目录需一致）

恢复备库控制文件

恢复数据库

打开数据库，开启日志实时应用

使用基于scn的增量备份恢复DG备库相关推荐

最新文章

热门文章