ORA-21561、ORA-15055、ORA-25253 導致DG備庫無法應用歸檔
昨天去某客戶那裡做巡檢,順便看一下上次搭建的RAC-DG環境是否正常,上次的DG是8月20日啟動並執行,而DG備庫從8月31日之後執行個體就沒有開啟過,後來詢問後才得知,原來那天斷過一次電,後來重啟了機器。直到今天我過去了,才把執行個體啟動起來。也就是說,從8月31日到今天快1個月的時間,備庫一直處於未用狀態。 接著查看備庫歸檔,顯然已經缺失了很多了,tnread1 最後一個日誌為1661,tnread2 最後一個日誌為1324,而此時主庫中還保留的最早的日誌是9月8日的,thread 1 最早為2055,thread 2 最早為1555。主備之間歸檔足足差了有好幾百個(正常,都快一個月沒開執行個體了) ASMCMD> ls2014_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_08ASMCMD> lsthread_1_seq_2055.500.857723297thread_1_seq_2056.494.857725223thread_1_seq_2057.493.857728031thread_1_seq_2058.490.857729849(略)……thread_2_seq_1555.502.857723297thread_2_seq_1556.499.857723301thread_2_seq_1557.497.857723305thread_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=857041081RMAN-08137: 警告: 歸檔日誌未刪除, 因為備用或上遊捕獲進程需要它歸檔記錄檔名=+DATA/sis/archivelog/2014_08_31/thread_1_seq_1662.1212.857042297 線程=1 序列=1662RMAN-08137: 警告: 歸檔日誌未刪除, 因為備用或上遊捕獲進程需要它歸檔記錄檔名=+DATA/sis/archivelog/2014_09_01/thread_2_seq_1325.1204.857122335 線程=2 序列=1325RMAN-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@sisdgRMAN> run{
allocate channel c1 device type disk;allocate auxiliary channel c2 device type disk;set newname for tempfile 1 to 'D:\app\administrator\oradata\sis\temp.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當前日誌序列 2619SQL> 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當前日誌序列 0SQL> 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 autobackupGot error: 19624******************** WARNING ***************************The errors during Server autobackup are not fatal, as itis attempted after sucessful completion of the command.However, it is recomended to take an RMAN control filebackup as soon as possible because the Autobackup failedwith the following error:ORA-19624: operation failed, retry possibleORA-19504: failed to create file "C:\ORABACKUP\BACKUPSETS\SIS1-C-3160648191-20140925-02.CTL"ORA-27040: file create error, unable to create fileOSD-04002: 無法開啟檔案O/S-Error: (OS 3) 系統找不到指定的路徑。******************** END OF WARNING *******************
更多詳情見請繼續閱讀下一頁的精彩內容:
在CentOS 6.4下安裝Oracle 11gR2(x64)
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 處理方法