Dataguard環境作為Oracle官方重要的HA功能元件，在實踐領域有非常多的應用場景和成功案例。同任何技術一樣，在配置過程中，會出現一些問題需要解決。本文主要介紹在修改Physical Standby備份Rman引數中出現的問題和解決策略。

1、問題描述

筆者環境為11.2.0.4的Dataguard環境，兩臺伺服器配置為雙單節點的Physical Standby。在配置備庫的RMAN資訊中，出現如下問題：

RMAN> connect target sys/oracle

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

RMAN> show all;

RMAN configuration parameters for database with db_unique_name URESTB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

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

RMAN> configure retention policy to recovery window of 15 days;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 12/31/2015 08:55:16

RMAN-05021: this configuration cannot be changed for a BACKUP or STANDBY control file

從提示資訊情況看，在Standby端的RMAN配置專案是不能進行修改的。從MOS資料上看，這個問題的根源在於Standby端的控制檔案control file是一個只讀檔案。在control file中，Oracle將資料檔案、日誌（歸檔和線上）、備份資訊都儲存在其中。對於Standby端，Control File是一個只讀的檔案內容，透過常規的修改配置手段，是不能夠修改配置內容的。

2、官方兩種處理策略

在MOS ID 1519386.1中，提出了兩種潛在的處理方法。第一種處理策略是在進行備份的時候，將配置內容直接寫在備份還原操作語句中。

RMAN> list backup summary;

List of Backups

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

Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag

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

61 B A A DISK 21-DEC-15 1 1 NO TAG20151221T153209

62 B F A DISK 21-DEC-15 1 1 NO TAG20151221T153322

63 B F A DISK 21-DEC-15 1 1 NO TAG20151221T153347

64 B A A DISK 31-DEC-15 1 1 NO TAG20151231T091532

65 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091548

66 B A A DISK 31-DEC-15 1 1 NO TAG20151231T091606

67 B F A DISK 31-DEC-15 1 1 NO TAG20151231T091607

按照當前的一份冗餘策略，就會刪除掉12月21日的記錄。

RMAN> delete obsolete;

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

using channel ORA_DISK_1

Deleting the following obsolete backups and copies:

Type Key Completion Time Filename/Handle

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

Backup Set 61 21-DEC-15

Backup Piece 62 21-DEC-15

/u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_annnn_TAG20151221T153209_c7hbry5x_.bkp

Backup Set 62 21-DEC-15

Backup Piece 63 21-DEC-15

/u01/app/oracle/fast_recovery_area/VLIFESB/backupset/2015_12_21/o1_mf_nnndf_TAG20151221T153322_c7hbt2l2_.bkp

Backup Set 63 21-DEC-15

Backup Piece 64 21-DEC-15

/u01/app/oracle/fast_recovery_area/VLIFESB/autobackup/2015_12_21/o1_mf_s_899017209_c7hbtvxo_.bkp

Do you really want to delete the above objects (enter YES or NO)? no

直接指定obsolete視窗在RMAN命令視窗。

RMAN> delete obsolete recovery window of 5 days;

using channel ORA_DISK_1

no obsolete backups found

第二種方法是從Primary中複製處一份全新的standby control file，之前修改好RMAN引數，之後轉移到Standby中。作為新的Standby進行處理載入。

這個方案，筆者進行了詳細測試，最後沒有成功。主要原因是修改內容太多，操作步驟過於複雜。

ü 對於切換過來的Standby Control File，所有的資料檔案、線上日誌都需要重新進行定位重新命名；

ü 在調整檔名過程中，還要終止檔案自動管理功能；

ü 備庫上所有的歸檔日誌、備份資訊和同步時間點資訊，都會丟失；

基於此，筆者並不推薦使用這種方法。

3、切換Switchover解決問題

經過思考，筆者提出了一種假說。如果Control File在Standby端是不允許進行修改，但是在Primary端允許修改的話。可否進行一次有準備的Switchover動作，讓Standby端臨時性變為可以修改的Control File。修改之後再Switchover就可以了。

實驗過程如下，首先在主庫上進行角色切換動作。

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ WRITE PRIMARY

SQL> alter database commit to switchover to standby with session shutdown;

Database altered.

SQL> quit

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

With the Partitioning, OLAP, Data Mining and Real Application Testing options

[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ ps -ef | grep pmon

oracle 30720 30659 0 10:40 pts/0 00:00:00 grep pmon

主庫切換之後，自動停機。下面進行備庫操作。

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:38:32 2016

SQL> conn / as sysdba

Connected.

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ ONLY WITH APPLY PHYSICAL STANDBY

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

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

TO PRIMARY

SQL> alter database commit to switchover to primary with session shutdown;

Database altered.

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

MOUNTED PRIMARY

SQL> alter database open;

Database altered.

原來的主庫（先備庫）啟動，進行Redo Apply過程。

[oracle@vLIFE-URE-OT-DB-PRIMARY ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Wed Jan 13 10:42:37 2016

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 2471931904 bytes

Fixed Size 2255752 bytes

Variable Size 738198648 bytes

Database Buffers 1711276032 bytes

Redo Buffers 20201472 bytes

Database mounted.

SQL> alter database recover managed standby database using current logfile disconnect;

Database altered.

--日誌傳輸正常。

SQL> select STATUS from v$archive_dest_status;

STATUS

---------

VALID

INACTIVE

修改原備庫RMAN專案。

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

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 10:48:47 2016

RMAN> connect target /

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

RMAN> show all;

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION ON;

RMAN> configure retention policy to recovery window of 15 days;

new RMAN configuration parameters:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

new RMAN configuration parameters are successfully stored

RMAN> show all;

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

下面就可以使用相同的方法將原來的Primary和Standby關係切換回來。由於篇幅所限，不進行詳細說明。操作後，修改的引數生效。

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

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jan 13 11:11:18 2016

RMAN> connect target /

connected to target database: VLIFE (DBID=4207470439)

using target database control file instead of recovery catalog

RMAN> show all;

RMAN configuration parameters for database with db_unique_name VLIFESB are:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

CONFIGURE BACKUP OPTIMIZATION ON;

3、結論

綜合上面的三種方法，理論上都能夠解決我們面臨的實際問題。但是在實踐環境，特別是投產系統中，我們要從系統停機視窗、備份方案可用性和操作複雜性等多個角度進行綜合評估，作出最好的判斷。

DataGuard環境下備庫RMAN-05021問題有效性解決方案

相關文章