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

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

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

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

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

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

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

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

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

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

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

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、結論

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

Oracle 11gR2 在VMWare虛擬機器中安裝步驟

Debian 下 安裝 Oracle 11g XE R2

Oracle Data Guard 重要配置參數

基於同一主機配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 歸檔刪除策略及指令碼

Oracle Data Guard 的角色轉換

Oracle Data Guard的日誌FAL gap問題

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法