备库失败，需要应用主库的变更，想着在主库做一个基于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 10966
502244 10966963118 109670
40320 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 prev
IoUs 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;
