RMAN duplicate恢復數據庫報錯RMAN-06054問題處理

        最近生產上要搞大動做，須要把生產庫備份天天都恢復到另一臺機器上，進行測試。因而想到了用DUPLIDATE的方式，簡單方便，前期配置好目錄，而後一條命令就能夠把庫恢復出來。因而寫了恢復腳本，也經過了測試，並且生產上使用一切正常。但一次須要在測試環境恢復數據庫時，使用該腳本卻報錯RMAN-06054。奇怪的是一樣的備份在生產上的另外一個環境已經成功恢復了。下面來看看這個問題是怎麼處理的。

        先看報錯的圖：

        從報錯來看須要找節點1序號爲36615的歸檔，但當前庫的歸檔編號已經到了30多萬了，顯然是要找很早以前的歸檔。因而到MOS去找duplicate RMAN-06054相關的文章，不是不少，並且還有說是BUG的，不會這麼巧又遇到BUG了吧。但這個備份文件在其餘環境是已經成功恢復了的，爲何到了這個環境就恢復不成功了呢。簡單對比了兩個恢復過程當中的日誌，發現報錯的此次恢復日誌與成功的日誌有區別，出現了creating datafile的日誌，感受比較奇怪，但不知道是什麼緣由。結果這是一個關鍵點，若是直接從這個點去排查，可能很快就發現問題了，但就這個問題仍是耗費了2天的時間。下圖爲區別：

            下面繼續排查問題，既然DUPLICATE語句不能自動recover恢復數據，那嘗試手動recover會是什麼效果呢，看下圖：

 

        看來手動recover仍是報錯，要找sequence 36615的歸檔日誌。recover不行那open reseglogs試試。這裏勸各位，我這個是測試環境能夠隨意嘗試，若是操做的是生產環境，請敬畏生產，防止事態進一步惡化。open reseglogs的結果仍然是報錯：

查看備份文件中的歸檔日誌的備份，sequence都是30多萬根本沒有報錯要找的36615號歸檔，那這就是個結了，沒有怎麼恢復呢？

        恢復不成功怎麼辦呢？測試還等着庫用呢，難道是DUPLICATE的BUG嗎？仍是「姿式」不對？從新再恢復一遍，結果等待兩個小時後依然報一樣的錯。

        DUPLICATE恢復不成功，那我用傳紡的方式手動restore recover的方式是否是就能夠了呢？結果是理想很豐滿，現實很骨感，依然一樣報錯。那問題在哪呢？

        靜下心來想一想，recover database想找很早之前的歸檔日誌，是否是備份文件出了問題，進而致使恢復出的文件有問題？因而使用validate把備份文件又驗證了一下，結果是沒有問題。那是否是傳輸過程當中出了問題呢？對兩邊機器上的文件作了md5校驗，結果是兩邊的文件又是一致的。那問題到底出在了哪呢？

        忽然想到能夠經過查詢數據字典查文件的scn號，經過這個是否是能夠找到問題的答案呢？咱們來看一下查詢結果：

        從v$datafile中查到的文件的scn號都比報錯中的scn號大幾個數量級，難道問題不在這？又想到，v$datafile應該是contral file中記錄的信息，控制文件是從備份中恢復出來的，那應該記錄的是比較新的scn號，如何找到文件中實際的scn號的，因而想到了v$datafile_header這個數據字典。終於從這個數據字典中找到了一些線索：

        從上圖中能夠看到有部分文件的scn號比其餘的小不少，應該是出問題的數據文件了。並且對比了文件號爲12的scn號爲22575491與RMAN報錯中的scn號是吻合的。那應該就能夠解釋問題了，部分數據文件恢復出問題，致使須要更早的歸檔日誌進行恢復，但歸檔日誌已被刪除，沒法恢復，因此recover沒法進行。

        問題找到了，那從新restore出問題的文件不就行了麼，結果仍是那句理想很豐滿，現實很骨感。restore datafile時又出現了creating datafile的語句，與最開始發現的問題同樣，再次查詢v$datafile_header這個文件仍是有問題的。都已經到這一步了，問題該怎麼解決呢？

        查詢datafile爲12的備份文件，也是有的

        可是嘗試使用FULLBACKUP的tag進行恢復時，出現了新的報錯no backup of copy of datafile found to restore。這就奇怪了，前面查備份是有的，但restore時報沒有，難道是見「鬼」了嗎？

        實在想不出問題解決的辦法，因而又去查恢復成功的日誌，此次有了重大發現，原來datafile 12的備份文件是在20181218這個備份文件中的。

        如今想明白了，原來其餘同事在傳輸備份文件時，覺得只有20181219的文件是所有的備份文件，而忽略了20181218的10個備份文件。而我就用這少了10個文件的備份嘗試了屢次恢復數據庫。想一想仍是有點可笑，就跟開始說的那樣，若是一開始發現恢復日誌有異常就去詳細對比日誌的話，就不會花了這麼多時間來搗鼓沒有所有備份文件的恢復了。

        把漏傳的備份文件從新傳輸後，duplicate成功完成了恢復。

        致些，問題解決，最後提醒一下本身，作事情還須要再仔細一些。還有最重要的一點就是敬畏生產。