Oracle10g冷備份恢復實戰

引言： 單位需要對一例數據庫環境進行數據恢復，筆者備份好原環境下的文件后，搭建與原有一致的環境，根據報錯代碼進行處置，終于實現了正常啟動數據庫。本文介紹故障的排除過程。

接到業務部門的支援請求，需要對一例數據庫環境進行數據恢復，雖然好久不碰數據庫，自我感覺已有許多生疏，但還是抱著技術人員的好奇心打算嘗試一下。

故障處理方案

首先了解當前的基本情況，原環境是一個基于Windows XP部署的Oracle 10g數據庫物理機，受硬件故障影響，數據庫環境已不可用，但ORACLE_HOME目錄下，包括表空間dbf在內的所有文件均未受損，數據庫用戶賬號密碼還記得，此外就沒有其他信息了?；诖?，計劃單獨重建一個Windows虛機將實例進行異機恢復，成功后將數據庫進行數據泵導出提供給對方自行利用。

第一次嘗試總會失敗

由于原環境Oracle 10g的情況無法收集足夠多信息，第一次嘗試時操作系統安裝了Windows 7 x64版，數據庫軟件采用64位的10.2.0.4.0版。根據網上搜索的資料，大致確定了處置的步驟：創建同名實例→停止實例→覆蓋dbf數據文件→啟動實例→根據報錯提示見招拆招。然而，替換數據文件后的實例啟動，報錯信息涉及參數、控制文件、日志文件等一系列報錯，根本無從下手，必須立即調整解決辦法。

基于手上已有完整的冷備份，實例自身的信息是完整的，假設能和Oracle軟件建立關聯，則聯系的緊密性會比替換一個實例中的文件更有效。觀察當前實例各個文件和文件夾的路徑，通過dbca刪除剛才建立的實例，將冷備份文件復制到已刪除的實例創建的文件路徑，使用oradim命令在命令行下添加實例，注意使用管理員身份運行“命令提示符”，否則權限不足又導致其他的報錯。

添加成功后立即進入sqlplus啟動實例，報錯代碼LRM-00109，提示無法打開路徑中的配置文件，檢查確認目標路徑缺少實例的配置文件，將冷備份的pfile文件復制到報錯提示的路徑，并修改為報錯信息中一致的文件名。再次啟動實例，實例加載成功，但也拋出了新的報錯代碼ORA-01157和ORA-01110，該報錯無法鎖定dbf文件，可以很明顯看到，提示的文件路徑是原環境的，與當前的路徑不一致，需要修正路徑信息。

分析當前的狀況，雖然加載了實例，但數據文件路徑，數據文件并未加載到實例中，因此數據文件此時就是離線狀態，可以直接嘗試修改文件參數。

數據庫已更改。

再次加載實例，觀察到報錯代碼沒變，但提示的dbf文件已經變了，說明修改是有效的。按此方法將冷備份中所有的dbf文件都做這一修改，隨后重啟實例，顯示的報錯代碼依然未變，但報錯文件已經變成了redo01.log，嘗試按同樣的方法修改重做日志文件的路徑，竟然也是有效的。

數據庫已更改。

這次啟動實例，已可確定數據文件加載無誤，但報錯代碼又更新為ORA-01092，進一步查看$ORACLE_HOMEadminorcldbdumpalert_orcldb.log日志，找到如下信息：

ORA-00704: 引導程序進程失敗

ORA-39700:必 須 用UPGRADE 選項打開數據庫

由此判斷，這里選用的Oracle 10g版本高于原有環境，需要升級數據庫實例，似乎成功就在眼前。進入sqlplus嘗試啟動。

通過netca工具檢查監聽，刪除現有監聽和本地服務名，重建添加監聽和本地服務名，再次進入sqlplus啟動實例，終于不再出現任何報錯，接下來就是執行升級數據庫的腳本。

然而，報錯依然如霧霾一般揮之不去，在執行一個替換函數的語句時彈出了一連串的報錯提示，腳本執行終止。此時，嘗試在sqlplus中連接實例，出現了ORA-12526報錯，實例已經處于restricted模式，面對沒完沒了的報錯，信心不斷被瓦解，但依然抱有一絲希望。既然實例已經啟動，是否不需要升級數據庫實例就可以將表空間和schemas一起導出呢？可是，技術的問題總是那么無情，UDE-00008、ORA-12526、ORA-39710、ORA-01017、ORA-06553、PLS-801等一個又一個的報錯伴隨著排錯過程不斷冒出，這樣下去就越來越偏離恢復的目標了。

恢復數據要將復雜的事情簡單化

眼看著一步之遙的屏障卻無法逾越，恢復的時長也變得越來越不可控，必須調整策略，讓整個恢復操作回到掌控之中。

重新梳理了一遍已做過的操作，對冷備份文件的加載其實已經實現了，只不過受Oracle版本的影響而無法導出。一般人搭環境往往都用官網默認的介質進行安裝，原環境也很有可能用的就是10.2.0.1.0版。當前的狀況假設找到癥結可能很快就能導出，可根據現有經驗無法預計剩余的時間，重新裝一次Windows XP和32位Oracle 10g雖然耗時，但時間是可控的，如果分析正確，匹配的版本環境可能就沒有那么多障礙了，值得重新嘗試一次。

結合上一輪嘗試的經驗，直接創建同名實例，然后停止但不刪除實例，復制冷備份文件到默認目錄，啟動實例，出現了上一輪熟悉的報錯代碼ORA-01157和ORA-01110，立即對所有復制進來的dbf和redo文件路徑進行修改，隨后停止和重新啟動一次實例，本以為會再彈出新的報錯提示，卻是不期而至的正常加載數據庫和實例，冷備份的恢復真的成功了么？最好的檢驗就是導出數據。

緊張地盯著屏幕上快速滾動的信息直到導出結束，過程中沒有出現一個報錯或警告，終于可以長舒一口氣，至此確認冷備份的數據恢復完美的達到了預期目標。

經驗總結

重新梳理一次整個恢復的過程，可以簡要地整理為如下步驟。

1.保留好原環境ORACLE_BASE路徑下所有的文件，雖然不一定都用得上，但每多一種備份就多一層恢復的時效和完整性，另外，需注意使用時務必再復制為副本。

2.搭建與原有一致的環境，至少要保持Oracle數據庫系統的版本號一致，有效降低恢復的難度。

3.創建同名實例，創建監聽，停止但不刪除實例，覆蓋待恢復的dbf文件到現有實例的文件目錄。

4.執行啟動實例命令，根據報錯代碼進行處置，直到正常啟動實例。

數據庫恢復是每一個DBA的必修課，場景、誘因、日常運維習慣、部署環境的細微差異等都會影響恢復可采用的技術和思路。本例所采用的恢復方法并不一定符合最佳實踐的標準，遇到的報錯代碼有的屬于常見報錯，很容易被網上的修復方法所誤導，但整個操作過程堅持了既定目標并不斷調整操作策略，也不失一次成功的實踐。