Oracle10g冷備份恢復(fù)實(shí)戰(zhàn)

引言： 單位需要對(duì)一例數(shù)據(jù)庫(kù)環(huán)境進(jìn)行數(shù)據(jù)恢復(fù)，筆者備份好原環(huán)境下的文件后，搭建與原有一致的環(huán)境，根據(jù)報(bào)錯(cuò)代碼進(jìn)行處置，終于實(shí)現(xiàn)了正常啟動(dòng)數(shù)據(jù)庫(kù)。本文介紹故障的排除過(guò)程。

接到業(yè)務(wù)部門(mén)的支援請(qǐng)求，需要對(duì)一例數(shù)據(jù)庫(kù)環(huán)境進(jìn)行數(shù)據(jù)恢復(fù)，雖然好久不碰數(shù)據(jù)庫(kù)，自我感覺(jué)已有許多生疏，但還是抱著技術(shù)人員的好奇心打算嘗試一下。

故障處理方案

首先了解當(dāng)前的基本情況，原環(huán)境是一個(gè)基于Windows XP部署的Oracle 10g數(shù)據(jù)庫(kù)物理機(jī)，受硬件故障影響，數(shù)據(jù)庫(kù)環(huán)境已不可用，但ORACLE_HOME目錄下，包括表空間dbf在內(nèi)的所有文件均未受損，數(shù)據(jù)庫(kù)用戶賬號(hào)密碼還記得，此外就沒(méi)有其他信息了?；诖耍?jì)劃單獨(dú)重建一個(gè)Windows虛機(jī)將實(shí)例進(jìn)行異機(jī)恢復(fù)，成功后將數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)泵導(dǎo)出提供給對(duì)方自行利用。

第一次嘗試總會(huì)失敗

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

基于手上已有完整的冷備份，實(shí)例自身的信息是完整的，假設(shè)能和Oracle軟件建立關(guān)聯(lián)，則聯(lián)系的緊密性會(huì)比替換一個(gè)實(shí)例中的文件更有效。觀察當(dāng)前實(shí)例各個(gè)文件和文件夾的路徑，通過(guò)dbca刪除剛才建立的實(shí)例，將冷備份文件復(fù)制到已刪除的實(shí)例創(chuàng)建的文件路徑，使用oradim命令在命令行下添加實(shí)例，注意使用管理員身份運(yùn)行“命令提示符”，否則權(quán)限不足又導(dǎo)致其他的報(bào)錯(cuò)。

添加成功后立即進(jìn)入sqlplus啟動(dòng)實(shí)例，報(bào)錯(cuò)代碼LRM-00109，提示無(wú)法打開(kāi)路徑中的配置文件，檢查確認(rèn)目標(biāo)路徑缺少實(shí)例的配置文件，將冷備份的pfile文件復(fù)制到報(bào)錯(cuò)提示的路徑，并修改為報(bào)錯(cuò)信息中一致的文件名。再次啟動(dòng)實(shí)例，實(shí)例加載成功，但也拋出了新的報(bào)錯(cuò)代碼ORA-01157和ORA-01110，該報(bào)錯(cuò)無(wú)法鎖定dbf文件，可以很明顯看到，提示的文件路徑是原環(huán)境的，與當(dāng)前的路徑不一致，需要修正路徑信息。

分析當(dāng)前的狀況，雖然加載了實(shí)例，但數(shù)據(jù)文件路徑，數(shù)據(jù)文件并未加載到實(shí)例中，因此數(shù)據(jù)文件此時(shí)就是離線狀態(tài)，可以直接嘗試修改文件參數(shù)。

數(shù)據(jù)庫(kù)已更改。

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

數(shù)據(jù)庫(kù)已更改。

這次啟動(dòng)實(shí)例，已可確定數(shù)據(jù)文件加載無(wú)誤，但報(bào)錯(cuò)代碼又更新為ORA-01092，進(jìn)一步查看$ORACLE_HOMEadminorcldbdumpalert_orcldb.log日志，找到如下信息：

ORA-00704: 引導(dǎo)程序進(jìn)程失敗

ORA-39700:必 須 用UPGRADE 選項(xiàng)打開(kāi)數(shù)據(jù)庫(kù)

由此判斷，這里選用的Oracle 10g版本高于原有環(huán)境，需要升級(jí)數(shù)據(jù)庫(kù)實(shí)例，似乎成功就在眼前。進(jìn)入sqlplus嘗試啟動(dòng)。

通過(guò)netca工具檢查監(jiān)聽(tīng)，刪除現(xiàn)有監(jiān)聽(tīng)和本地服務(wù)名，重建添加監(jiān)聽(tīng)和本地服務(wù)名，再次進(jìn)入sqlplus啟動(dòng)實(shí)例，終于不再出現(xiàn)任何報(bào)錯(cuò)，接下來(lái)就是執(zhí)行升級(jí)數(shù)據(jù)庫(kù)的腳本。

然而，報(bào)錯(cuò)依然如霧霾一般揮之不去，在執(zhí)行一個(gè)替換函數(shù)的語(yǔ)句時(shí)彈出了一連串的報(bào)錯(cuò)提示，腳本執(zhí)行終止。此時(shí)，嘗試在sqlplus中連接實(shí)例，出現(xiàn)了ORA-12526報(bào)錯(cuò)，實(shí)例已經(jīng)處于restricted模式，面對(duì)沒(méi)完沒(méi)了的報(bào)錯(cuò)，信心不斷被瓦解，但依然抱有一絲希望。既然實(shí)例已經(jīng)啟動(dòng)，是否不需要升級(jí)數(shù)據(jù)庫(kù)實(shí)例就可以將表空間和schemas一起導(dǎo)出呢？可是，技術(shù)的問(wèn)題總是那么無(wú)情，UDE-00008、ORA-12526、ORA-39710、ORA-01017、ORA-06553、PLS-801等一個(gè)又一個(gè)的報(bào)錯(cuò)伴隨著排錯(cuò)過(guò)程不斷冒出，這樣下去就越來(lái)越偏離恢復(fù)的目標(biāo)了。

恢復(fù)數(shù)據(jù)要將復(fù)雜的事情簡(jiǎn)單化

眼看著一步之遙的屏障卻無(wú)法逾越，恢復(fù)的時(shí)長(zhǎng)也變得越來(lái)越不可控，必須調(diào)整策略，讓整個(gè)恢復(fù)操作回到掌控之中。

重新梳理了一遍已做過(guò)的操作，對(duì)冷備份文件的加載其實(shí)已經(jīng)實(shí)現(xiàn)了，只不過(guò)受Oracle版本的影響而無(wú)法導(dǎo)出。一般人搭環(huán)境往往都用官網(wǎng)默認(rèn)的介質(zhì)進(jìn)行安裝，原環(huán)境也很有可能用的就是10.2.0.1.0版。當(dāng)前的狀況假設(shè)找到癥結(jié)可能很快就能導(dǎo)出，可根據(jù)現(xiàn)有經(jīng)驗(yàn)無(wú)法預(yù)計(jì)剩余的時(shí)間，重新裝一次Windows XP和32位Oracle 10g雖然耗時(shí)，但時(shí)間是可控的，如果分析正確，匹配的版本環(huán)境可能就沒(méi)有那么多障礙了，值得重新嘗試一次。

結(jié)合上一輪嘗試的經(jīng)驗(yàn)，直接創(chuàng)建同名實(shí)例，然后停止但不刪除實(shí)例，復(fù)制冷備份文件到默認(rèn)目錄，啟動(dòng)實(shí)例，出現(xiàn)了上一輪熟悉的報(bào)錯(cuò)代碼ORA-01157和ORA-01110，立即對(duì)所有復(fù)制進(jìn)來(lái)的dbf和redo文件路徑進(jìn)行修改，隨后停止和重新啟動(dòng)一次實(shí)例，本以為會(huì)再?gòu)棾鲂碌膱?bào)錯(cuò)提示，卻是不期而至的正常加載數(shù)據(jù)庫(kù)和實(shí)例，冷備份的恢復(fù)真的成功了么？最好的檢驗(yàn)就是導(dǎo)出數(shù)據(jù)。

緊張地盯著屏幕上快速滾動(dòng)的信息直到導(dǎo)出結(jié)束，過(guò)程中沒(méi)有出現(xiàn)一個(gè)報(bào)錯(cuò)或警告，終于可以長(zhǎng)舒一口氣，至此確認(rèn)冷備份的數(shù)據(jù)恢復(fù)完美的達(dá)到了預(yù)期目標(biāo)。

經(jīng)驗(yàn)總結(jié)

重新梳理一次整個(gè)恢復(fù)的過(guò)程，可以簡(jiǎn)要地整理為如下步驟。

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

2.搭建與原有一致的環(huán)境，至少要保持Oracle數(shù)據(jù)庫(kù)系統(tǒng)的版本號(hào)一致，有效降低恢復(fù)的難度。

3.創(chuàng)建同名實(shí)例，創(chuàng)建監(jiān)聽(tīng)，停止但不刪除實(shí)例，覆蓋待恢復(fù)的dbf文件到現(xiàn)有實(shí)例的文件目錄。

4.執(zhí)行啟動(dòng)實(shí)例命令，根據(jù)報(bào)錯(cuò)代碼進(jìn)行處置，直到正常啟動(dòng)實(shí)例。

數(shù)據(jù)庫(kù)恢復(fù)是每一個(gè)DBA的必修課，場(chǎng)景、誘因、日常運(yùn)維習(xí)慣、部署環(huán)境的細(xì)微差異等都會(huì)影響恢復(fù)可采用的技術(shù)和思路。本例所采用的恢復(fù)方法并不一定符合最佳實(shí)踐的標(biāo)準(zhǔn)，遇到的報(bào)錯(cuò)代碼有的屬于常見(jiàn)報(bào)錯(cuò)，很容易被網(wǎng)上的修復(fù)方法所誤導(dǎo)，但整個(gè)操作過(guò)程堅(jiān)持了既定目標(biāo)并不斷調(diào)整操作策略，也不失一次成功的實(shí)踐。