为何recover noredo不起作用

原贴发布于http://www.itpub.net/thread-1762728-1-1.html

这是一个2节点RAC系统，其standby也是2个节点，版本为10204
备库被主库拉下的太远,决定使用recover noredo恢复
--standby
SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
9058385939647
--primary
SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
9096971552573
--primary增量备份
RMAN> run
2> {allocate channel d1 type disk;
3> allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
backup as compressed backupset incremental from SCN 9058385939647 database format '/s105/oradata/STandby_bkp/standby_%d_%T_%U.bak'
include current controlfile for standby filesperset=5  tag 'FOR STANDBY';
release channel d1;
release channel d2;
release channel d3;
release channel d4;
}
将文件传给standby并catalog，登陆rman执行，输出结果只有这么多，且current_scn并为改变
--standby
RMAN> recover database noredo;
Starting recover at 04-FEB-13
using channel ORA_DISK_1
Finished recover at 04-FEB-13
SQL> select to_char(current_scn) from v$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
9058385939647

 

疑惑

依据备库的current_scn在主库做增量备份，但是recover noredo不起作用

841765.1给出很好的解释

 

某些时候datafile scn和current_scn差距较大，此时应选用min(scn)作为增量备份的起点

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 read write ;
SQL> alter tablespace read only ;

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

RMAN> BACKUP INCREMENTAL FROM SCN
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;

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15480802/viewspace-761491/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15480802/viewspace-761491/