移除遷移遺留的無法訪問的RMAN過期備份

　　這裡提供一種並不常見的NBU+RMAN備份問題的解決方案。這是最近一項遷移計劃的實施帶來的問題，遷移非常成功，但是遷移後建立備份計劃時遇到問題，由於資料庫遷移前採用帶庫備份，遷移後考慮新機硬碟空間充足，改為本地硬碟備份，但是遷移之前的備份資訊並沒有刪除，遷移後的伺服器未配置連線帶庫，因此遷移前的備份就無法直接刪除了。

如下：

RMAN> report obsolete device type sbt;


using target database controlfile instead of recovery catalog
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 7 days
Report of obsolete backups and copies
Type                 Key    Completion Time    Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set           11301  22-12月-08       
  Backup Piece       11301  22-12月-08         c-1984618042-20081222-00
Backup Set           11304  22-12月-08       
  Backup Piece       11304  22-12月-08         c-1984618042-20081222-01
Backup Set           11306  22-12月-08       
  Backup Piece       11306  22-12月-08         c-1984618042-20081222-02
Backup Set           11312  23-12月-08       
  Backup Piece       11312  23-12月-08         c-1984618042-20081223-00
Backup Set           11315  23-12月-08       
  Backup Piece       11315  23-12月-08         c-1984618042-20081223-01
Backup Set           11317  23-12月-08       
  Backup Piece       11317  23-12月-08         c-1984618042-20081223-02
Backup Set           11323  24-12月-08       
  Backup Piece       11323  24-12月-08         c-1984618042-20081224-00
Backup Set           11326  24-12月-08       
  Backup Piece       11326  24-12月-08         c-1984618042-20081224-01
Backup Set           11328  24-12月-08       
  Backup Piece       11328  24-12月-08         c-1984618042-20081224-02
Backup Set           11334  25-12月-08       
  Backup Piece       11334  25-12月-08         c-1984618042-20081225-00
Backup Set           11335  25-12月-08       
  Backup Piece       11335  25-12月-08         al_11445_1_674426605
Backup Set           11336  25-12月-08       
  Backup Piece       11336  25-12月-08         al_11446_1_674426911
Backup Set           11337  25-12月-08       
  Backup Piece       11337  25-12月-08         c-1984618042-20081225-01
Backup Set           11339  25-12月-08       
  Backup Piece       11339  25-12月-08         c-1984618042-20081225-02
............
..............
................

直接delete會報這個錯誤：

RMAN> delete obsolete device type sbt;

RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 7 days
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 02/01/2009 13:42:24
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25

你想說crosscheck一下？

RMAN> crosscheck backup;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=33 devtype=DISK
released channel: ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 02/01/2009 14:32:18
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25

RMAN> configure default device type to sbt;

old RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
new RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
new RMAN configuration parameters are successfully stored

RMAN> crosscheck backup;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 02/01/2009 14:33:29
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 2

　　顯然也不行啊，因為無法連線到帶庫裝置，自動也無法驗證備份集。

　　正如開往篇所說，這種問題並不常見，當然這也難不住俺，三思隨便動了幾個腦細胞，就想出如下幾種解決方式：

　　１、重建控制檔案。
　　絕對好使，但是代價較大，不僅之前備份統統無效，而且還需要停資料庫服務，由於要操作的是一臺較重要的生產伺服器，因此這種方法不可行。

　　２、通過rman命令手工將備份集狀態置為unavailable。
　　RMAN提供了一個change命令，可以修改備份集狀態為AVAILABLE/UNAVAILABLE/UNCATALOG等等。手工使用該命令將所有不可訪問的備份集置為unavailable，修改完狀態後等待控制檔案自動更新覆蓋失效記錄即可。這種方式最大的問題是見效太慢。
　　注意，nocatalog模式才能使用這種方式。

　　３、藉助dbms_backup_restore包直接刪除備份片段。
　　dbms_backup_restore是oracle提供的系統包，官方文件中並沒有提供該包的說明，但實際上rman在執行備份/恢復操作時就是呼叫的該包，該包提供了數十個滿足不同需求的包/函式，功能那是崗崗的。該過程排毒養顏而且無任何毒副作用，不僅療效好見效快老少皆宜，口感也非常好呢，實在是排解疑難，必備良工啊~~

這裡呢三思就通過dbms_backup_restore.deleteBackupPiece過程實戰演示刪除無法訪問的備份集。
dbms_backup_restore.deleteBackupPiece的定義如下：

PROCEDURE DELETEBACKUPPIECE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ ------------
 RECID                          NUMBER                  IN
 STAMP                          NUMBER                  IN
 HANDLE                         VARCHAR2                IN
 SET_STAMP                      NUMBER                  IN
 SET_COUNT                      NUMBER                  IN
 PIECENO                        BINARY_INTEGER          IN
 PARAMS                         VARCHAR2                IN     DEFAULT NULL

前6項引數都需要我們指定，這些引數的引數值可以從v$backup_piece中獲得。
由前report可知需要處理的piece ID為11301->11478：

SQL> select recid,stamp,set_stamp,set_count,handle,piece# from v$backup_piece where recid between 11301 and 11478;

     RECID      STAMP  SET_STAMP  SET_COUNT HANDLE                             PIECE#
---------- ---------- ---------- ---------- ------------------------------ ----------
     11301  674167385  674167385      11411 c-1984618042-20081222-00                1
     11304  674168006  674168005      11414 c-1984618042-20081222-01                1
     11306  674168089  674168089      11416 c-1984618042-20081222-02                1
     11312  674253707  674253707      11422 c-1984618042-20081223-00                1
     11315  674254316  674254315      11425 c-1984618042-20081223-01                1
     11317  674254397  674254397      11427 c-1984618042-20081223-02                1
     .........
     ...........
     ..............

測試一下，先處理recid=11301的記錄：

SQL> DECLARE
  2   devtype varchar2(256);
  3   BEGIN
  4   devtype:=dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');
  5   dbms_backup_restore.deleteBackupPiece(recid => 11301,stamp => 674167385,handle => 'c-1984618042-20081222-00',set_stamp => 674167385 ,set_count => 11411 ,pieceno => 1);
  6   dbms_backup_restore.deviceDeallocate;
  7  END;
  8  /

PL/SQL procedure successfully completed.

轉到rman中再看一下：

RMAN> list backupset 11301;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of list command at 02/01/2009 15:21:27
RMAN-06160: no backup pieces found for backup set key: 11301

ok,11301已經被成功刪除。

dbms_backup_restore.deleteBackupPiece一次只能處理一條，每次手動輸入未免繁瑣，我們可以通過sql語句直接生成處理指令碼如下：

SQL> select 'dbms_backup_restore.deleteBackupPiece(' || recid || ',' || stamp || ',''' || HANDLE || ''',' || SET_STAMP || ',' || SET_COUNT || ',' || PIECE# || ');' sqlt
  2    from v$backup_piece
  3*  where recid between 11301 and 11478
SQL> /

SQLT
----------------------------------------------------------------------------------------------------
dbms_backup_restore.deleteBackupPiece(11301,674167385,'c-1984618042-20081222-00',674167385,11411,1);
dbms_backup_restore.deleteBackupPiece(11304,674168006,'c-1984618042-20081222-01',674168005,11414,1);
dbms_backup_restore.deleteBackupPiece(11306,674168089,'c-1984618042-20081222-02',674168089,11416,1);
dbms_backup_restore.deleteBackupPiece(11312,674253707,'c-1984618042-20081223-00',674253707,11422,1);
dbms_backup_restore.deleteBackupPiece(11315,674254316,'c-1984618042-20081223-01',674254315,11425,1);
.............
.................
....................

複製到declare塊執行即可。

　　上述操作執行完之後重新，在rman中重新crosscheck及report驗證，如無錯誤，則問題解決，詳細過程限於篇幅此處不再描述。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7607759/viewspace-544956/，如需轉載，請註明出處，否則將追究法律責任。