RESETLOGS後沒有備份情況下的數據恢復

媒體恢復分完全恢復和不完全恢復。不完全恢復可以恢復到指定的時刻或系統更改號，但不完全恢復之後剩余日志文件就不可用，必須重置日志序列號，用RESETLOGS選項打開數據庫，此後數據庫變成一個新形體，為了將來的恢復，必須重做一致備份。而且，RESETLOGS之前的備份已不可用。但是，很可能在RESETLOGS後沒有做數據庫的一致備份，而數據庫又不認識RESETLOGS之前的備份，此時該如何恢復RESETLOGS後的數據呢？雖說本文提供的技術能實現用RESETLOGS之前的備份恢復到RESETLOGS之後某一時刻的數據，但這也是挽救措施，筆者強烈建議讀者要做RESETLOGS之後的一致數據庫備份。

技術的理論基礎

Oracle僅根據系統更改號（SCN）進行恢復操作，所有數據文件必須恢復到同一時間點，並在該點後未作任何改動，才能打開數據庫。數據庫的SCN是唯一的，並隨著數據庫生存期間的操作事務增加而增加（可能不連續）。SCN的值永遠不會為0，除非重新創建數據庫。SCN的序列的遞增性不隨數據庫的任何操作而改變，即使是RESETLOGS也如此。RESETLOGS清除所有聯機日志文件中未應用的重做記錄，RESETLOGS只重置日志文件的序列號為1，但對SCN無影響，SCN仍按原序列遞增。

在控制文件中保存resetlogs SCN和計數器，以便唯一地標識用RESETLOGS選項執行的每一次打開數據庫的操作。這個值被寫進每個數據文件頭以及重做日志文件。如果重做日志文件的日志序列號與Oracle的要求值不相符，則在恢復中不能應用重做日志文件。執行不完全恢復後，數據庫要求日志序列號為1的日志文件，所以原來的日志序列中剩余的日志文件將不可用。RESETLOGS操作創建數據庫的新形體，即一個擁有從1開始的新的日志序列號流的數據庫。

根據以上理論，SCN為順序數據流，在數據庫存在期間始終遞增，而日志文件序列流也是遞增序列，只不過會因RESETLOGS而重置，但日志文件序列流中的SCN序列流卻保持遞增不便。因此可以用RESETLOGS之前的歸檔日志流和RESETLOGS之後的歸檔日志流來連接和延續SCN序列流，這樣就實現了用RESETLOGS之前的備份恢復RESETLOGS之後的數據。前提是保證兩股日志流（RESETLOGS之前的歸檔日志流和RESETLOGS之後的歸檔日志流）完整，並且有相應兩股日志流的控制文件。

即使能夠挽救數據，也要滿足下列條件

（1）Oracle版本等於或高於7.3.3。

（2）能夠成功實現RESETLOGS之前的不完全媒體恢復。

（3）RESETLOGS後沒有提供一致備份。

（4）RESETLOGS之前提供一致性備份（冷或熱）。

（5）必須備份RESETLOGS之前和之後的控制文件。

（6）分別保存RESETLOGS之前和之後的歸檔日志文件到不同位置，提供用於恢復的所有歸檔日志，並保證日志可用。

建議

（一）強烈建議RESETLOGS之後要備份數據庫。

（二）在RESETLOGS前保證數據庫以前備份的數據安全，在創建RESETLOGS之後的一個一致性備份之前，一定不可刪掉在RESETLOGS前創建的一致數據庫備份。如不是為了空間需要，建議永久保留RESETLOGS前創建的一致數據庫備份，包括數據文件、控制文件和歸檔日志。

（三）在RESETLOGS之後立即創建控制文件備份，並把歸檔日志單獨存放。

（四）在以RESETLOGS方式打開數據庫前，備份在恢復中用過的所有歸檔日志和聯機重做日志。

（五）進行RESETLOGS後，備份alter.log文件，因為該文件保存著point-in-time恢復後記錄的change#（系統更改號SCN）。

（六）把RESETLOGS之前和之後的歸檔日志文件保存到不同位置，用於恢復。因為可能存在如下情形：如果RESETLOGS之前和之後的歸檔日志文件保存到相同位置，而RESETLOGS之後的歸檔日志文件序列號從1開始，隨著日志切換的不斷發生，新的日志序列號要增長到與RESETLOGS之前日志序列號相同的時候，那時RESETLOGS之前的歸檔日志文件將被新日志文件覆蓋，從而使RESETLOGS之前的日志序列出現空洞。