RMAN duplicate恢復(fù)數(shù)據(jù)庫報錯RMAN-06054問題處理

        最近生產(chǎn)上要搞大動作，需要把生產(chǎn)庫備份每天都恢復(fù)到另外一臺機器上，進行測試。于是想到了用DUPLIDATE的方式，簡單方便，前期配置好目錄，然后一條命令就可以把庫恢復(fù)出來。于是寫了恢復(fù)腳本，也通過了測試，而且生產(chǎn)上使用一切正常。但一次需要在測試環(huán)境恢復(fù)數(shù)據(jù)庫時，使用該腳本卻報錯RMAN-06054。奇怪的是同樣的備份在生產(chǎn)上的另一個環(huán)境已經(jīng)成功恢復(fù)了。下面來看看這個問題是怎么處理的。

        先看報錯的圖：

        從報錯來看需要找節(jié)點1序號為36615的歸檔，但當(dāng)前庫的歸檔編號已經(jīng)到了30多萬了，顯然是要找很早之前的歸檔。于是到MOS去找duplicate RMAN-06054相關(guān)的文章，不是很多，而且還有說是BUG的，不會這么巧又遇到BUG了吧。但這個備份文件在其他環(huán)境是已經(jīng)成功恢復(fù)了的，為什么到了這個環(huán)境就恢復(fù)不成功了呢。簡單對比了兩個恢復(fù)過程中的日志，發(fā)現(xiàn)報錯的這次恢復(fù)日志與成功的日志有區(qū)別，出現(xiàn)了creating datafile的日志，感覺比較奇怪，但不知道是什么原因。結(jié)果這是一個關(guān)鍵點，如果直接從這個點去排查，可能很快就發(fā)現(xiàn)問題了，但就這個問題還是耗費了2天的時間。下圖為區(qū)別：

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

        看來手動recover還是報錯，要找sequence 36615的歸檔日志。recover不行那open reseglogs試試。這里勸各位，我這個是測試環(huán)境可以隨意嘗試，如果操作的是生產(chǎn)環(huán)境，請敬畏生產(chǎn)，防止事態(tài)進一步惡化。open reseglogs的結(jié)果仍然是報錯：

查看備份文件中的歸檔日志的備份，sequence都是30多萬根本沒有報錯要找的36615號歸檔，那這就是個結(jié)了，沒有怎么恢復(fù)呢？

        恢復(fù)不成功怎么辦呢？測試還等著庫用呢，難道是DUPLICATE的BUG嗎？還是“姿勢”不對？重新再恢復(fù)一遍，結(jié)果等待兩個小時后依然報同樣的錯。

        DUPLICATE恢復(fù)不成功，那我用傳紡的方式手動restore recover的方式是不是就可以了呢？結(jié)果是理想很豐滿，現(xiàn)實很骨感，依然同樣報錯。那問題在哪呢？

        靜下心來想想，recover database想找很早以前的歸檔日志，是不是備份文件出了問題，進而導(dǎo)致恢復(fù)出的文件有問題？于是使用validate把備份文件又驗證了一下，結(jié)果是沒有問題。那是不是傳輸過程中出了問題呢？對兩邊機器上的文件做了md5校驗，結(jié)果是兩邊的文件又是一致的。那問題到底出在了哪呢？

        突然想到可以通過查詢數(shù)據(jù)字典查文件的scn號，通過這個是不是可以找到問題的答案呢？我們來看一下查詢結(jié)果：

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

        從上圖中可以看到有部分文件的scn號比其他的小很多，應(yīng)該是出問題的數(shù)據(jù)文件了。而且對比了文件號為12的scn號為22575491與RMAN報錯中的scn號是吻合的。那應(yīng)該就可以解釋問題了，部分數(shù)據(jù)文件恢復(fù)出問題，導(dǎo)致需要更早的歸檔日志進行恢復(fù)，但歸檔日志已被刪除，無法恢復(fù)，所以recover無法進行。

        問題找到了，那重新restore出問題的文件不就好了么，結(jié)果還是那句理想很豐滿，現(xiàn)實很骨感。restore datafile時又出現(xiàn)了creating datafile的語句，與最開始發(fā)現(xiàn)的問題一樣，再次查詢v$datafile_header這個文件還是有問題的。都已經(jīng)到這一步了，問題該怎么解決呢？

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

        但是嘗試使用FULLBACKUP的tag進行恢復(fù)時，出現(xiàn)了新的報錯no backup of copy of datafile found to restore。這就奇怪了，前面查備份是有的，但restore時報沒有，難道是見“鬼”了嗎？

        實在想不出問題解決的辦法，于是又去查恢復(fù)成功的日志，這次有了重大發(fā)現(xiàn)，原來datafile 12的備份文件是在20181218這個備份文件中的。

        現(xiàn)在想明白了，原來其他同事在傳輸備份文件時，以為只有20181219的文件是全部的備份文件，而忽略了20181218的10個備份文件。而我就用這少了10個文件的備份嘗試了多次恢復(fù)數(shù)據(jù)庫。想想還是有點好笑，就跟開始說的那樣，如果一開始發(fā)現(xiàn)恢復(fù)日志有異常就去詳細對比日志的話，就不會花了這么多時間來搗鼓沒有全部備份文件的恢復(fù)了。

        把漏傳的備份文件重新傳輸后，duplicate成功完成了恢復(fù)。

        致些，問題解決，最后提醒一下自己，做事情還需要再仔細一些。還有最重要的一點就是敬畏生產(chǎn)。