Oracle備庫GV$ARCHIVED_LOG.APPLIED的最新歸檔日志狀態為"IN-MEMORY"對應主庫的狀態為"NO"
問題
公司數據庫每天的0,6,12,18這幾個時間點均進行歸檔備份並刪除操作，在OEM查看RMAN的備份狀態總是"COMPLETED WITH WARNINGS"。
具體查看備份日志，發現的報錯如下：
在主庫歸檔刪除策略為：CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
則報錯為：RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
在主庫歸檔刪除策略為：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
則報錯為：RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
[oracle@XXXXXX1 2021-03-03]$ ll -ltrh *.log -rw-r--r-- 1 oracle oinstall 7.2K Mar 2 23:56 rman_archbak_20210303000001.log -rw-r--r-- 1 oracle oinstall 29K Mar 3 01:44 rman_db1_20210303.log -rw-r--r-- 1 oracle oinstall 6.1K Mar 3 05:56 rman_archbak_20210303060001.log -rw-r--r-- 1 oracle oinstall 7.2K Mar 3 11:57 rman_archbak_20210303120001.log -rw-r--r-- 1 oracle oinstall 7.2K Mar 3 17:57 rman_archbak_20210303180001.log [oracle@XXXXXX1 2021-03-03]$ grep RMAN- *.log rman_archbak_20210303000001.log:RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process rman_archbak_20210303060001.log:RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process rman_archbak_20210303120001.log:RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process rman_archbak_20210303180001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210303.log:RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process[oracle@XXXXXX1 2021-03-03]$ [oracle@XXXXXX1 2021-03-03]$ cd ../2021-03-04 [oracle@XXXXXX1 2021-03-04]$ ll -ltrh *.log -rw-r--r-- 1 oracle oinstall 7.5K Mar 3 23:56 rman_archbak_20210304000001.log -rw-r--r-- 1 oracle oinstall 32K Mar 4 01:45 rman_db1_20210304.log -rw-r--r-- 1 oracle oinstall 7.1K Mar 4 05:56 rman_archbak_20210304060001.log -rw-r--r-- 1 oracle oinstall 7.9K Mar 4 11:56 rman_archbak_20210304120001.log -rw-r--r-- 1 oracle oinstall 7.2K Mar 4 17:57 rman_archbak_20210304180001.log [oracle@XXXXXX1 2021-03-04]$ grep RMAN- *.log rman_archbak_20210304000001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304060001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304060001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304060001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304060001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304060001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304120001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_archbak_20210304180001.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210304.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210304.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210304.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210304.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby rman_db1_20210304.log:RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
探究
數據庫架構為雙節點RAC+單節點ADG。
每次查看主庫GV$ARCHIVED_LOG.APPLIED的值為"NO"的記錄，總是存在並且只有一條。
而且該條記錄對應的歸檔總是其中一個節點（有時候是1節點有時候是2節點都有可能）的最新產生的歸檔日志序列號。
如下，查看APPLIED='NO'的記錄此刻為日志序列號40031的歸檔日志，並且該歸檔日志為當前1節點最新的歸檔日志。
14:53:32 SYS@XXXXXX1(1862)> select recid, dest_id, thread#, sequence#, first_time, completion_time, creator, registrar, archived, applied, deleted, status from v$archived_log where standby_dest='YES' and status='A' and applied='NO'; RECID DEST_ID THREAD# SEQUENCE# FIRST_TIME COMPLETION_TIME CREATOR REGISTRAR ARCHIVED APPLIED DELETED STA ---------- ---------- ---------- ---------- ------------------- ------------------- --------------------- --------------------- --------- --------------------------- --------- --- 83754 2 1 40031 2021-03-05 14:00:16 2021-03-05 14:30:15 LGWR LGWR YES NO NO A Elapsed: 00:00:00.08 14:53:36 SYS@XXXXXX1(1862)> select thread#,max(sequence#) "Last Primary Seq Generated" from v$archived_log val,v$database vdb where val.resetlogs_change#=vdb.resetlogs_change# group by thread# order by 1; THREAD# Last Primary Seq Generated ---------- -------------------------- 1 40031 2 27724 Elapsed: 00:00:00.08 14:54:27 SYS@XXXXXX1(1862)> select * from v$log order by THREAD#,SEQUENCE#; GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME ---------- ---------- ---------- ---------- ---------- ---------- --------- ------------------------------------------------ ------------- ------------------- ------------ ------------------- 3 1 40029 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 13:00:15 2.2413E+11 2021-03-05 13:30:17 1 1 40030 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 13:30:17 2.2413E+11 2021-03-05 14:00:16 4 1 40031 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 14:00:16 2.2414E+11 2021-03-05 14:30:15 2 1 40032 1073741824 512 2 NO CURRENT 2.2414E+11 2021-03-05 14:30:15 2.8147E+14 13 2 27722 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 13:00:15 2.2413E+11 2021-03-05 13:30:14 11 2 27723 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 13:30:14 2.2413E+11 2021-03-05 14:00:13 14 2 27724 1073741824 512 2 YES INACTIVE 2.2413E+11 2021-03-05 14:00:13 2.2414E+11 2021-03-05 14:30:15 12 2 27725 1073741824 512 2 NO CURRENT 2.2414E+11 2021-03-05 14:30:15 2.8147E+14 8 rows selected. Elapsed: 00:00:00.01
在主庫創建測試表，備庫立馬可以看到新建的表，同步時間基本保持在毫秒級別內不存在GAP和大的延遲。
從備庫的警告日志看，40031的日志在14:26:53秒就在備庫歸檔成功，但是從上邊查詢記錄看，14:53:32主庫的查看結果為APPLIED='NO'。
查詢備庫的應用情況，40031的狀態為"IN-MEMORY"，當前的MRP進程應用日志為主庫V$LOG.STATUS='CURRENT'的40032（表示實時同步）：
14:52:53 SYS@xxxxxxstb(1308)> select sequence# from gv$archived_log where applied ='IN-MEMORY'; SEQUENCE# ---------- 40031 Elapsed: 00:00:00.14 14:52:54 SYS@xxxxxxstb(1308)> select process, pid, status, thread#, sequence#, block# from v$managed_standby where process='MRP0'; PROCESS PID STATUS THREAD# SEQUENCE# BLOCK# --------------------------- ---------- ------------------------------------ ---------- ---------- ---------- MRP0 15085 APPLYING_LOG 1 40032 643116 Elapsed: 00:00:00.00
到這里就有點奇怪了，40031已經在備庫應用了，只不過備庫的400031的APPLIED='IN-MEMORY'。
但確實是應用了，主庫40031的APPLIED狀態沒實時更新為YES。
原因
根據文檔The Latest Archivelog On Standby Database Keep The Status Of In-Memory (文檔 ID 1384371.1)中指出（右鍵翻譯中文），
備庫最新日志狀態為"IN-MEMORY"，表示已完全應用存檔的日志，但恢復檢查點尚未移出日志。
從Broker的角度來看，“ IN-MEMORY”等效於“ YES”，因為Broker關心是否已通過恢復應用日志，而不關心日志是否已被檢查點。
從RMAN的角度來看，“ IN-MEMORY”等效於“ NO”，因為RMAN只關心是否可以刪除日志。幸運的是，此txn不需要更改RMAN，因為今天查看此列的所有RMAN代碼都會檢查該值是“ YES”或者不是“ YES”。
通常，只有在運行備用恢復時（或在備用實例崩潰后），才能在備用數據庫上看到此值。
當備用恢復會話結束時，只要實例不死，任何“內存中”狀態都將更改為“是”或“否”。如果恢復正常，恢復將檢查所有內容，從而使所有處於“ IN-MEMORY”狀態的歸檔日志都變為“ YES”。如果異常結束並且恢復無法將檢查點移到前面，則所有未完全檢查點的具有“ IN-MEMORY”狀態的日志都將更改為“ NO”。如果備用實例崩潰，則不會執行此操作。
狀態“IN-MEMORY”來自Oracle 11g恢復概念的變化。 在以前的版本中，一旦完全讀取了日志文件（已到達日志文件的最后一個SCN），我們將執行完整的恢復檢查點，即。 此日志序列中的所有更改都將寫入數據庫文件中，並且標題和控制文件也將更新。
從Oracle 11g開始，我們執行某種“延遲檢查點”，實際上我們在以后的某個時間執行該檢查點，以提高恢復和整體性能。 因此，當狀態為“內存中”時，這意味着在實例中更改了相應的塊，但是這些更改尚未寫入數據庫文件中。 因此，我們必須使那些ArchiveLogs保持可用，因為在發生崩潰的情況下，我們仍然需要那些ArchiveLogs從數據庫文件中的最后一個SCN恢復恢復。
因此，這是您案例中的預期行為。
也就是說，這是正常的。
那么要解決RMAN的報錯，可以直接忽略該報錯。
要么就是先備份歸檔日志，再刪除半個小時前的已經被備份的歸檔日志了（數據庫強制每半個小時歸檔一次）。
參考
The Latest Archivelog On Standby Database Keep The Status Of In-Memory (文檔 ID 1384371.1)
v$archived_log: applied column is not marked if recovery applied the redo from SRL (文檔 ID 1481927.1)