怎樣恢復(fù)SQL SERVER 數(shù)據(jù)庫文件

這篇文章將為大家詳細(xì)講解有關(guān)怎樣恢復(fù)SQL SERVER 數(shù)據(jù)庫文件，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

首先意淫這篇文字，任務(wù)是要說SQL SERVER 數(shù)據(jù)庫要被消滅等等的就可以到此為止了。下面主要說的這兩天，恢復(fù)SQL SERVER 數(shù)據(jù)庫文件，拯救系統(tǒng)的始末.

前天下午，接到運(yùn)維同學(xué)的電話，（估計(jì)之前已經(jīng)有人報(bào)警說系統(tǒng)無法運(yùn)行了），他告訴我我們的SQL SERVER  集群的主庫正在被還原，問我有什么解決方法嗎？

WHAT  HOW ，是我腦子里閃出的東西，當(dāng)然還有別的，STOP

冷靜，我腦子里面里面開始運(yùn)轉(zhuǎn)，從腦子里面的數(shù)據(jù)庫搜索各種方案和使用這樣方案會造成的影響。

首先我確認(rèn)的是

1 業(yè)務(wù)終止了

2 是否能終止整體數(shù)據(jù)庫還原

3 終止后怎么讓業(yè)務(wù)數(shù)據(jù)庫上線

4 我能保證數(shù)據(jù)的一致性嗎

5 我需要多長時間

6 情況還能多糟糕

可能說道這里，有觀眾已經(jīng)想問，怎么會？  OMG ，好好的怎么會數(shù)據(jù)庫還原。

我倒是想奉勸，怎么就不可能，這世界上什么事情不會發(fā)生，沒有什么好奇怪的，發(fā)生了，也別問怎么樣，誰干的，諸如此類無聊的問題。他發(fā)生了，現(xiàn)在給我打電話就是要SAVE IT， 其他的我不關(guān)心。

問完我自己那些問題，腦子的數(shù)據(jù)庫首先的第一條反映就是，不能讓他繼續(xù)還原，如果繼續(xù)的話，我半點(diǎn)拯救數(shù)據(jù)庫的機(jī)會都沒有，OK 我們的SQL SERVER 是ALWAYS ON ，OMG ，三臺機(jī)器，

有人問，HI 關(guān)機(jī)不就完啦，反正業(yè)務(wù)已經(jīng)停止了，SHUT UP，那個數(shù)據(jù)庫上還跑著其他的數(shù)據(jù)庫，不光正在還原的這一個數(shù)據(jù)庫，已經(jīng)停止了關(guān)鍵業(yè)務(wù)，難道關(guān)了數(shù)據(jù)庫服務(wù)器，讓整個公司都沸騰嗎？

1 decision ，不能關(guān)機(jī)，必須正常輸出其他的服務(wù)，影響不能擴(kuò)大化

又會有人說，你不關(guān)機(jī)，就讓他繼續(xù)還原數(shù)據(jù)庫，NO NO NO ，幸虧我們的公司有ALWAYS ON （那些還讓SQL SERVER （尤其主營業(yè)務(wù)）還不適用 ALWAYS ON 的 當(dāng)然還有使用集群方式的（類似 ORACLE RAC））就等著哭吧， 

2  我立即告訴運(yùn)維人員，我要關(guān)閉一臺SQL SERVER 從庫，這里解釋一下為什么再次提到 ORACLE  RAC 和 SQL SERVER 類似的功能 SQL SERVER CLUSTER。  使用這樣的方案，必須在發(fā)生這樣問題的情形下，必死無疑，必死無疑，必死無疑，重要的事情說三遍。分布式數(shù)據(jù)庫的優(yōu)點(diǎn)，關(guān)閉一臺機(jī)器，不影響業(yè)務(wù)，數(shù)據(jù)服務(wù)的繼續(xù)輸出。

關(guān)閉后，我在想，我不怕了，至少我留下了一臺數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)，雖然分布式數(shù)據(jù)庫上的數(shù)據(jù)也已經(jīng)在還原的狀態(tài)，但我保住了原始的數(shù)據(jù)，不再被損壞，我還有生還的機(jī)會。

我還應(yīng)該在做點(diǎn)什么，下一步怎么辦，停止那的備份軟件的誤操作，得到第三方的軟件供應(yīng)商的答復(fù)是NO。

OMG ，這就是花了錢后得到的服務(wù)，我明白為什么互聯(lián)網(wǎng)公司什么都要自己開發(fā)，從不買什么備份軟件，監(jiān)控軟件，系統(tǒng)保護(hù)軟件之類的。因?yàn)槿绻枪緝?nèi)部自己開發(fā)的，那絕對不會說出冷冰冰的 NO 。 而是大家繼續(xù)想辦法拯救需要拯救的東西。（后來事實(shí)證明，只有公司內(nèi)部的團(tuán)隊(duì)是靠譜的，關(guān)鍵的東西其實(shí)還是自己研發(fā)比較好）

既然軟件上說NO ，那就是不能停止還原的操作，怎么辦，查看軟件的線程，一直在連接SQL SERVER 進(jìn)行數(shù)據(jù)還原，還是多線程的，停止時夠嗆了，因?yàn)樗袕?qiáng)大的重試功能，估計(jì)還是使用的SA 之類的高級賬號給他做連接數(shù)據(jù)庫的賬號，我已經(jīng)不奢望什么了。

好吧，我的關(guān)注點(diǎn)，回到我保留下的那個關(guān)閉的服務(wù)器，又接到電話，說那個關(guān)閉的服務(wù)器，還要在開機(jī)，因?yàn)橐獓L試解散集群，嘗試數(shù)據(jù)庫停止恢復(fù)B PLAN。 OMG 

在開機(jī)后，我再次決定停止SQL SERVER 的服務(wù)，不讓馬上連接的節(jié)點(diǎn)，被繼續(xù)破壞，我開始拷貝節(jié)點(diǎn)的數(shù)據(jù)庫的文件，（這里又有故事，缺少這個故事，估計(jì)也搞不定，BULABULA）。 拷貝完我的數(shù)據(jù)庫文件到一個安全的地方，我打開了SQL SERVER 的服務(wù)，如同電影 奇幻PI旅行中最后老虎消失的一幕，我知道，這臺機(jī)器的數(shù)據(jù)庫也完蛋了。

不過我已經(jīng)拷貝了數(shù)據(jù)庫，下面面對我有時連續(xù)的奇葩問題

1  我光有數(shù)據(jù)文件，沒有能讓我使用的恢復(fù)數(shù)據(jù)庫的服務(wù)器

2  這些文件已經(jīng)部分還原，我拿到這些能還原多少文件

3  怎么恢復(fù)這些數(shù)據(jù)文件

以前學(xué)習(xí)過的 SQL SERVER PAGE 頁的知識，浮現(xiàn)在腦子里面

SQL Server中的在頁面頂部有一個96字節(jié)的頭，它包括PageID、頁面所屬的結(jié)構(gòu)類型、頁面中的記錄數(shù)量以及指向上一頁和下一頁的指針。所以有8096字節(jié)可用來存儲記錄。但是，數(shù)據(jù)記錄的最大長度是8060字節(jié)，正如頁面底部(最新的36字節(jié))所示，它駐留的slot數(shù)組包含關(guān)于行的偏移量的信息(每行2字節(jié))

馬上問題又在腦子里面翻轉(zhuǎn)

1 如果頁頭毀掉了，那就完蛋了

2 數(shù)據(jù)頁面如果不連續(xù)了，很可能會有數(shù)據(jù)的缺失和損壞

3 如果有跨頁的情況，那損壞也許更多

并且根據(jù)SQL SERVER 數(shù)據(jù)庫文件的頁面分配，9，0 1 2 3 首頁面如果被毀，那簡直就是死路一條。 

怎么辦，本來我想用以前用過的 APEXLOG ，來嘗試重新讀取文件，不過原理不對，那個軟件是讀取日志文件，來恢復(fù)數(shù)據(jù)的，而這次毀滅性的打擊，根據(jù) ALWAYS ON 的原理，很可能日志是最先被毀滅的文件。并且我如果想恢復(fù)，至少我的先讓這些數(shù)據(jù)文件再次掛在在數(shù)據(jù)庫服務(wù)器上，才能使用 APEXLOG ，不幸的是，這些條件都不具備。

嘗試掛載數(shù)據(jù)文件，報(bào)告，MASTER FILE  32:32 損壞，無法掛載數(shù)據(jù)庫。好吧我早就該想到這一點(diǎn)，被覆蓋，還強(qiáng)行關(guān)機(jī)，掛不上那是應(yīng)該的，掛上那是上帝顯靈了。

那也不能坐以待斃，我嘗試尋找其他方法，那不具備那些條件的情況下，我可以通過讀取數(shù)據(jù)文件的方式恢復(fù)數(shù)據(jù)，根據(jù)文件的物理特性，其實(shí)可以通過SQL SERVER DBCC的方式直接讀取數(shù)據(jù)頁，并且恢復(fù)數(shù)據(jù)，但前提是數(shù)據(jù)庫的聯(lián)機(jī)，現(xiàn)在這個問題是數(shù)據(jù)庫不能聯(lián)機(jī)，并且聯(lián)機(jī)的也是那個正在還原停不了的數(shù)據(jù)庫，并且也不能拿現(xiàn)在的數(shù)據(jù)庫冒險。 更糟糕的我想把數(shù)據(jù)拷貝到 UAT 或者 測試庫的想法 也都落空，倒霉催的網(wǎng)絡(luò)帶寬，倒霉催的網(wǎng)絡(luò)帶寬，倒霉催的網(wǎng)絡(luò)帶寬。 

SQL SERVER 本身能讀取數(shù)據(jù)PAGE，其實(shí)按原理上個來說，只要有讀取這個PAGE的軟件就可以，嘗試找找，還真有類似的軟件，那試試吧，裝上軟件，開始對我拷貝的數(shù)據(jù)文件，進(jìn)行SEARCH，上線，我看到久違的數(shù)據(jù)，好像初戀一樣的感覺。好吧后面就是，恢復(fù)數(shù)據(jù)，BULABULA。

此外，開發(fā)團(tuán)隊(duì)在得到 AUDIT LOG 后，想嘗試另一種恢復(fù)的方法，也可歌可泣，絕對應(yīng)該載入公司的史冊，并且我也從這次開發(fā)的努力中看到了不放棄，并且我們也得到一些在此類問題上的經(jīng)驗(yàn)，絕對是有益的。

總結(jié)：

1 首先感謝開發(fā)者軟件的公司，并且有破解這個軟件的人，再次感謝

2 如果讓我做數(shù)據(jù)庫部署的抉擇，1 不會使用ORACLE RAC 或類似的功能，因?yàn)樵綇?fù)雜的東西，遭遇不測恢復(fù)很難，如果是ORACLRE 估計(jì)也很難有公司能得到技術(shù)內(nèi)幕并開發(fā)此類軟件。換做是MYSQL 估計(jì)連第三方軟件都不用，很快就能將這樣的問題解決（前提的做些工作）

運(yùn)維的同學(xué)雖然不在一個部門，不過我想他們積極的找解決問題的出路的努力應(yīng)該被肯定.

身處這樣的公司，出了問題大家一起努力解決，而不是冷冰冰的指責(zé)（某些公司體會過，放心這樣的事情放在那些公司，我只有三個字  OMG ），雖然出了問題，但我們解決了，這很了不起。這也讓我想起到底是職責(zé)劃清好，還是大家“大鍋飯”好，都有優(yōu)點(diǎn)，和缺點(diǎn)，不過這次，徹底讓我感覺到 “大鍋飯”的好處。  記得4年前在某公司，也是這樣的問題，而處境，各個部門事不關(guān)己高高掛起的嘴臉，真讓我厭惡，并且還落井下石。

3 分布式數(shù)據(jù)庫，（是分布式不是數(shù)據(jù)分片，那將毫無幫助），對此類問題是有幫助。

4  冷靜，冷靜，冷靜，和信心

5 經(jīng)驗(yàn)值和一些發(fā)現(xiàn)的問題（就讓他們在我腦子里面吧）

關(guān)于怎樣恢復(fù)SQL SERVER 數(shù)據(jù)庫文件就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。