dataguard 中standby有大量gap解決方法

當前遇到的問題

Oracle  dataguard環境，Standby 很長一段時間沒有啓用，再次啓用standby時，產生大量的歸檔gap。

環境介紹

oracle dataguard環境，主庫和備庫均爲單實例，而且軟件和硬件環境都相同

操做系統

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

linux ncdb 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64x86_64 x86_64 GNU/Linux

數據庫

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

PL/SQL Release 10.2.0.4.0 - Production

CORE    10.2.0.4.0      Production

TNS for Linux: Version 10.2.0.4.0 - Production

NLSRTL Version 10.2.0.4.0 – Production

判斷依據

通過仔細檢查，primary和standby的其餘都沒有問題，問題定位在standby的gap

Standby查詢v$archive_gap

SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE#HIGH_SEQUENCE#

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

         1           482           3713

         Standby的告警日誌信息中沒有error和ORA,

Waiting for all non-current ORLs to be archived...

Media Recovery Waiting for thread 1 sequence 482

Fetching gap sequence in thread 1, gap sequence482-581

 

解決方法：

解決gap的方法有兩種，方法雖然略有不一樣，可是原理是相同的

1、gap較少，能夠直接將缺乏的歸檔scp到standby，在standby手工註冊下便可

2、gap較多，在primary 作基於scn的backup，同時建立一個新的standbycontrolfile，將備份好的backupset ，standbycontrolfile 拷貝的備庫的相應目錄下，進行restore、recover的操做便可。

由於這個案例中，standby丟失的歸檔太多，推薦用第二種方法，同時，下面的操做也是使用的第二種方法

操做流程提綱：

（1）      standby 取消recover

（2）      查詢gap中LOW_SEQUENCE#-1對應的scn

（3）      在primary作基於該scn的增量備份

（4）      在primary建立新的standby controlfile

（5）      將增量的備份集和建立好的standby controlfile 拷貝的備庫

（6）      備庫shutdown

（7）      使用新的standby controlfile 啓動備庫到mount

（8）      Standby 作recover

（9）      驗證結果

 

具體操做步驟

（1）     standby取消recover

SQL> alter database recover managed standby databasecancel;

（2）      查詢gap中LOW_SEQUENCE#-1對應的scn

SQL>select THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#from v$archived_log

  2 where SEQUENCE#=481;

  THREAD#  SEQUENCE# FIRST_CHANGE#NEXT_CHANGE#

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

         1      481     542543    551725

（3）      在primary作基於該scn的增量備份

RMAN> run {

2> allocate channel c1device type disk;

3> allocate channel c2device type disk;

4> backup incremental from scn 542543 databaseformat '/oradata/bak/ora_scn_%U.bak';    #incremental單詞不要寫錯

5> release channel c1;

6> }

（4）      在primary建立standby controlfile

SQL> alterdatabase create standby controlfile as '/oradata/bak/control.ctl';

（5）      將增量備份集和建立好的standby controlfile 一塊兒拷貝備庫相應目錄下。

（6）      備庫shutdown

SQL> shutdownimmediate

（7）      使用新的standby controlfile 啓動備庫到mount

SQL> startup nomount;

ORACLE instance started.

 

Total System Global Area1610612736 bytes

Fixed Size                  2084296 bytes

Variable Size             385876536 bytes

Database Buffers         1207959552 bytes

Redo Buffers               14692352 bytes

SQL> alterdatabase mount;

（8）      Standby 作recover（須要注意的步驟）

RMAN> catalogstart with '/oradata/bak/ora_scn_05ohoqvu_1_1';   #放在standby的增量備份的備份集

using target databasecontrol file instead of recovery catalog

searching for all filesthat match the pattern /oradata/bak/ora_scn_05ohoqvu_1_1

List of Files Unknown tothe Database

=====================================

File Name:/oradata/bak/ora_scn_05ohoqvu_1_1

 

Do you really want to catalog theabove files (enter YES or NO)? YES

cataloging files...

cataloging done

 

List of Cataloged Files

=======================

File Name:/oradata/bak/ora_scn_05ohoqvu_1_1

 

RMAN> recover database noredo;

 

Starting recover at 20-8月 -13

allocated channel:ORA_DISK_1

channel ORA_DISK_1: sid=540devtype=DISK

channel ORA_DISK_1:starting incremental datafile backupset restore

channel ORA_DISK_1:specifying datafile(s) to restore from backup set

destination for restore ofdatafile 00001: /oradata/NCDB/system01.dbf

destination for restore ofdatafile 00002: /oradata/NCDB/undotbs01.dbf

destination for restore ofdatafile 00003: /oradata/NCDB/sysaux01.dbf

destination for restore ofdatafile 00004: /oradata/NCDB/users01.dbf

destination for restore ofdatafile 00005: /oradata/NCDB/nnc_data01.dbf

destination for restore ofdatafile 00006: /oradata/NCDB/nnc_data02.dbf

destination for restore ofdatafile 00007: /oradata/NCDB/nnc_data03.dbf

destination for restore ofdatafile 00008: /oradata/NCDB/nnc_index01.dbf

destination for restore ofdatafile 00009: /oradata/NCDB/nnc_index02.dbf

destination for restore ofdatafile 00010: /oradata/NCDB/nnc_index03.dbf

destination for restore ofdatafile 00011: /oradata/NCDB/nnc_iufo01.dbf

channel ORA_DISK_1: reading frombackup piece /oradata/bak/ora_scn_05ohoqvu_1_1

channel ORA_DISK_1:restored backup piece 1

piecehandle=/oradata/bak/ora_scn_05ohoqvu_1_1 tag=TAG20130820T095718

channel ORA_DISK_1: restore complete, elapsed time: 00:02:56

Finished recoverat 20-8月 -13

 

此時的告警日誌信息：

...

Tue Aug 20 11:24:46 2013

alter database recovercancel

Tue Aug 20 11:24:47 2013

Media Recovery Canceled

Completed: alter database recovercancel

Tue Aug 20 11:26:01 2013

Redo Shipping ClientConnected as PUBLIC

-- Connected User is Valid

RFS[1]: Assigned to RFSprocess 22461

RFS[1]: Identified databasetype as 'physical standby'

Tue Aug 20 11:26:01 2013

RFS LogMiner: Client disabled from further notification

Tue Aug 20 11:30:18 2013

Incremental restore complete of datafile 3 /oradata/NCDB/sysaux01.dbf

  checkpoint is 107026909

  last deallocation scn is 612835

Tue Aug 20 11:30:48 2013

Incremental restore complete of datafile 1 /oradata/NCDB/system01.dbf

  checkpoint is 107026909

  last deallocation scn is 615547

Tue Aug 20 11:31:11 2013

Incremental restore complete of datafile 2 /oradata/NCDB/undotbs01.dbf

  checkpoint is 107026909

  last deallocation scn is 662518

Incremental restore complete of datafile 4 /oradata/NCDB/users01.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 6 /oradata/NCDB/nnc_data02.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 7 /oradata/NCDB/nnc_data03.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 8 /oradata/NCDB/nnc_index01.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 9 /oradata/NCDB/nnc_index02.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 10/oradata/NCDB/nnc_index03.dbf

  checkpoint is 107026909

Incremental restore complete of datafile 11 /oradata/NCDB/nnc_iufo01.dbf

  checkpoint is 107026909

Tue Aug 20 11:31:31 2013

Incremental restorecomplete ofdatafile 5 /oradata/NCDB/nnc_data01.dbf

  checkpoint is 107026909

Tue Aug 20 11:34:16 2013

（9）      驗證結果

Standby 執行接收並恢復日誌操做

SQL> alterdatabase recover managed standby database disconnect from session;

SQL> select * fromv$archive_gap；

no rows selected

SQL> select THREAD#,max(SEQUENCE#) from v$archived_log

  2 group by THREAD#;

   THREAD# MAX(SEQUENCE#)

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

         1           3729

 

Primary端驗證結果

 

SQL> select THREAD# ,max(SEQUENCE#) from v$archived_log

  2  group by THREAD#;

 

   THREAD# MAX(SEQUENCE#)

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

1                                      3729

Primary進行日誌切換，查看standby告警日誌：

 

Fetching gapsequence in thread 1, gap sequence 3727-3727

Tue Aug 2011:36:57 2013

RFS[1]: ArchivedLog: '/oradata/arch/1_3727_753900804.arc'

Tue Aug 2011:37:27 2013

Media RecoveryLog /oradata/arch/1_3727_753900804.arc

Media RecoveryLog /oradata/arch/1_3728_753900804.arc

Media RecoveryWaiting for thread 1 sequence 3729

Tue Aug 2011:37:57 2013

RFS[1]: ArchivedLog: '/oradata/arch/1_3729_753900804.arc'

Tue Aug 20 11:37:582013

Media RecoveryLog /oradata/arch/1_3729_753900804.arc

Media RecoveryWaiting for thread 1 sequence 3730

原文地址：http://m.blog.csdn.NET/blog/woshizyq/12143327