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

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

1.問題描述

客戶環境：2節點rac，Centos6.5，配置了一個單實例physical standby，數據庫數據量200g左右，日歸檔量10g

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

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.歸檔日志并未傳輸應用到physical standby端，由于配置了physical standby，默認如果歸檔日志未在備庫應用，源庫不允許使用RMAN刪除歸檔，防止發生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

通過檢查，發現有進程打開了2019年11月13日歸檔，通過了解，此庫并未配置OGG、SharePlex等復制軟件，僅有DataGuard，且DG備庫在合肥，網絡丟包較為嚴重，此時判斷打開的13日歸檔為DG傳輸進程，我們去數據庫中通過如下查詢語句印證了該判斷。

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

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

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

b.排查是否由于歸檔未被DataGuard應用導致無法刪除

通過如下命令檢查physical standby端進程狀態：

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

發現RFS接收進程正在接受的歸檔確實為11月13日無法刪除的歸檔sequence#。

通過如下命令檢查primary端歸檔應用情況：

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

發現physical standby端僅僅應用到了11月13日的日志，比當前足足落后了7天，所以基本判斷網絡丟包嚴重導致發送接收緩慢，導致無法歸檔無法及時被physical端接收應用導致無法刪除。

3.問題解決

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

（1）選擇合適時機，清除DG環境

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

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

b.重置Data Guard初始化參數

LOG_ARCHIVE_CONFIG
DB_FILE_NAME_CONVERT
LOG_FILE_NAME_CONVERT
LOG_ARCHIVE_DEST_n指向Standby Database以及對STANDBY_LOGFILES有效的該參數
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轉換為獨立的數據庫使用

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

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

_deferred_log_dest_is_valid參數默認為TRUE，控制log_archive_dest_state_n參數設置為defer時，是否允許primary歸檔在未被physical standby應用時刪除，防止再次將log_archive_dest_state_n設置為enable時，gap發生，導致physical standby不可用，該參數在11.2.0.4版本中為可動態調整參數，可以在線修改。

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環境中主庫RMAN刪除歸檔時報ORA-08137問題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！