oracle增量备份修复dg,Oracle DG GAP的解决

Oracle DATAGURD需要分为Physical Standby和logical Standby，企业主要使用的物理Standby，做灾备使用较多。

物理Standby：以基于块对块的主数据库同样的磁盘数据库结构，物理备用数据库物理等同于主数据库。

数据库的每一个块的内容包括块的逻辑位置都和主库完全一致

DG通过执行重做应用，维护物理备用数据库

物理STANDBY打开flashback database后可以完全读写打开

物理备用数据库使用通过oracle恢复机制，从归档重做日志文件或直接从备系统上的备重做日志文件用用重做数据来恢复。

物理备用数据库可用于执行备份

物理备用数据库使用重做应用技术使用低级别的恢复机制应用更改，绕过了所有SQL基本代码层，因此应用海量重做数据最有效，性能大于逻辑备份。

逻辑Standby：使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句。不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型。

如果使用了这种数据类型，则不能保证数据完全一致。LogicalStandby数据库可以在恢复的同时进行读写操作。

1、物理DG丢失部分日志

查询V$MANAGED_STANDBY，可以看到MRP的状态是WAIT_FOR_GAP查看GAP量

SQL>select * from V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

1        121958       121967在主库中查询缺失的日志的所在路径和名称

SQL>SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE#BETWEEN 121958 AND 121967 ;

NAME

----------

/other/arc/1_121958_902679684.dbf

……

……

/other/arc/1_121967_902679684.dbf

将上一步查询出的日志文件由主库拷贝到备库，并在备库注册日志文件

注：如果使用ASM存储归档日志，11g以后可以直接使用asmcmd里边cp命令拷贝到本地。11g以下版本可以使用dbms_file_transfer或者rman的convert和backup as copy命令，可参考：https://blog.csdn.net/imliuqun123/article/details/79260816/

SQL>alter database register logfile '/other/arc/1_121958_902679684.dbf';

查看注册过一个日志文件后，备库的gap情况，low_sequence#由121958变成了121959；

SQL>select * from V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

1 121959 121967完成全部日志文件注册，最好下观察备库的alert日志信息，最终查询到v$archive_gap无记录，说明GAP已经解决。

SQL>alter database register logfile '/other/arc/1_121959_902679684.dbf';

…… ……

SQL>alter database register logfile '/other/arc/1_121967_902679684.dbf';

SQL>select * from V$ARCHIVE_GAP;

norows selected也可以使用如下的SQL语句：

ALTERDATABASE REGISTER OR REPLACE LOGFILE '/other/arc/1_121959_902679684.dbf ';

ALTERDATABASE REGISTER OR REPLACE PHYSICAL LOGFILE '/other/arc/1_121959_902679684.dbf';

注：视图V$ARCHIVE_GAP只返回当前阻碍重做应用继续的GAp。在解决GAP并重启重做应用进程后，再次在物理备库上查询V$ARCHIVE_GAP视图来确定是个还有其他GAP存在，如果有的话，重复这个过程直到没有更多的中断。

2、逻辑DG手动解决GAP

在逻辑备库上查询DBA_LOGSTDBY_LOG视图可以确定是否有归档中断。例如，下面的查询指出断档号为121至123：

SQL>COLUMN FILE_NAME FORMAT a60

SQL>SELECT THREAD#, SEQUENCE#, FILE_NAME

FROM DBA_LOGSTDBY_LOG L

WHERE NEXT_CHANGE# NOT IN

(SELECT FIRST_CHANGE# FROMDBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)

ORDER BY THREAD#, SEQUENCE#;

THREAD# SEQUENCE# FILE_NAME

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

1 121 other/arc/1_121_902679684.dbf

1            123       /other/arc/1_123_902679684.dbf接下来复制丢失的日志文件到逻辑备库，并在逻辑备库上使用来注册日志文件。SQL>ALTER DATABASE REGISTER LOGICAL LOGFILE '/other/arc/1_121_902679684.dbf';在逻辑备库上注册这些日志文件之后，重启SQL应用。

同物理DG一样，在逻辑备库上的DBA_LOGSTDBY_LOG视图只返回当前阻碍SQL应用继续的GAP。在解决指定的GAP并重启SQL应用之后，再次在逻辑备库上查询DBA_LOGSTDBY_LOG视图，以确定下一个GAP，如果有的话，重复这个过程直到没有GAP。

如果需要的归档日志已经不在主库上了，但是有归档日志的RMAN备份，那么可以通过RMAN恢复把缺少的归档日志进行还原，如下所示：

SET ARCHIVELOG DESTINATION TO '/backup/arch';

RESTORE ARCHIVELOG FROM LOGSEQ 7;

如果断档的归档日志已经丢失，且RMAN又没有备份，那么在Oracle 10g之前没有办法修复了，只能重建DG，但是从Oracle 10g开始可以采用主库基于RMAN SCN的增量备份来恢复DG，下边将介绍基于RMANSCN的增量备份恢复。

3、GAP较多情况，基于RMAN SCN增量备份恢复利用基于SCN的备份去恢复DG的备库，从而绕开中间过多或者丢失的归档。如果要成完成一次基于scn的恢复？找到备库端数据文件中最低的scn，然后在主库去基于这个scn进行备份，这个时候rman回去扫描整个主库的块，如果块内的scn小于备库端数据文件中最低的scn，则证明这个块从备库应用到的时间点到现在是没有改变的，就忽略掉这个块。修复过程：

(1)查询备库当前SCN

SQL>col CURRENT_SCN for 999999999999999999

SQL>SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN

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

5995252523400

(2)确定主库是否添加数据文件

如果添加了数据文件，需要手工在备库添加。

SQL>select FILE#,name from v$datafile where CREATION_CHANGE#> =5995252523400;

norows selected

(3)备库停止日志应用

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

(4)主库增量备份并传输到备库上

RMAN>run {

allocatechannel c1 device type disk;

backup incremental fromscn 5995252523400 database format '/other/rman/ora_scn_%U.bak';

releasechannel c1;

}

scp other/rman/ora_scn_*.bak10.1.32.99:/other/rman/

(5)备库上进行恢复

RMAN>RECOVER DATABASE NOREDO;

(6)主库上创建Standbycontrolfile文件并传输到备库

RMAN>BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/other/rman/std_ctl.bak';

scp std_ctl.bak10.1.32.99:/other/rman/

(7)备库恢复控制文件

RMAN>shutdown;

RMAN>STARTUP NOMOUNT;

RMAN>RESTORE STANDBY CONTROLFILE FROM '/other/rman/std_ctl.bak';

RMAN>alter database mount;

(8)清空备库日志组(这里不用)

本次DG中使用了standbylog模式，不需要此步骤。

SQL>ALTER DATABASE CLEAR LOGFILE GROUP 1;

如果配置了physical standby redo log则不需该步骤；

如果没有采用standby log模式，有几组需要清空几组。

(9)备库重设flashback

备库重设flashback(根据实际情况选做，备库本身就没开启，所以不用操作)

SQL>ALTER DATABASE FLASHBACK OFF;

SQL>ALTER DATABASE FLASHBACK ON;

(10)备库重新接收并应用日志

备库重新接收并应用日志：

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE using current logfileDISCONNECT FROM SESSION;

恢复过程备库最后的日志(最后需要出现Media Recovery Waiting for字样)

(11)备库重新开启readonly模式

根据实际情况，备库重新开启readonly模式，本次需求是需要备库read only状态应用日志(11g ADG特性)

SQL>alter database RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL>alter database open;

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE using current logfileDISCONNECT FROM SESSION;

(12)验证修复是否成功对比最大sequence#.

在主库中执行altersystem switch logfile;

分别主备库中执行：select max(sequence#) from v$archived_log;通过跟踪alert文件

主库告警：

tail -200f oracle/app/oracle/diag/rdbms/xddb/xddb/trace/alert_xddb.log

备库告警：

tail -200f /oracle/app/oracle/diag/rdbms/xddb_dg/xddb/trace/alert_xddb.log

注：若备库是rac，或者asm存储，则在还原控制文件后需要把控制文件中的数据文件重命名为备库的原数据文件名称才可以执行恢复操作。

--重命名备库的数据文件

altersystem set standby_file_management=manual sid='*';

alterdatabase rename file '+DATADG/testdg/datafile/system.274.976812987' TO'+DATADG/testdgphy/datafile/system.261.976877439';

......

alterdatabase rename file '+DATADG/testdg/datafile/undotbs2.286.976813901' TO'+DATADG/testdgphy/datafile/undotbs2.257.976877619';

......

altersystem set standby_file_management=auto sid='*';

在执行RECOVER DATABASE NOREDO前，应该让备库和主库都处于同一个incarnation,否则会报错

listincarnation of database;

resetdatabase to incarnation 1;--应该和主库保持一致

附录：

Oracle的DG中常常用到的比较有用的性能视图：

V$MANAGED_STANDBY：包含与物理备库相关的数据库进程(例如：LGWR、RFS、LNS、ARCH、MRP等)的信息。

V$ARCHIVED_LOG：在备库执行此查询时，显示该备库接收到的日志。

V$LOG_HISTORY：包含归档历史的详细信息。

V$DATAGUARD_STATUS：包含DG生成的消息，这些消息被写入该特定数据库(主库或备库)的告警日志或跟踪文件中。

V$RECOVERY_PROGRESS：包含与备库恢复相关的统计信息。

V$STANDBY_EVENT_HISTOGRAM：包含某个物理备库的应用滞后的直方图。

DBA_LOGSTDBY_LOG：包含关于已经被或正在被SQL Apply处理的归档日志的信息。

DBA_LOGSTDBY_EVENTS：包含最近的SQL Apply事件(例如异常终止)的记录，这些事件也存在于运行SQL Apply的数据库实例的告警日志中。

V$LOGSTDBY_PROCESS：包含每个SQL Apply进程的当前状态。