<ul id="cqego"></ul><del id="cqego"></del>

記一次RMAN-20207報錯處理過程

IT那活兒發(fā)布于2023-01-11 13:20 / 2761人閱讀

記一次RMAN-20207報錯處理過程

概述

最近給一套庫做不完全恢復(fù),其中映象較為深刻的對RMAN-20207（如下圖）的報錯處理方式，下面在測試環(huán)境中來復(fù)現(xiàn)。

現(xiàn) 象模擬

1、前提條件，全庫備份在，后續(xù)歸檔文件在。

==》我這套測試環(huán)境中只有1，2，3，4，5。這個5個數(shù)據(jù)文件。system，sysaux，undo（rac環(huán)境中各個節(jié)點都要還原）這個三類表空間是必須要恢復(fù)的。5號表空間是模擬業(yè)務(wù)表空間，是我們這次要恢復(fù)的目標(biāo)。

==》通過如上命令還原表空間對應(yīng)的數(shù)據(jù)文件。

==》這里通過skip方式跳過不需要恢復(fù)的表空間，恢復(fù)完成后，使用resetlogs方式打開數(shù)據(jù)庫。紅框中2號文件被offlinedrop，這里的2號文件對應(yīng)的是test2這個表空間。換個思路就是說，我們不使用skip命令，而是提前將不需要的表空間對應(yīng)的數(shù)據(jù)文件給offlinedrop掉，就可以直接使用recoverdatabase ;進(jìn)行恢復(fù)。（當(dāng)然這是另外一種思路了）。

2、發(fā)現(xiàn)只恢復(fù)test1表空間，數(shù)據(jù)有丟失，需要二次恢復(fù)把test2表空間給加上如下圖：

==》這里還原時新加了test2表空間對應(yīng)的數(shù)據(jù)文件，2號文件。

==》隨后進(jìn)行recover報RMAN-20209.這里就復(fù)現(xiàn)了之前生產(chǎn)的報錯。

關(guān)于報錯原因：

我這里模擬使用了resetlogs后的控制文件進(jìn)行二次恢復(fù)的（如上圖紅框），因為incarnation發(fā)生了改變，導(dǎo)致恢復(fù)報錯。實際上生產(chǎn)上進(jìn)行了恢復(fù)就是犯了這個錯誤，從而引發(fā)后續(xù)一系列的問題。

解決方案

1、通過resetdatabase toincarnation，調(diào)整到resetlog之前的incarnation號。此外，根據(jù)二次恢復(fù)需要，檢查v$datafile中status狀態(tài)，將新添加的文件修改為online（首次恢復(fù)，通過skip命令調(diào)整成了offline。實際生產(chǎn)中，我們雖然reset了incarnation,但是未將新增的文件給online就進(jìn)行了recover，雖然recover沒有報錯，但在啟庫階段數(shù)據(jù)庫一直拉不起來，最終導(dǎo)致第三次重新恢復(fù)。