RMAN - 恢復期間未找到數據文件
我在 Oracle Linux 7 上執行 12.1 SE 數據庫。在嘗試恢復時，我的 rman 腳本每晚都會收到有關失去數據文件的錯誤/警告。
我一直在使用以下腳本將 rman 執行到本地驅動器：
RUN { RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'r2cig_incr' DATABASE; BACKUP DEVICE TYPE DISK TAG 'r2cig_inc' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT; DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK; }由於磁碟空間問題，添加了第二個磁碟，我嘗試通過更改通道設備來移動 rman 以使用該磁碟，例如
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/rman/r2cig/rman/%U' maxpiecesize 10G;（事後看來，符號連結可能是一個更好的選擇，但當時我更喜歡在單獨的驅動器上明確/明顯地確定備份的位置）。
這個頻道更改似乎沒有任何效果。最初我懷疑是因為我設置了 7 天的保留期並且舊圖像仍然有效，但是 7 天后仍然在舊位置創建數據文件圖像。
隨著磁碟空間變得越來越緊張，我更改了備份腳本以使用不同的 TAG 來嘗試強制在新磁碟上創建一組新的備份映像。這似乎奏效了——當晚在新磁碟上創建了一組新的備份映像，但隨後的恢復操作似乎失敗了。
Starting recover at 19/12/2016 10:45:12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=251 device type=DISK no copy of datafile 1 found to recover no copy of datafile 2 found to recover no copy of datafile 3 found to recover no copy of datafile 4 found to recover no copy of datafile 5 found to recover我從文件中的理解是，這在第一次執行時是正常的（當沒有數據文件映像副本時），在第二次執行時是正常的（當有數據文件副本時，但沒有增量），但在第 3 次和後續執行時應該總是有一個數據文件副本和一個增量應用到它。這在過去的 6 個晚上一直失敗。
來自https://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm
腳本第一次執行時，該命令不起作用，因為既沒有數據文件副本，也沒有一級增量備份。
該腳本第二次執行時，有一個數據文件副本（由第一個 BACKUP 命令創建），但沒有增量 1 級備份，因此該命令再次無效。
在第三次執行和所有後續執行中，有一個數據文件副本和前一次執行的 1 級增量，因此 1 級增量應用於數據文件副本，使數據文件副本上升到 1 級增量的檢查點 SCN .
他們自己的增量備份似乎創建得很好並且在正確的位置，只是恢復失敗了。
有什麼方法可以查看 RMAN 在恢復命令期間查找數據文件的內容/位置？
或者有沒有辦法強制它查看新位置？
如果需要，我的 RMAN 配置如下：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/rman/r2cig/rman/%U' MAXPIECESIZE 10 G; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home/oracle/app/oracle/product/12.1.0/dbhome_1/dbs/snapcf_r2cig.f'; # default
要求數據庫做不可能的事情。
您更改了 TAG，因此您創建了一組新的初始映像副本。
隨著磁碟空間變得越來越緊張，我更改了備份腳本以使用不同的 TAG 來嘗試強制在新磁碟上創建一組新的備份映像。這似乎有效 - 新的備份映像集在那天晚上在新磁碟上創建得很好。
可以說這發生在
2016-12-13（只是假設，基於此）：這在過去的 6 個晚上一直失敗
第二天，備份腳本就
2016-12-14到了這一點：
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';所以它想將創建的圖像副本恢復
2016-12-13到更早的狀態：SYSDATE-7=2016-12-07。那樣不行。您不能將圖像副本回退到較早的狀態。當您嘗試執行此類操作時，RMAN 將查找可以恢復（向前，而不是向後）的較早映像副本，但沒有具有指定 TAG 的較早映像副本，因此：no copy of datafile 1 found to recover.所以這件事一直發生到今天。今天，這個腳本再次執行：
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';這意味著，將創建的映像副本恢復
2016-12-13到狀態：SYSDATE-7=2016-12-12。還是不行。明天
SYSDATE-7將意味著2016-12-13創建新的初始映像副本的那一天。我懷疑這也會失敗。可以說，您的腳本每天都在同一時間開始，00:00. 它從 開始，在2016-12-13 00:00完成創建圖像副本2016-12-13 01:00。腳本下一次啟動 (2016-12-20 00:00)SYSDATE-7仍然意味著更早的時間：2016-12-13 00:00。但是後天，當
SYSDATE - 7=時2016-12-14，它將開始恢復圖像副本。如果您每天執行上述腳本，它不會在前 7 天恢復任何內容，因為
SYSDATE-7. 第8天開始恢復。或者，您現在可以通過執行帶有該
PREVIEW選項的腳本來嘗試此操作。這不會做任何恢復，只是一個預覽。我懷疑，這仍然會列印與過去 6 天相同的錯誤：RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7' preview;但這應該列出要恢復的映像副本、開始和結束 SCN 以及用於恢復的日誌文件：
RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-5' preview;