面试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'