怎么解決DataGuard環(huán)境中主庫RMAN刪除歸檔時報ORA-08137問題

本篇內(nèi)容主要講解“怎么解決DataGuard環(huán)境中主庫RMAN刪除歸檔時報ORA-08137問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“怎么解決DataGuard環(huán)境中主庫RMAN刪除歸檔時報ORA-08137問題”吧!

1.問題描述

客戶環(huán)境：2節(jié)點rac，Centos6.5，配置了一個單實例physical standby，數(shù)據(jù)庫數(shù)據(jù)量200g左右，日歸檔量10g

問題現(xiàn)象：2019年11月20日，源端備份軟件每天全備數(shù)據(jù)庫，RMAN刪除三天前歸檔，但是監(jiān)控系統(tǒng)報空間不足，經(jīng)過檢查，歸檔依然保留了2019年11月12日的到2019年11月20日的歸檔，并沒有刪除三天前的歸檔，經(jīng)過檢查備份軟件生成備份日志，發(fā)現(xiàn)日志中報錯如下：

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=+FRADG/honor/archivelog/2019_11_22/thread_1_seq_365.534.1024999167 thread=1 sequence=365

2.問題原因

（1）分析原因

通過報錯描述，初步判斷為兩方面原因：

a.有進程打開持有歸檔

b.歸檔日志并未傳輸應(yīng)用到physical standby端，由于配置了physical standby，默認(rèn)如果歸檔日志未在備庫應(yīng)用，源庫不允許使用RMAN刪除歸檔，防止發(fā)生gap。

（2）排查

a.排查是否有進程持有打開未刪除歸檔

11g版本中asmcmd控制臺中可以使用lsof命令查看asm磁盤中文件打開情況：

[root@db-oracle-node1 ~]# su - gridLast login: Thu Nov 21 20:08:26 CST 2019
[grid@db-oracle-node1 ~]$ asmcmd
ASMCMD> lsof -G FRADG

通過檢查，發(fā)現(xiàn)有進程打開了2019年11月13日歸檔，通過了解，此庫并未配置OGG、SharePlex等復(fù)制軟件，僅有DataGuard，且DG備庫在合肥，網(wǎng)絡(luò)丟包較為嚴(yán)重，此時判斷打開的13日歸檔為DG傳輸進程，我們?nèi)?shù)據(jù)庫中通過如下查詢語句印證了該判斷。

select process,pid,status,thread#,sequence# from v$managed_standby;

但是同時，通過執(zhí)行如下命令發(fā)現(xiàn)，隔段時間可以刪除一部分歸檔，但是報錯的歸檔序號并沒有進程打開使用，所以排除有進程持有打開導(dǎo)致ORA-08137可能性。

RMAN> delete archivelog until time 'sysdate-3';
或
RMAN> delete archivelog all completed before 'sysdate-3';

b.排查是否由于歸檔未被DataGuard應(yīng)用導(dǎo)致無法刪除

通過如下命令檢查physical standby端進程狀態(tài)：

select process,pid,status,thread#,sequence# from v$managed_standby;

發(fā)現(xiàn)RFS接收進程正在接受的歸檔確實為11月13日無法刪除的歸檔sequence#。

通過如下命令檢查primary端歸檔應(yīng)用情況：

select thread#,name,max(sequence#),applied from v$archived_log where applied='YES' group by thread#,name, applied;

發(fā)現(xiàn)physical standby端僅僅應(yīng)用到了11月13日的日志，比當(dāng)前足足落后了7天，所以基本判斷網(wǎng)絡(luò)丟包嚴(yán)重導(dǎo)致發(fā)送接收緩慢，導(dǎo)致無法歸檔無法及時被physical端接收應(yīng)用導(dǎo)致無法刪除。

3.問題解決

通過與客戶了解，客戶基本放棄了使用該physical standby，所以我們可以使用如下幾種解決辦法：

（1）選擇合適時機，清除DG環(huán)境

a.將primary置為最大性能模式

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

b.重置Data Guard初始化參數(shù)

LOG_ARCHIVE_CONFIG
DB_FILE_NAME_CONVERT
LOG_FILE_NAME_CONVERT
LOG_ARCHIVE_DEST_n指向Standby Database以及對STANDBY_LOGFILES有效的該參數(shù)
LOG_ARCHIVE_DEST_STATE_n
STANDBY_ARCHIVE_DEST
STANDBY_FILE_MANAGEMENT
FAL_SERVER
FAL_CLIENT

c.刪除Standby Redologs

SQL> SELECT GROUP# FROM V$STANDBY_LOG;
SQL> ALTER DATABASE DROP STANDBY LOGFILE GROUP <GROUP_NUMBER>;

d.如果需要，可以將physical standby轉(zhuǎn)換為獨立的數(shù)據(jù)庫使用

$ sqlplus / as sysdba
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

（2）臨時解決該問題，可以通過設(shè)置參數(shù)log_archive_dest_state_2為defer以及隱含參數(shù)_deferred_log_dest_is_valid為false來消除刪除報ORA-08137問題

_deferred_log_dest_is_valid參數(shù)默認(rèn)為TRUE，控制log_archive_dest_state_n參數(shù)設(shè)置為defer時，是否允許primary歸檔在未被physical standby應(yīng)用時刪除，防止再次將log_archive_dest_state_n設(shè)置為enable時，gap發(fā)生，導(dǎo)致physical standby不可用，該參數(shù)在11.2.0.4版本中為可動態(tài)調(diào)整參數(shù)，可以在線修改。

SQL> alter system set log_archive_dest_state_2=defer scope=both;
SQL> alter system set "_deferred_log_dest_is_valid"='FALSE' scope=both;

（3）刪除歸檔使用force選項

RMAN > delete force archivelog until time 'sysdate-3' ;

到此，相信大家對“怎么解決DataGuard環(huán)境中主庫RMAN刪除歸檔時報ORA-08137問題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！