Oracle Dataguard是官方重要HA架構的組成部分。透過只讀的Standby資料庫，可以在確保高可用的基礎上，將一部分報表、備份負載從主庫上分離出來，提高主庫效能。

根據Oracle最佳實踐，主庫Primary是可以不進行直接的備份，核心備份操作可以放在Standby端進行操作，這樣不僅可以節省備份資源，還可以有效的將備份的效能消耗轉移到Standby端進行。

本文記錄了筆者在Physical Standby端進行RMAN備份的時候，遇到錯誤資訊的問題解決。記錄下來，留待需要的朋友待查。

1、環境說明

筆者使用Oracle 11gR2進行測試，具體版本為11.2.0.4。Data Guard Primary和Standby採用的版本完全相同。

SQL> select * from v$version;

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE 11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

在Standby端，是採用Active Data Guard只讀應用狀態。

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ ONLY WITH APPLY PHYSICAL STANDBY

2、問題故障

在standby端，使用RMAN進行備份動作。進行全庫備份和歸檔日誌備份，備份之後嘗試刪除掉已經備份的日誌檔案。

[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalog

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 18 13:44:54 2015

RMAN> connect target /

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

進行RMAN備份。

RMAN> backup database plus archivelog delete input;

Starting backup at 18-OCT-15

RMAN-06820: WARNING: failed to archive current log at primary database

ORACLE error from target database:

ORA-17629: Cannot connect to the remote database server

ORA-17627: ORA-00942: table or view does not exist

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=204 device type=DISK

specification does not match any archived log in the repository

backup cancelled because there are no files to backup

Finished backup at 18-OCT-15

Starting backup at 18-OCT-15

（篇幅原因，有省略……）

handle=/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893423697_c26dj5nb_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 18-OCT-15

在備份過程中出現錯誤，錯誤提示上好像是要訪問Primary端資料庫，之後由於許可權問題沒有能夠訪問。其他備份動作看似正常，備份集合顯示正確。

RMAN> list backup;

List of Backup Sets

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

BS Key Size Device Type Elapsed Time Completion Time

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

6 27.46M DISK 00:00:00 18-OCT-15

BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20151018T133946

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_10_18/o1_mf_annnn_TAG20151018T133946_c26d52kd_.bkp

List of Archived Logs in backup set 6

Thrd Seq Low SCN Low Time Next SCN Next Time

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

1 22 1290925 18-OCT-15 1298642 18-OCT-15

1 23 1298642 18-OCT-15 1298901 18-OCT-15

1 24 1298901 18-OCT-15 1299107 18-OCT-15

1 25 1299107 18-OCT-15 1299528 18-OCT-15

1 26 1299528 18-OCT-15 1301585 18-OCT-15

1 27 1301585 18-OCT-15 1301853 18-OCT-15

1 28 1301853 18-OCT-15 1302226 18-OCT-15

1 29 1302226 18-OCT-15 1303310 18-OCT-15

1 30 1303310 18-OCT-15 1303858 18-OCT-15

1 31 1303858 18-OCT-15 1308314 18-OCT-15

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

11 Full 1.11G DISK 00:00:08 18-OCT-15

BP Key: 12 Status: AVAILABLE Compressed: NO Tag: TAG20151018T134526

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_10_18/o1_mf_nnndf_TAG20151018T134526_c26dhpdf_.bkp

List of Datafiles in backup set 11

File LV Type Ckp SCN Ckp Time Name

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

1 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_system_c2613wz5_.dbf

2 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_sysaux_c2613x03_.dbf

3 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_undotbs1_c2613x07_.dbf

4 Full 1308778 18-OCT-15 /u01/app/oracle/oradata/VLIFESB/datafile/o1_mf_users_c2613x0d_.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

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

12 Full 9.36M DISK 00:00:00 18-OCT-15

BP Key: 13 Status: AVAILABLE Compressed: NO Tag: TAG20151018T134541

Piece Name: /u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893423697_c26dj5nb_.bkp

SPFILE Included: Modification time: 18-OCT-15

SPFILE db_unique_name: VLIFESB

Standby Control File Included: Ckp SCN: 1310511 Ckp time: 18-OCT-15

3、問題分析解決

這個問題很不合理，看似應該是Oracle Bug之類的情況。查詢MOS，發現了對應的Bug資訊：RMAN-06820 ORA-17629 During Backup at Standby Site (文件 ID 1616074.1)。

根據文章資訊，該問題Oracle一個未釋出的bug，編號為Bug 8740124。當Oracle嘗試訪問主庫過程中，需要連帶將全部的standby log獲取到。當連線失敗的時候，就會發生報錯。

要解決該問題，Oracle提供了一個變通的辦法，就是不要使用target /匿名方式登入，而是使用sysdba使用者的使用者名稱和密碼資訊進行直接連線。

實驗如下：

[oracle@vLIFE-URE-OT-DB-STANDBY trace]$ rman nocatalog

Recovery Manager: Release 11.2.0.4.0 - Production on Sun Oct 18 13:49:56 2015

RMAN> connect target sys/oracle@vlifesb

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

RMAN> backup database plus archivelog delete input;

Starting backup at 18-OCT-15

current log archived at primary database

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=204 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

（篇幅原因，有省略……）

handle=/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_10_18/o1_mf_s_893425827_c26dssbt_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 18-OCT-15

沒有出現報錯資訊，問題解決。

4、結論

筆者思考一下，這個變通策略還是利用了主庫和備庫在sysdba使用者的密碼相同這個策略。在備份的時候，將顯示記錄的sysdba使用者密碼輸入進去，用於進行遠端Primary登入和獲取。

Dataguard Standby備份報錯RMAN-06820 ORA-17629解決

相關文章