在DG环境中,主库丢失归档,对主库进行基于SCN的增量备份来恢复物理DG环境

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 在DG环境中,主库丢失归档,对主库进行基于SCN的增量备份来恢复物理DG环境

面试DBA岗位,面试官对于DG环境常常会问到,若是主库丢失了归档文件,而这些归档文件还未来得及传递到备库,则物理备库是否只能通过重建的方式来恢复呢?这道面试题是作者亲身经历,当时以为只能重建备库,但最后经过查找文档找到了解决办法,可以通过对主库进行基于SCN的增量备份来恢复物理DG。

全过程简单有如下几个步骤:

第一步,主库创建基于SCN的增量备份:

首先要知道误删除或者丢失的归档日志是从哪个SCN开始的。视图V$ARCHIVED_LOG的FIRST_CHANGE#列能够查到归档日志对应的起始SCN。可以使用如下SQL查询最小的SCN:

SELECT (SELECT MIN(D.CHECKPOINT_CHANGE#) FROM V$DATAFILE D) DATAFILE_SCN,
       (SELECT MIN(D.CHECKPOINT_CHANGE#) FROM   V$DATAFILE_HEADER D WHERE  ROWNUM = 1) DATAFILE_HEADER_SCN,
       (SELECT CURRENT_SCN FROM V$DATABASE) CURRENT_SCN,
       (SELECT MIN(B.NEXT_CHANGE#) FROM   V$ARCHIVED_LOG B
        WHERE  B.SEQUENCE# IN (968,644)--这里修改成丢失的归档号
        AND  RESETLOGS_CHANGE# =(SELECT D.RESETLOGS_CHANGE# FROM V$DATABASE D)) NEXT_CHANGE#
FROM   DUAL;

若最小的SCN为750983,则在主库上使用BACKUP ... INCREMENTAL FROM SCN为主库做一个增量备份,这个操作会将整个库中SCN大于750983的BLOCK全备份出来,SQL如下:

RUN { 
ALLOCATE CHANNEL D1 TYPE DISK; 
ALLOCATE CHANNEL D2 TYPE DISK; 
ALLOCATE CHANNEL D3 TYPE DISK; 
ALLOCATE CHANNEL D4 TYPE DISK; 
BACKUP AS COMPRESSED BACKUPSET INCREMENTAL FROM SCN 750983 DATABASE FORMAT '/ARCHIVE/STANDBY_NEW_%D_%T_%U.BAK' INCLUDE CURRENT CONTROLFILE FOR STANDBY FILESPERSET=5  TAG 'FOR STANDBY NEW'; 
RELEASE CHANNEL D1; 
RELEASE CHANNEL D2; 
RELEASE CHANNEL D3;
RELEASE CHANNEL D4;
}
list backupset of controlfile;--找到控制文件的备份集文件名

第二步,将备份的文件复制到备库端的空目录下

第三步,恢复备库的控制文件

在使用RMAN恢复备库的控制文件之前,需要将原来的控制文件进行手工的冷备并且记录下原来的控制文件中记录的数据文件的名称:

SELECT ''''||NAME||''' ;' FROM V$DATAFILE; --记录备库数据文件原名称及路径
startup force nomount
cp +DATA/oranlhr/controlfile/control01.ctl +DATA/oranlhr/controlfile/control01.ctl_bk
restore standby  controlfile from '/home/oracle/bak/standby_TESTDG_20180525_19t3q9sb_1_1.bak';
select 'alter database rename file '''||NAME ||''' TO ' FROM V$datafile; --查询恢复控制文件后备库数据文件的名称

第四步,在备库执行RECOVER操作:

ALTER DATABASE MOUNT; 
CATALOG START WITH '/ARCHIVE/';

list incarnation of database;
reset database to incarnation 1;--应该和主库保持一致

--重命名备库的数据文件
alter system set standby_file_management=manual sid='*';
alter database rename file '+DATADG/testdg/datafile/system.274.976812987' TO '+DATADG/testdgphy/datafile/system.261.976877439';
......
alter database rename file '+DATADG/testdg/datafile/undotbs2.286.976813901' TO '+DATADG/testdgphy/datafile/undotbs2.257.976877619';
alter system set standby_file_management=auto sid='*';

--最后执行恢复操作
RECOVER DATABASE NOREDO;

最后开启备库的实时应用进程,并且查询备库的日志应用情况:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

COL NAME FOR A100
SET LINESIZE 9999  PAGESIZE 9999
COL NEXT_CHANGE# FOR 999999999999999
SELECT THREAD#, NAME, SEQUENCE#, ARCHIVED, APPLIED, A.NEXT_CHANGE#
  FROM V$ARCHIVED_LOG A
 WHERE A.SEQUENCE# >= (SELECT MAX(B.SEQUENCE#) - 3
                         FROM V$ARCHIVED_LOG B
                        WHERE B.THREAD# = A.THREAD#
                          AND B.RESETLOGS_CHANGE# = A.RESETLOGS_CHANGE#
                          AND B.RESETLOGS_CHANGE# =
                              (SELECT D.RESETLOGS_CHANGE# FROM V$DATABASE D)
                          AND B.APPLIED = 'YES' 
              GROUP BY B.THREAD#)
 ORDER BY A.THREAD#, A.SEQUENCE#;

若需要恢复的文件比较多,则可以使用如下的SQL来查询恢复的进度:

SELECT A.USERNAME,
       (SELECT UPPER(NB.OSUSER) FROM V$SESSION NB WHERE NB.SID = A.SID) OSUSER,
       (SELECT NB.SID || ',' || NB.SERIAL# || ',' || PR.SPID
          FROM V$PROCESS PR, V$SESSION NB
         WHERE NB.PADDR = PR.ADDR
           AND NB.SID = A.SID
           AND NB.SERIAL# = A.SERIAL#) SESSION_INFO,
       A.TARGET,
       A.OPNAME,
       TO_CHAR(A.START_TIME, 'YYYY-MM-DD HH24:MI:SS') START_TIME,
       ROUND(A.SOFAR * 100 / A.TOTALWORK, 2) || '%' AS PROGRESS,
       (A.TIME_REMAINING) TIME_REMAINING,
       (A.SOFAR || ':' || A.TOTALWORK) SOFAR_TOTALWORK,
       (A.ELAPSED_SECONDS) ELAPSED_SECONDS,
       MESSAGE MESSAGE,
       (SELECT NB.EVENT FROM V$SESSION_WAIT NB WHERE NB.SID = A.SID) WAIT_EVENT,
       (SELECT NB.STATUS FROM V$SESSION NB WHERE NB.SID = A.SID) STATUS
  FROM V$SESSION_LONGOPS A
 WHERE A.TIME_REMAINING <> 0
 ORDER BY STATUS, A.TIME_REMAINING DESC, A.SQL_ID, A.SID;

在主库归档日志丢失无法同步到备库时,可以利用增量scn来备份主库的方式,从而避免重建standby。由于丢失了归档,所以最后需要对数据库进行一次全备。

在整个恢复过程中需要注意的几点:

① 若备库是rac,或者asm存储,则在还原控制文件后需要把控制文件中的数据文件重命名为备库的原数据文件名称才可以执行恢复操作。
② 在执行RECOVER DATABASE NOREDO前,应该让备库和主库都处于同一个incarnation,否则会报如下的错误,并且不能启用备库的实时日志应用功能:

SYS@DGPHY1> alter database open;
alter database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+DATADG/testdgphy/datafile/system.261.976877439'
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
数据库
在备库上进行热备份--11.2.0.4之后
一个经典的备份语句:backup database plus archivelog;
|
数据库
在备库上进行热备份--10G之前
切换主库日志的脚本 logswitch.sh
|
数据库
在备库上进行冷备份的三个步骤
数据库处于mount状态不一定是一致的,要看mrp进程是否存在!
|
数据库
备库数据文件异常,物理DG如何恢复?
备库数据文件异常,物理DG如何恢复?
247 0
|
Oracle 关系型数据库
dataguard 增量恢复
dataguard 增量恢复
131 0
|
运维
简单记录一次ADG备库同步故障
这是一套11g的老库,主库3节点,备库1节点。项目上于昨天晚上做某测试扩容了表空间,在其他位置新建了9个数据文件,在备库无法创建这个非标准位置的datafile,从而导致同步中断。
421 0