Oracle 11g通过SCN做增量备份修复standby库详细过程(2)

SQL> select to_char(current_scn) scnfrom v$database;                                                                                                                                         

SCN

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

11134239189

SQL>

备库：

SQL> select to_char(current_scn) scnfrom v$database;                                                                                                                                         

SCN

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

11125946526

SQL> 

也可以按照备库的最后一个scn号来在主库上进行增量备份，不过为了保险起见，我们以主库的scn号为准，那么就需要基于11125946510这个scn号去主库上做增量备份。

3，在主库上设置log_archive_dest_state_2值，主库的日志无法归档到备库.

先查询自己的归档目录select * from V$ARCHIVE_DEST;

PS：select * from V$ARCHIVE_DEST;查询到STATUS为VALID的，然后DESTINATION为PD_DG（这里是备库的标识）的dest编号就是往备库传输归档日志的；另外一个有目录/oracle/app/oracle/flash_recovery_area/archivelog的就是主库本身的归档日志dest，这个目录存储的就是主库本身的归档日志

ALTER system SET log_archive_dest_state_2 ='defer';

SQL> ALTER system SETlog_archive_dest_state_2 = 'defer';                                                                                                                                     

System altered.

SQL>

4，去备库先停止备库应用

ALTER DATABASE RECOVER MANAGED STANDBYDATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE CANCEL;                                                                                                                                 

ALTER DATABASE RECOVER MANAGED STANDBYDATABASE CANCEL

*

ERROR at line 1:

ORA-16136: Managed Standby Recovery notactive

SQL> 

看到standby已经是not active了，所以不需要执行了。

5，在主库执行备份

基于SCN增量备份：

backup device type disk incremental fromscn 11125946510 database format '/home/oracle/db_incre%U.bbk'; 

RMAN> backup device type diskincremental from scn 11125946510 database format'/home/oracle/db_incre%U.bbk';                                                                                 

Starting backup at 13-MAY-15                                                                                                                                                                   

using target database control file insteadof recovery catalog