How to Use RMAN Incremental backup to restore data guard log gap (log disconnection), rmangap

How to Use RMAN Incremental backup to restore data guard log gap (log disconnection), rmangap
The minimum scn information of the master database:
SQL> col current_scn for 999999999999999
SQL> SELECT CURRENT_SCN FROM V $ DATABASE;
 
Select min (fhscn) from x $ kcvfh;
 
Select min (f. fhscn) from x $ kcvfh f, v $ datafile d
Where f. hxfil = d. file #
And d. enabled! = 'Read only ';
CURRENT_SCN
----------------
12614205226673

MIN (FHSCN)
----------------
12614205076072

MIN (F. FHSCN)
----------------
12614205076072
 
++ ++ =


1. ---- the standby database cancels the archive application
Alter database recover managed standby database cancel;


2. ---- the slave database determines the lowest scn
Col current_scn for 99999999999999
SELECT CURRENT_SCN from v $ DATABASE;

Select min (fhscn) from x $ kcvfh;

Select min (f. fhscn) from x $ kcvfh f, v $ datafile d
Where f. hxfil = d. file #
And d. enabled! = 'Read only ';

Take the minimum value in the preceding Query

SQL> col current_scn for 999999999999999999
SQL> SELECT CURRENT_SCN FROM V $ DATABASE;
 
CURRENT_SCN
-------------------
12611050666604
 
SQL> select min (fhscn) from x $ kcvfh;
 
MIN (FHSCN)
----------------
12611050666605
 
SQL> select min (f. fhscn) from x $ kcvfh f, v $ datafile d
Where f. hxfil = d. file #
And d. enabled! = 'Read only'; 2 3
 
MIN (F. FHSCN)
----------------
12611050666605


3. ----- on primary db end Incremental Backup Based on the minimum scn obtained in step 1
Backup incremental from scn 12611050666604 DATABASE format'/lixora/ForStandby _ % U' tag 'forstandby ';


4. ----- copy the backup to the slave Database
$ Scp ForStandby_07pqprm4_1_1 192.168.0.10:/tmp


5. ---- on standby db registers backup slices on the slave database. Pay attention to the user's owner and permissions.
RMAN> catalog start with '/lixora/forstandby ';


6. ---- execute recovery
RMAN> recover database noredo;




7. ----- on primary db generate a new standby Control File
RMAN> backup current controlfile for standby format'/lixora/ForStandbyCTRL. bck ';



8. ---- copy the standby control file generated by the master database to the slave database. Pay attention to the owner and permissions of the user.

RMAN> backup current controlfile for standby format'/lixora/ForStandbyCTRL. bck ';
 
Scp/lixora/ForStandbyCTRL. bck 192.168.0.10:/tmp


9. ------ back up the data file information of the slave database for comparison after the new standby control file is restored
Spool datafile_names_step8.txt
Set lines 200
Col name format a60
Select file #, name from v $ datafile order by file #;
Spool off


10. ------ on standby Db restore the new standby Control File

RMAN> shutdown immediate;
RMAN> startup nomount;
RMAN> restore standby controlfile from '/tmp/ForStandbyCTRL. bck ';


11. ----- update the data file information in the control file
Apply the new standby Control File
RMAN> SHUTDOWN;
RMAN> startup mount;

Catalog start with '+ DATA/zhglptdg/datafile /';


12. ------ on primary db. Make sure that no new data files are added to the master database after the log gap occurs in the slave database.
Select file #, name from v $ datafile where CREATION_CHANGE # & gt; 12611050666604;

If a record exists, you cannot perform the witch operation. You can refer to the following document to restore the record:
Note 1531031.1 Steps to perform for Rolling forward a standby database using RMAN incremental backup when datafile is added to primary


13. ----- rename the data file
RMAN> switch database to copy;
 
 
14. ----- confirm again that there is not much difference between the master database and the slave database scn after the Incremental backup is restored
SQL> col current_scn for 99999999999999
SELECT CURRENT_SCN from v $ DATABASE;
 
Select min (fhscn) from x $ kcvfh;
 
Select min (f. fhscn) from x $ kcvfh f, v $ datafile d
Where f. hxfil = d. file #
And d. enabled! = 'Read only ';

CURRENT_SCN
---------------
12614205662375
 
MIN (FHSCN)
----------------
12614205076072

MIN (F. FHSCN)
----------------
12614205076072
 

15. ------ On standby database, clean up the standby log Group
Select * from v $ standby_log;

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;


16. ------ start redo data apply
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

If you encounter some data loss caused by nologgling, you can install the following methods to restore the data.
To resolve NOLOGGING operations only, see Note 958181.1.
In addition to this information, see the online documentation:
10.2: http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#CIHIAADC
11.1: http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/rman.htm#SBYDB00759
11.2: http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/rman.htm#CIHIAADC


Postscript
If you want to enable real-time applications, you need to add standby redo logs to the slave database. The size should be the same as that of the master database and there should be a group more than the master database;


Alter database add standby logfile group 6 size 500 M;
Alter database add standby logfile group 7 size 500 M;
Alter database add standby logfile group 8 size 500 M;
Alter database add standby logfile group 9 size 500 M;


Enable command:
Alter database recover managed standby database using current logfile;

For details, see:

Oracle 10 Gb standby database real-time application of redo data

How to ensure that the dg is normal? Background logs are similar to the following:
Mon December 22 10:03:04 CST 2014
RFS [1]: Archived Log: '+ DATA/lixora/archivelog/1_23094_790186477.dbf'
Mon December 22 10:03:25 CST 2014
Media Recovery Log + DATA/lixora/archivelog/1_23094_790186477.dbf
Media Recovery Waiting for thread 1 sequence 23095 (in transit)
Mon December 22 10:05:53 CST 2014
RFS [2]: Archived Log: '+ DATA/lixora/archivelog/1_23095_790186477.dbf'
Primary database is in maximum performance mode
RFS [2]: No standby redo logfiles of size 1024000 blocks exist
Mon December 22 10:05:55 CST 2014
Media Recovery Log + DATA/zhglptdg/archivelog/1_23095_790186477.dbf
Media Recovery Waiting for thread 1 sequence 23096 (in transit)
Mon December 22 10:05:57 CST 2014
RFS [2]: Archived Log: '+ DATA/lixora/archivelog/1_23096_790186477.dbf'
Primary database is in maximum performance mode
RFS [2]: No standby redo logfiles of size 1024000 blocks exist
Mon December 22 10:06:00 CST 2014
Media Recovery Log + DATA/lixora/archivelog/1_23096_790186477.dbf
Media Recovery Waiting for thread 1 sequence 23097 (in transit)




Similar to the log, it indicates that the log is only transmitted but has no application:
Tue Dec 16 17:28:48 CST 2014
Primary database is in maximum performance mode
RFS [3]: Successfully opened standby log 7: '+ DATA/lixora/onlinelog/group_7.360.857131345'
Tue Dec 16 18:57:12 CST 2014
Primary database is in maximum performance mode
RFS [3]: Successfully opened standby log 8: '+ DATA/lixora/onlinelog/group_8.361.857131375'
Tue Dec 16 20:12:13 CST 2014
Primary database is in maximum performance mode
RFS [3]: Successfully opened standby log 7: '+ DATA/lixora/onlinelog/group_7.360.857131345'
Tue Dec 16 21:40:39 CST 2014
Primary database is in maximum performance mode
RFS [3]: Successfully opened standby log 8: '+ DATA/lixora/onlinelog/group_8.361.857131375'




How to ensure normal dg:
1) v $ archive_log.applied: yes
2) master database switch log: ALTER system swtich logfile;
Check whether the standby database v $ database. CURRENT_SCN has increased?