您當前位置：首頁 > 互聯網 > ORA-21561、ORA-15055、ORA-25253 導致DG備庫無法應用歸檔

ORA-21561、ORA-15055、ORA-25253 導致DG備庫無法應用歸檔

來源：程序員人生發布時間：2014-10-08 08:00:01 閱讀次數：3327次

昨天去某客戶那里做巡檢，順便看一下上次搭建的RAC-DG環境是否正常，上次的DG是8月20日運行的，而DG備庫從8月31日之后實例就沒有開啟過，后來詢問后才得知，原來那天斷過一次電，后來重啟了機器。直到今天我過去了，才把實例啟動起來。也就是說，從8月31日到今天快1個月的時間，備庫一直處于未用狀態。

接著查看備庫歸檔，顯然已經缺失了很多了，tnread1 最后一個日志為1661，tnread2 最后一個日志為1324，而此時主庫中還保留的最早的日志是9月8日的，thread 1 最早為2055，thread 2 最早為1555。主備之間歸檔足足差了有好幾百個（正常，都快一個月沒開實例了）

ASMCMD> ls

2014_09_08/

2014_09_09/

2014_09_10/

2014_09_11/

2014_09_12/

2014_09_13/

2014_09_14/

2014_09_15/

2014_09_16/

2014_09_17/

2014_09_18/

2014_09_19/

2014_09_20/

2014_09_21/

2014_09_22/

2014_09_23/

2014_09_24/

2014_09_25/

ASMCMD> cd 2014_09_08

ASMCMD> ls

thread_1_seq_2055.500.857723297

thread_1_seq_2056.494.857725223

thread_1_seq_2057.493.857728031

thread_1_seq_2058.490.857729849

（略）……

thread_2_seq_1555.502.857723297

thread_2_seq_1556.499.857723301

thread_2_seq_1557.497.857723305

thread_2_seq_1558.496.857725225

（略）……

ASMCMD>

盡管在腳本中配置了備份完歸檔后用delete input來刪除歸檔，以減小歸檔占用的磁盤空間，可以在RMAN腳本的備份日志中看到，從8月31日起，陸續有報RMAN-08137，提示由于備庫還未獲得歸檔，導致無法刪除：

歸檔日志文件名=+DATA/sis/archivelog/2014_08_31/thread_1_seq_1661.1208.857041081 RECID=3930 STAMP=857041081

RMAN-08137: 警告: 歸檔日志未刪除, 因為備用或上游捕獲進程需要它

歸檔日志文件名=+DATA/sis/archivelog/2014_08_31/thread_1_seq_1662.1212.857042297 線程=1 序列=1662

RMAN-08137: 警告: 歸檔日志未刪除, 因為備用或上游捕獲進程需要它

歸檔日志文件名=+DATA/sis/archivelog/2014_09_01/thread_2_seq_1325.1204.857122335 線程=2 序列=1325

RMAN-08137: 警告: 歸檔日志未刪除, 因為備用或上游捕獲進程需要它

但是，由于FRA磁盤空間是有限的，使用到一定的百分比（有參數可調整），Oracle會自動清空其中的內容，以釋放空間，因此在FRA中的歸檔日志大約保留了18天，從9月8日到9月25日，而8月31日的歸檔肯定是沒有的了，最近的備份集只有到9月15日的。

于是決定重新搭建一下DG，關閉備庫實例，刪除全部數據庫文件（數據文件、控制文件、日志文件），只保留密碼文件、參數文件、tnsnames.ora、listener.ora即可，重建很方便，用11g的duplicate重新同步一下就可以了，命令如下：

rman target / auxiliary sys/oracle@sisdg

RMAN> run{

allocate channel c1 device type disk;

allocate auxiliary channel c2 device type disk;

set newname for tempfile 1 to 'D:appadministratororadatasis emp.269.852648395';

duplicate target database for standby from active database dorecover;

release channel c1;

release channel c2;

}

執行完以上操作后，備庫與主庫的歸檔就同步了

主庫：

SQL> archive log list

數據庫日志模式存檔模式

自動存檔啟用

存檔終點 USE_DB_RECOVERY_FILE_DEST

最早的聯機日志序列 2617

下一個存檔日志序列 2619

當前日志序列 2619

SQL> select thread#,max(sequence#) from v$archived_log group by thread#;

THREAD# MAX(SEQUENCE#)

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

1 2619

2 2556

備庫：

SQL> archive log list

數據庫日志模式存檔模式

自動存檔啟用

存檔終點 D:archivelog

最早的聯機日志序列 0

下一個存檔日志序列 0

當前日志序列 0

SQL> select thread#,max(sequence#) from v$archived_log group by thread#;

THREAD# MAX(SEQUENCE#)

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

1 2619

2 2556

主備庫查看了一下v$archive_dest_status，兩邊都是的status列都是valid的，因此開啟備庫的redo apply，看到日志也開始已經應用了

SQL> select thread#,sequence#,applied from v$archived_log;

THREAD# SEQUENCE# APPLIED

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

1 2617 YES

1 2618 YES

2 2556 YES

1 2619 NO

1 2620 NO

由于采用的是LGWR ASYNC模式傳遞日志，再重新創建一次standby redo logfile，主庫每個thread有3組日志，所以備庫創建了7組日志

此外，備庫的alertlog里還報了個錯誤，因為是從主庫duplicate過來的，RMAN的配置信息還保留著主庫的一些參數：

Starting control autobackup

Got error: 19624

******************** WARNING ***************************

The errors during Server autobackup are not fatal, as it

is attempted after sucessful completion of the command.

However, it is recomended to take an RMAN control file

backup as soon as possible because the Autobackup failed

with the following error:

ORA-19624: operation failed, retry possible

ORA-19504: failed to create file "C:ORABACKUPBACKUPSETSSIS1-C-3160648191-20140925-02.CTL"

ORA-27040: file create error, unable to create file

OSD-04002: 無法打開文件

O/S-Error: (OS 3) 系統找不到指定的路徑。

******************** END OF WARNING *******************

RMAN> show all;

使用目標數據庫控制文件替代恢復目錄

db_unique_name 為 SISDG 的數據庫的 RMAN 配置參數為:

CONFIGURE RETENTION POLICY TO REDUNDANCY 7;

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'c:orabackupackupsetssis1-%F.ctl';

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:APPADMINISTRATORPRODUCT11.2.0DBHOME_1DATABASESNCFSIS.ORA'; # default

備庫并沒有“ 'c:orabackupackupsets ”這個路徑，所以報錯，clear掉就可以了

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

問題到這里似乎是圓滿地解決了，但事實并非如此，當我在節點1連續切換了幾次日志后發現，雖然歸檔都能順利傳到備庫，但后續的日志始終應用不了，查看節點1和備庫的alertlog，也沒有發現有什么異常，直到我意識到應該看看節點2的情況時，才發現了點端倪。

照理說，正常情況下，在v$archive_dest_status視圖中查詢到的遠程歸檔路徑的status必須是要valid的，并且error列的狀態為空，而節點2的查詢結果是這樣的：

SQL> select dest_id,status,error from v$archive_dest where dest_id<3;

DEST_ID STATUS ERROR

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

1 VALID

2 ERROR ORA-21561: 生成 OID 失敗

此時再去查看節點2的alertlog，發現除了報ORA-21561，伴隨著的還有ORA-15055、ORA-25253等

Thu Sep 25 15:05:06 2014

WARNING: ASM communication error: op 0 state 0x0 (15055)