【Oracle】基於SCN的增量備份修複DataGuard GAP

來源:互聯網
上載者:User

標籤:

1.  首先來類比Gap的產生1.1.  備庫關閉:

[email protected]_s>shutdown immediate;

1.2.  主庫切換日誌

[email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log;

 

 SEQUENCE# ARC STATUS

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

        61 YES ACTIVE

        62 YES ACTIVE

        63 NO  CURRENT

 

[email protected]>alter system archive log current;

 

System altered.

 

[email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log;

 

 SEQUENCE# ARC STATUS

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

        64 NO  CURRENT

        62 YES ACTIVE

        63 YES ACTIVE

剛才current的日誌已經歸檔

1.3.  刪除歸檔,產生UNRESOLVABLE GAP

現在刪除63號歸檔

[[email protected] arch]$ mv 1_63_909786801.dbf 1_63_909786801.dbf.bak

 

2.  查看報錯2.1.  啟動備庫

[email protected]_s>startup

2.2.  查看備庫的alert

Media Recovery Log /u01/app/oracle/arch/1_62_909786801.dbf

Media Recovery Waiting for thread 1 sequence 63

Fetching gap sequence in thread 1, gap sequence 63-63

Fri May 06 05:28:09 2016

FAL[client]: Failed to request gap sequence

 GAP - thread 1 sequence 63-63

 DBID 3866310445 branch 909786801

FAL[client]: All defined FAL servers have been attempted.

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

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that‘s sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

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

2.3.  主庫查詢SWITCHOVER_STATUS

[email protected]>SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

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

UNRESOLVABLE GAP

為UNRESOLVABLE GAP,說明此時的GAP需要我們自己手工去修複,無法自動修複,可自動修複的GAP顯示為RESOLVABLE GAP

 

3.  基於SCM的增量備份修複GAP3.1.  在備庫上查詢current scn號

[email protected]_s>select current_scn from v$database;

 

CURRENT_SCN

-----------

    2567388

3.2.  到主庫去進行基於此SCN的增量備份

RMAN> BACKUP INCREMENTAL FROM SCN 2567388 DATABASE FORMAT ‘/u01/app/oracle/oradata/tmp/ora11_scn_%U‘ tag ‘For Standby Gap‘;

3.3.  傳輸到備庫:

[[email protected] tmp]$ scp * standby:/u01/app/oracle/oradata/tmp

[email protected]‘s password:

ora11_scn_0kr54hvk_1_1                                                                                                               100%  125MB 125.2MB/s   00:01    

ora11_scn_0lr54l99_1_1                                                                                                               100% 9664KB   9.4MB/s   00:00  

3.4.  備庫重新啟動到mount,並取消日誌應用

[email protected]_s>shutdown immediate;

[email protected]_s>startup mount;

[email protected]_s>alter database recover managed standby database cancel;

3.5.  註冊剛才傳輸過來的備份組

RMAN> CATALOG START WITH ‘/u01/app/oracle/oradata/tmp‘;

3.6.  recover備庫

RMAN> recover database noredo;

恢複完畢,這時我們可以觀察備庫的alert日誌:

Incremental restore complete of datafile 4 /u01/app/oracle/oradata/dgtest_s/users01.dbf

  checkpoint is 2893208

  last deallocation scn is 3

Incremental restore complete of datafile 3 /u01/app/oracle/oradata/dgtest_s/undotbs01.dbf

  checkpoint is 2893208

  last deallocation scn is 973300

Incremental restore complete of datafile 5 /u01/app/oracle/oradata/dgtest_s/example01.dbf

  checkpoint is 2893208

  last deallocation scn is 942056

Mon May 09 05:20:25 2016

Incremental restore complete of datafile 2 /u01/app/oracle/oradata/dgtest_s/sysaux01.dbf

  checkpoint is 2893208

  last deallocation scn is 956093

Incremental restore complete of datafile 1 /u01/app/oracle/oradata/dgtest_s/system01.dbf

  checkpoint is 2893208

  last deallocation scn is 955346

探索資料檔案的scn號都已經重新重新整理,但是此時還不能重新起庫,需要重新從主庫產生一個standby controlfile。

3.7.  主庫備份控制檔案

RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT ‘/u01/app/oracle/oradata/tmp/ctl.bak‘;

3.8.  傳輸standby控制檔案到備庫

[email protected]‘s password:

ctl.bak                                                                                                                              100% 9664KB   9.4MB/s   00:00

3.9.  備庫恢複standby控制檔案

備庫庫起到nomount階段:

[email protected]_s>shutdown immediate

[email protected]_s>startup nomount;

rman恢複控制檔案

RMAN> RESTORE STANDBY CONTROLFILE FROM ‘/u01/app/oracle/oradata/tmp/ctl.bak‘;

3.10.  mount備庫,並取消日誌應用

[email protected]_s> alter database mount;

[email protected]_s>alter database recover managed standby database cancel;

3.11.  清空備庫日誌組

[email protected]_s>ALTER DATABASE CLEAR LOGFILE GROUP 1;

 

Database altered.

註:如果採用了standby log模式,不需要清空,如果清空會出現

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

ALTER DATABASE CLEAR LOGFILE GROUP 1

*

ERROR at line 1:

ORA-19527: physical standby redo log must be renamed

ORA-00312: online log 1 thread 1: ‘/u01/oradata/badly9/redo01.log‘

說明:如果沒有採用standby log模式,有幾組需要清空幾組

 

3.12.  備庫重設flashback

[email protected]_s>ALTER DATABASE FLASHBACK OFF;

[email protected]_s>ALTER DATABASE FLASHBACK ON;

3.13.  備庫開始應用日誌

[email protected]_s>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

 

4.  確認修複成功

在主庫中執行

[email protected]>alter system switch logfile;

分別主備庫中執行select max(sequence#) from v$archived_log;如果一致標示修複成功

[email protected]>select max(sequence#) from v$archived_log;

 

MAX(SEQUENCE#)

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

            81

 

[email protected]_s>select max(sequence#) from v$archived_log;

 

MAX(SEQUENCE#)

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

            81

至此GAP修複完畢。

【Oracle】基於SCN的增量備份修複DataGuard GAP

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.