利用增量备份恢复standby

备库失败，需要应用主库的变更，想着在主库做一个基于scn的increment backup，然后恢复过去,查了下备库当前数据文件的scn:

SQL> select min(fhscn),max(fhscn) from x$kcvfh;

MIN(FHSCN) MAX(FHSCN)

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

16485717414 172167149419

发现差异挺大，16485717414是几个readonly数据文件的scn，172167149419是其他的read write数据文件的scn，我认为read only的数据文件应该在恢复的时候会直接跳过，

所以只要在主库做一个排除了readonly数据文件的最小scn增量备份，再增量恢复就可以了，但发现并不行，以下是我的操作步骤：

备份：

run {

allocate channel ch0 device type disk format '/prodbak/%U';

allocate channel ch1 device type disk format '/prodbak/%U';

allocate channel ch2 device type disk format '/prodbak/%U';

allocate channel ch3 device type disk format '/prodbak/%U';

backup INCREMENTAL FROM SCN 172167149419 database;

release channel ch0;

release channel ch1;

release channel ch2;

release channel ch3;

}

恢复时很快就说完成了：

RMAN> RECOVER DATABASE NOREDO;

Starting recover at 14-JUL-16

using channel ORA_DISK_1

datafile 6 not processed because file is read-only

datafile 9 not processed because file is read-only

datafile 10 not processed because file is read-only

datafile 11 not processed because file is read-only

datafile 16 not processed because file is read-only

datafile 20 not processed because file is read-only

datafile 28 not processed because file is read-only

Finished recover at 14-JUL-16

不指定noredo时会报错：

RMAN>

unable to find archived log

archived log thread=1 sequence=604969

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 07/14/2016 11:38:15

RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 604969 and starting SCN of 172167149419

v$datafile_header.checkpoint_change#来源于x$kcvfh.fhscn,这个值保存在各数据文件块头

v$datafile.checkpoint_change#来源于x$kccfe.fecps，这个值保存在控制文件中，

通常情况下，所有文件的这2个值是比较接近的，除非有offline状态和readonly的数据文件，这个值就会有比较明显的差异，我的数据库中那几个checkpoint_change#较小的数据文件就是这种情况，

所以按照note841765.1进行了操作：

1）取两者中小的那个scn做为增量开始的scn

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

SQL> select min(fhscn) from x$kcvfh;

2)将主库的readonly表空间临时设置为read write,再基于增量scn做一个增量的备份，并将备份文件拷贝到备库

run {

allocate channel ch0 device type disk format '/prodbak/%U';

allocate channel ch1 device type disk format '/prodbak/%U';

allocate channel ch2 device type disk format '/prodbak/%U';

allocate channel ch3 device type disk format '/prodbak/%U';

backup INCREMENTAL FROM SCN 16485717414 database;

release channel ch0;

release channel ch1;

release channel ch2;

release channel ch3;

}

3）catalog下备份文件，并recover:

RECOVER DATABASE NOREDO;

发现这样操作之后跟原来还是一样的现象，问题未能解决，还是提示缺少604969日志，

RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 604969 and starting SCN of 172167149419

但我查了下，发现min(x$kcvfh.fhscn)已经都调整到跟生产库接近了，而min(x$kccfe.fecps)还是停留在16485717414，即原来只读状态时的scn.

看来控制文件并没有随着增量备份的recover而恢复到跟生产一致，原因可能是recover的时候只是对数据文件进行了recover，并没有recover控制文件。

于是从生产库重新创建了一个standby controlfile:

SQL>alter database create standby controlfile as '/tmp/control.ctl';

并拷贝到备库，用这个控制文件mount数据库，再recover，又出现了数据文件找不到的错误：

SQL> recover automatic standby database;

ORA-00283: recovery session canceled due to errors

ORA-01110: data file 16: '/oradata/datafile/ZT_0210011_5.dbf'

ORA-01157: cannot identify/lock data file 16 - see DBWR trace file

ORA-01110: data file 16: '/oradata/datafile/ZT_0210011_5.dbf'

原因是因为设置了standby_file_management=AUTO,所以在主库新建数据文件的时候，备库数据文件名是自动生成的，与主库的文件名不一致，

例如主库文件名：undotbs02.dbf ，备库文件名：o1_mf_undotbs1_brlsddyc_.dbf

而我们现在使用的是从主库创建的控制文件，所以会报错找不到数据文件，

我通过在操作系统层面rename备库的数据文件解决：

mv /oradata/datafile/ADG/datafile/o1_mf_undotbs1_brlsddyc_.dbf /oradata/datafile/undotbs02.dbf

最后成功recover备库了。

这说明并不能按照我认为的方式去恢复，其实Oracle有2篇文档对增量恢复standby有一个详细的步骤说明：

Roll Forward a Physical Standby Database Using RMAN Incremental Backups 'Recover Database Noredo' Does Nothing (文档 ID 841765.1)

Roll Forward a Physical Standby Database Using RMAN Incremental Backups 'Recover Database Noredo' Does Nothing even after working through note 841765.1 (文档 ID 1960268.1)

841765.1：

SYMPTOMS

RMAN incremental backups can be used to synchronize a physical standby database with the primary database. Using the RMAN BACKUP INCREMENTAL FROM SCN command, you can create a backup on the primary database that starts at the standby database's current SCN,
which can then be used to roll the standby database forward in time.

However in some cases the RECOVER DATABASE NOREDO; command does not apply the incremental changes to the standby database and it just completes in few seconds.

RMAN> RECOVER DATABASE NOREDO;

Starting recover at 11-JUN-09

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=152 devtype=DISK

Finished recover at 11-JUN-09

CAUSE

In ideal case, the SCN of the database (CURRENT_SCN) and the datafile scn should not have a huge difference also most of the datafiles should be in same scn range. In the below example datafiles are of different scn that makes the incremental backup based
on CURRENT_SCN cannot be used.

Run this query in STANDBY

SQL> select distinct checkpoint_change# from v$datafile_header order by 1;

CHECKPOINT_CHANGE#

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

10966360849

10966365192

10966456071

10966459094

10966459249

10966478310

10966500361

10966501649

10966502244

10966963118

10967040320

10967041014

10967041052

10967041082

10967041102

10967044662

10969481568

10969482498

10969483695

The reason could be either the some of datafiles may be offline for long time, Read-only datafiles or the files are copied to standby one by one by the time there are changes going in the primary that cause the scn difference between datafiles.

SOLUTION

1) In STANDBY execute the below query to identify the lowest SCN

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

SQL> select min(fhscn) from x$kcvfh;

NOTE : In ideal situation the above 2 queries will return the almost same SCN. However if there is huge difference its better to take backup using the SCN from second query (lesser SCN), as one of the datafile may be behind.

If the affected files belong to a READ ONLY tablespace, those files will be ignored during backup. To bypass the issue, at Primary Database, switch the tablespace from read only to read write and back to read only again :

SQL> alter tablespace <tablespace_name> read write ;

SQL> alter tablespace <tablespace_name> read only ;

2) Take SCN based incremental backup from PRIMARY where SCN is from the result of step 1

RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step>

DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY'

3) Move the incremental backup to Standby , catalog the backup piece to STANDBY.

4) Now try to apply the incremental changes to the STANDBY using and it will apply the incremental changes to the standby database.

RMAN> RECOVER DATABASE NOREDO;

--------------split---------

1960268.1：

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.1.0.6 to 12.1.0.2 [Release 11.1 to 12.1]

Information in this document applies to any platform.

SYMPTOMS

You are working through the process of closing the gap on a standby via the use of a

RMAN level 1 incremental backup, but the "recover database noredo" command completes very quickly.

You've also worked through this Note

(Doc ID 841765.1) Roll Forward a Physical Standby Database Using RMAN Incremental Backups 'Recover Database Noredo' Does Nothing

Yet you still see the "recover database noredo" command complete very quickly:

CAUSE

Wrong incarnation is used/set in standby database

SOLUTION

# Connect via RMAN to the standby then issue:

rman> list incarnation of database;

# If you see a less than current incarnation which was created in the

# last day or two (time since you took the incremental backup),

# reset the incarnation and then try "recover database noredo" again.

Example:

--------

rman> reset database to incarnation 1;

rman> recover database noredo;