為什麼我的備份使用這麼多空間？ORA-19804
我有一個失敗的備份工作是這樣的：
RMAN-03002: failure of backup plus archivelog command at 10/20/2016 01:16:23 ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 67108864 bytes disk space from 107374182400 limit因此，根據其他地方的一些建議，我增加
db_recovery_file_dest_size了（從 100G 增加到 200G）並且錯誤停止發生。現在，不到一個月後，它再次發生：
RMAN-03002: failure of backup plus archivelog command at 04/14/2017 01:16:08 ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 67108864 bytes disk space from 214748364800 limit數據庫幾乎沒有那麼大。一個完整的數據泵出口小於 5G。而且我不敢相信它的變化如此之快，以至於一個月的備份實際上需要包含這麼多額外的資訊。
數據庫和備份腳本是作為更大應用程序的一部分安裝的。我沒有手動設置所有這些，但我確實有權更改它。腳本如下所示：
run { configure controlfile autobackup on; configure controlfile autobackup format for device type disk to '%F'; configure retention policy to recovery window of 31 days; allocate channel d1 type disk maxpiecesize=5G; backup as compressed backupset incremental level 0 cumulative tag 'L0'database plus archivelog delete all input; restore database validate; release channel d1; delete noprompt obsolete; restore database check logical validate; backup validate database; restore archivelog from time 'SYSDATE-14' validate; host 'copy E:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\tnsnames.ora E:\oradata\fast_recovery_area\'; host 'copy E:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\sqlnet.ora E:\oradata\fast_recovery_area\'; host 'copy E:\oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\listener.ora E:\oradata\fast_recovery_area\'; host 'copy E:\oracle\product\12.1.0\dbhome_1\database\pwd*.ora E:\oradata\fast_recovery_area\'; } list incarnation of database; list backup summary; list backup by file; list recoverable backup of database; report schema; report need backup redundancy=3; report need backup recovery window of 3 days;它每週執行。有一個每日腳本是相同的，只是它具有
level 1並且tag L1每週腳本具有level 0和tag L0。我有這個腳本的完整輸出，所以我可以根據需要填寫其他詳細資訊。
查看fast_recovery_area，最大的子目錄是ARCHIVELOG，裡面有516G的東西。這些文件可以追溯到 4 個月，這比腳本中提到的 3 天和 31 天視窗要長得多。我不明白為什麼沒有刪除舊文件。如果它抱怨達到 200G 的限制，我不明白它最初是如何增長到 516G 的。顯然我錯過了一些關於
db_recovery_file_dest_size.BACKUPSET 子目錄沒有那麼大，但裡面也有一些非常古老的文件，可以追溯到 2 年前。我也不明白為什麼那些還沒有被刪除。
最令人困惑的是備份腳本中的最後一個命令：
report need backup recovery window of 3 days;輸出是一個空列表。如果我理解正確，這意味著我可以將一切恢復到 3 天前的狀態。這已經令人驚訝了，因為我已經從備份腳本中收到這些錯誤 2 或 3 天了。更令人驚訝的是：
report need backup recovery window of 9999 days;我想要它做的是像“你無法從 9999 天前恢復任何東西，你這個可笑的人”這樣的話。但它什麼也沒說。我不知道如何解釋這一點。
如何擺脫舊垃圾並獲得備份以開始合理執行？
附加資訊
RMAN> report obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to recovery window of 31 days no obsolete backups found附加 2
RMAN> list expired archivelog all; specification does not match any archived log in the repository附加 3
自從發布了這個問題以來，磁碟已接近滿，而 rman 仍然沒有刪除任何內容。除了手動刪除最舊的文件，別無選擇。rman 似乎沒有註意到這一點。它仍然說
ORA-19804: cannot reclaim 67108864 bytes disk space from 214748364800 limit即使 fast_recovery_area 實際使用的空間量遠低於 200G 的限制（大約使用了 127G，所以應該還剩 73G，但它說找不到 64M！這是怎麼回事？）
我在其他地方得到了增加
control_file_record_keep_time和執行的建議catalog recovery area。結果是：RMAN> alter system set control_file_record_keep_time = 39; Statement processed RMAN> catalog recovery area; List of files in Recovery Area not managed by the database ==========================================================(… fast_recovery_area/ARCHIVELOG 目錄中每個文件的列表…)
number of files not managed by recovery area is 175, totaling 55.28GB我不知道這意味著什麼，但它並沒有阻止 ORA-19804 在下一次備份嘗試時再次出現。
我在備份結束時在 RMAN 中使用以下命令：
delete noprompt archivelog until time 'SYSDATE-1' backed up 1 times to device type 'SBT-TAPE';備份到磁帶且超過 1 天的所有文件都將從目錄中刪除並釋放
db_recovery_file_dest.當我進行恢復時，磁帶儲存會向我提供 RMAN 需要的歸檔日誌。
我已經設法使錯誤消失，至少現在是這樣。我在這裡將結論作為社區 wiki 答案，因為它留下了一些無法解釋的東西。
在繞過 rman 並手動刪除最舊的文件後，有必要：
crosscheck archivelog all; crosscheck backup; delete expired archivelog all; delete expired backupset;這使 rman 確信它有足夠的可用空間重新開始工作。清理後成功完成了 0 級備份，第二天早上成功完成了 1 級備份。
該解決方案的一個顯著特點是：
report need backup;仍然說它正在使用 31 天的視窗，並且沒有列出任何需要備份的文件。按照我的理解，這意味著被刪除的文件實際上已經過時了。
control_file_record_keep_time按照推薦的公式，也已更新為 39。希望這是問題的根本原因，並且從現在開始自動刪除將起作用。