【Oracle】基于SCN的增量备份修复DataGuard GAP

1. 首先来模拟Gap的产生

1.1. 备库关闭:

[email protected]_s>shutdown immediate;

1.2. 主库切换日志

[email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log;

SEQUENCE# ARC STATUS

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

61 YES ACTIVE

62 YES ACTIVE

63 NO  CURRENT

[email protected]>alter system archive log current;

System altered.

[email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log;

SEQUENCE# ARC STATUS

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

64 NO  CURRENT

62 YES ACTIVE

63 YES ACTIVE

刚才current的日志已经归档

1.3. 删除归档,产生UNRESOLVABLE GAP

现在删除63号归档

[[email protected] arch]$ mv 1_63_909786801.dbf 1_63_909786801.dbf.bak

2. 查看报错

2.1. 启动备库

[email protected]_s>startup

2.2. 查看备库的alert

Media Recovery Log /u01/app/oracle/arch/1_62_909786801.dbf

Media Recovery Waiting for thread 1 sequence 63

Fetching gap sequence in thread 1, gap sequence 63-63

Fri May 06 05:28:09 2016

FAL[client]: Failed to request gap sequence

GAP - thread 1 sequence 63-63

DBID 3866310445 branch 909786801

FAL[client]: All defined FAL servers have been attempted.

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

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that‘s sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

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

2.3. 主库查询SWITCHOVER_STATUS

[email protected]>SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

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

UNRESOLVABLE GAP

为UNRESOLVABLE GAP,说明此时的GAP需要我们自己手工去修复,无法自动修复,可自动修复的GAP显示为RESOLVABLE
GAP

3. 基于SCM的增量备份修复GAP

3.1. 在备库上查询current scn号

[email protected]_s>select current_scn from v$database;

CURRENT_SCN

-----------

2567388

3.2. 到主库去进行基于此SCN的增量备份

RMAN> BACKUP INCREMENTAL FROM SCN 2567388 DATABASE FORMAT ‘/u01/app/oracle/oradata/tmp/ora11_scn_%U‘ tag ‘For Standby Gap‘;

3.3. 传输到备库:

[[email protected] tmp]$ scp * standby:/u01/app/oracle/oradata/tmp

[email protected]‘s password:

ora11_scn_0kr54hvk_1_1                                                                                                               100%  125MB 125.2MB/s   00:01

ora11_scn_0lr54l99_1_1                                                                                                               100% 9664KB   9.4MB/s   00:00

3.4. 备库重新启动到mount,并取消日志应用

[email protected]_s>shutdown immediate;

[email protected]_s>startup mount;

[email protected]_s>alter database recover managed standby database cancel;

3.5. 注册刚才传输过来的备份集

RMAN> CATALOG START WITH ‘/u01/app/oracle/oradata/tmp‘;

3.6. recover备库

RMAN> recover database noredo;

恢复完毕,这时我们可以观察备库的alert日志:

Incremental restore complete of datafile 4 /u01/app/oracle/oradata/dgtest_s/users01.dbf

checkpoint is 2893208

last deallocation scn is 3

Incremental restore complete of datafile 3 /u01/app/oracle/oradata/dgtest_s/undotbs01.dbf

checkpoint is 2893208

last deallocation scn is 973300

Incremental restore complete of datafile 5 /u01/app/oracle/oradata/dgtest_s/example01.dbf

checkpoint is 2893208

last deallocation scn is 942056

Mon May 09 05:20:25 2016

Incremental restore complete of datafile 2 /u01/app/oracle/oradata/dgtest_s/sysaux01.dbf

checkpoint is 2893208

last deallocation scn is 956093

Incremental restore complete of datafile 1 /u01/app/oracle/oradata/dgtest_s/system01.dbf

checkpoint is 2893208

last deallocation scn is 955346

发现数据文件的scn号都已经重新刷新,但是此时还不能重新起库,需要重新从主库生成一个standby controlfile。

3.7. 主库备份控制文件

RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT ‘/u01/app/oracle/oradata/tmp/ctl.bak‘;

3.8. 传输standby控制文件到备库

[email protected]‘s password:

ctl.bak                                                                                                                              100% 9664KB   9.4MB/s   00:00

3.9. 备库恢复standby控制文件

备库库起到nomount阶段:

[email protected]_s>shutdown immediate

[email protected]_s>startup nomount;

rman恢复控制文件

RMAN> RESTORE STANDBY CONTROLFILE FROM ‘/u01/app/oracle/oradata/tmp/ctl.bak‘;

3.10. mount备库,并取消日志应用

[email protected]_s> alter database mount;

[email protected]_s>alter database recover managed standby database cancel;

3.11. 清空备库日志组

[email protected]_s>ALTER DATABASE CLEAR LOGFILE GROUP 1;

Database altered.

注:如果采用了standby log模式,不需要清空,如果清空会出现

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

ALTER DATABASE CLEAR LOGFILE GROUP 1

*

ERROR at line 1:

ORA-19527: physical standby redo log must be renamed

ORA-00312: online log 1 thread 1: ‘/u01/oradata/badly9/redo01.log‘

说明:如果没有采用standby log模式,有几组需要清空几组

3.12. 备库重设flashback

[email protected]_s>ALTER DATABASE FLASHBACK OFF;

[email protected]_s>ALTER DATABASE FLASHBACK ON;

3.13. 备库开始应用日志

[email protected]_s>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

4. 确认修复成功

在主库中执行

[email protected]>alter system switch logfile;

分别主备库中执行select max(sequence#) from v$archived_log;如果一致标示修复成功

[email protected]>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

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

81

[email protected]_s>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

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

81

至此GAP修复完毕。

时间: 2024-08-01 17:41:38

【Oracle】基于SCN的增量备份修复DataGuard GAP的相关文章

ORACLE 11G通过SCN做增量备份修复standby库详细过程

背景描述:Oracle 的standby库后台alert报错,如下: ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 10240change 11125950022 time 05/08/2015 22:00:41 ORA-00334: archived log:'/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf' R

增量备份解决dataguard库日志gap

有时候备库滞后于主库很长时间了,而主库的归档日志已经不存在了,此时的日志间隔如何消除那,很多人选择重建备库,这个是很麻烦的,尤其当主库数据量很大的时候,此时我们还有另外一种选择,那就是使用增量数据库备份来前滚备库,消除日志间隔,具体作法如下:1.备库查看丢失的归档时的scn号 idle> select current_scn from v$database; CURRENT_SCN ----------- 96458277 2.主库创建基于丢失归档scn号为起始的增量备份(要确定主库和备库的目标

基于binlog的增量备份

1.1 增量备份简介 增量备份是指在一次全备份或上一次增量备份后,以后每次的备份只需备份与前一次相比增加或者被修改的文件.这就意味着,第一次增量备份的对象是进行全备后所产生的增加和修改的文件:第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件,如此类推.这种备份方式最显著的优点就是:没有重复的备份数据,因此备份的数据量不大,备份所需的时间很短.但增量备份的数据恢复是比较麻烦的.您必须具有上一次全备份和所有增量备份磁带(一旦丢失或损坏其中的一个增量,就会造成恢复的失败),并且它们必

DataGuard GAP问题解决

某天下午打开DG备库时发现无法open只能到mount状态. Alter database open; 总是提示如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-10458: standby database requires recovery ORA-01196: file 1 is inconsistent due to a failed media recovery session ORA-

通过增量备份恢复来处理Oracle DG 复制GAP

1.确定增备scn范围,通过alert日志获取gap日志序列GAP - thread 1 sequence 109631-117170 2.根据序列获取增备起点SCN提示最小gap序列为109631, 往前推一个序列,然后获得scn号 select THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log where SEQUENCE#=109630;THREAD# SEQUENCE# FIRST_CHANGE# NEXT_

Xtrabackup 增量备份、恢复、原理

整合了网上的一些资料,结合自己的理解,并进行了实验验证 理解一: 1,Xtrabackup是什么 Xtrabackup是一个对InnoDB做数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业备份工具InnoDB Hotbackup的一个很好的替代品. Xtrabackup有两个主要的工具:xtrabackup.innobackupex (1).xtrabackup只能备份InnoDB和XtraDB两种数据表,而不能备份MyISAM数据表 (2). innobackupex是参考了In

MySQL5.7.18 备份、Mysqldump,mysqlpump,xtrabackup,innobackupex 全量,增量备份,数据导入导出

粗略介绍冷备,热备,温暖,及Mysqldump,mysqlpump,xtrabackup,innobackupex 全量,增量备份 --备份的目的 灾难恢复:意外情况下(如服务器宕机.磁盘损坏等)对损坏的数据进行恢复和还原保证数据不丢失,最小程度地丢失需求改变:因需求改变而需要把数据还原到改变以前测试:测试新功能是否可用 --备份与恢复概述 根据备份的方法可以分为: 1.Hot Backup(热备) 2.Cold Backup(冷备) 3.Warm Backup(温备) Hot Backup是指

Centos 6.9 安装xtrabackup-2.4.8 通用包,yum安装,全量备份,增量备份

xtrabackup-2.4.8的安装及使用 ---Yum安装 官网地址:https://www.percona.com/doc/percona-xtrabackup/LATEST/installation/yum_repo.html [[email protected] ~]# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm [[

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE