SQL Server 數(shù)據(jù)文件 MDF 修復(fù)
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
![]() 對(duì)于CS模式的軟件系統(tǒng),數(shù)據(jù)庫(kù)文件損壞是常有的事。之所以損壞,我見過最多的場(chǎng)景無非是兩種:一是磁盤老化,很多系統(tǒng)使用了較長(zhǎng)時(shí)間,磁盤還是win7上市前一直使用到現(xiàn)在的;二是斷電,有用戶一下班就將排插斷電或關(guān)電源總閘,無非是為了方便和省電。 不管是什么系統(tǒng),只要使用數(shù)據(jù)庫(kù),我們一定要非常迫切需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份。CS軟件系統(tǒng),用戶是不會(huì)主動(dòng)去備份的,因?yàn)樗麄円膊涣私鈹?shù)據(jù)庫(kù),對(duì)數(shù)據(jù)安全也不敏感。也許有較負(fù)責(zé)任的商家,會(huì)幫助客戶做好定時(shí)備份任務(wù)。但發(fā)生損壞了,也需要人員進(jìn)行修復(fù)。 接下來我們用一個(gè)實(shí)際案例進(jìn)行數(shù)據(jù)庫(kù)的修復(fù)。某用戶附加數(shù)據(jù)庫(kù)的 mdf 和 ldf 文件,發(fā)生報(bào)錯(cuò)無法附加,給到我們進(jìn)行數(shù)據(jù)庫(kù)修復(fù)。一般遇到這種情況,我們也會(huì)懷疑客戶是不是直接拷貝 mdf 和 ldf 進(jìn)行數(shù)據(jù)庫(kù)備份的。 我們可以用SSMS進(jìn)行數(shù)據(jù)庫(kù)附加
消息 1813,級(jí)別 16,狀態(tài) 2,第 3 行 無法打開新數(shù)據(jù)庫(kù) 'SampleDB'。CREATE DATABASE 中止。 消息 824,級(jí)別 24,狀態(tài) 2,第 3 行SQL Server 檢測(cè)到基于一致性的邏輯 I/O 錯(cuò)誤 頁(yè)撕裂(簽名應(yīng)該為: 0xaaaaaaaa,但實(shí)際為: 0x5555aaaa)。在文件 'E:\Backup\AAA\mssql\DATA\SampleDB_Data.mdf' 中、偏移量為 0x0000000a37c000 的位置對(duì)數(shù)據(jù)庫(kù) ID 5 中的頁(yè) (1:20926) 執(zhí)行 讀取 期間,發(fā)生了該錯(cuò)誤。SQL Server 錯(cuò)誤日志或系統(tǒng)事件日志中的其他消息可能提供了更詳細(xì)信息。這是一個(gè)威脅數(shù)據(jù)庫(kù)完整性的嚴(yán)重錯(cuò)誤條件,必須立即糾正。請(qǐng)執(zhí)行完整的數(shù)據(jù)庫(kù)一致性檢查(DBCC CHECKDB)。此錯(cuò)誤可以由許多因素導(dǎo)致;有關(guān)詳細(xì)信息,請(qǐng)參閱 SQL Server 聯(lián)機(jī)叢書。 消息 3313,級(jí)別 21,狀態(tài) 2,第 3 行 在重做數(shù)據(jù)庫(kù) 'SampleDB' 的日志中記錄的操作時(shí),日志記錄 ID (9071:366:30) 出錯(cuò)。通常,特定故障以前會(huì)在 Windows 事件日志服務(wù)中記錄為錯(cuò)誤。請(qǐng)利用完整備份還原數(shù)據(jù)庫(kù),或者修復(fù)該數(shù)據(jù)庫(kù)。 在預(yù)期內(nèi),果然報(bào)錯(cuò)。我們要恢復(fù)數(shù)據(jù)庫(kù),必須先把數(shù)據(jù)文件掛到數(shù)據(jù)庫(kù)實(shí)例中,我們可以另辟蹊徑來達(dá)到我們的目的。
當(dāng)然,也有些第三方工具可以直接讀取 mdf 或 ldf 文件進(jìn)行數(shù)據(jù)提取修復(fù),這里我們就不考慮了。現(xiàn)在我們先看看 mdf 與 ldf 的文件信息。
![]() 這些信息可以看到數(shù)據(jù)庫(kù)名稱、數(shù)據(jù)庫(kù)版本、邏輯文件名、原物理文件路徑等。我們盡量創(chuàng)建與原路徑同名的數(shù)據(jù)庫(kù),可以用 Powershell 直接創(chuàng)建一個(gè)完整的路徑名稱
? 接下來我們根據(jù)以上信息,創(chuàng)建一個(gè)新的同名數(shù)據(jù)庫(kù)。
創(chuàng)建完成后,我們將該數(shù)據(jù)庫(kù)離線(脫機(jī))
離線后,數(shù)據(jù)文件 mdf 和日志文件 ldf 就可以直接刪除了,然后用我們有問題的 mdf 和 ldf 進(jìn)行替換,有時(shí)候需要注意 SQL Server 服務(wù)賬號(hào)是否有權(quán)限訪問該文件。 替換完成后,我們?cè)O(shè)置數(shù)據(jù)庫(kù)在線。
此時(shí)會(huì)提示出現(xiàn)錯(cuò)誤如下,數(shù)據(jù)庫(kù)也處于“可疑”狀態(tài)。 消息926,級(jí)別14,狀態(tài)1,第43行無法打開數(shù)據(jù)庫(kù)'SampleDB'。恢復(fù)操作已將該數(shù)據(jù)庫(kù)標(biāo)記為SUSPECT。有關(guān)詳細(xì)信息,請(qǐng)參閱SQL Server錯(cuò)誤日志。 消息5069,級(jí)別16,狀態(tài)1,第43行ALTER DATABASE語(yǔ)句失敗。 消息9003,級(jí)別20,狀態(tài)15,第43行傳遞給數(shù)據(jù)庫(kù)'SampleDB'中的日志掃描操作的日志掃描號(hào)(1419:83:1)無效。此錯(cuò)誤可能指示數(shù)據(jù)損壞,或者日志文件(.ldf)與數(shù)據(jù)文件(.mdf)不匹配。如果此錯(cuò)誤是在復(fù)制期間出現(xiàn)的,請(qǐng)重新創(chuàng)建發(fā)布。否則,如果該問題導(dǎo)致啟動(dòng)期間出錯(cuò),請(qǐng)從備份還原。 消息3414,級(jí)別21,狀態(tài)1,第43行恢復(fù)期間出錯(cuò),導(dǎo)致數(shù)據(jù)庫(kù)'SampleDB' (數(shù)據(jù)庫(kù)ID 5)無法重新啟動(dòng)。請(qǐng)?jiān)\斷并糾正這些恢復(fù)錯(cuò)誤,或者從已知的正確備份中還原。如果無法更正錯(cuò)誤,或者為意外錯(cuò)誤,請(qǐng)與技術(shù)支持人員聯(lián)系。 接下來我們可以直接用常用的命令來進(jìn)行數(shù)據(jù)庫(kù)修復(fù)。
通過 REPAIR_ALLOW_DATA_LOSS 修復(fù)數(shù)據(jù),相關(guān)修復(fù)信息如下。其中大部分是系統(tǒng)元數(shù)據(jù)有問題,還有一些用戶表的索引有問題。修復(fù)后新的頁(yè)面關(guān)系可能導(dǎo)致一些異常頁(yè)面數(shù)據(jù)丟失。 如果企業(yè)丟失了數(shù)據(jù),哪怕僅僅幾行數(shù)據(jù),對(duì)企業(yè)和客戶來說都是非常嚴(yán)重的問題。如果發(fā)現(xiàn)數(shù)據(jù)庫(kù)損壞,應(yīng)盡快修復(fù),在修復(fù)完成前不建議繼續(xù)使用該數(shù)據(jù)庫(kù)。若某個(gè)頁(yè)面損壞,我們還可以通過備份恢復(fù)某個(gè)頁(yè)面的數(shù)據(jù)。如果損壞過多,即使有損修復(fù)數(shù)據(jù),數(shù)據(jù)的完整性也沒有保障,數(shù)據(jù)之間的關(guān)系可能已經(jīng)不存在了,損失也相當(dāng)于進(jìn)一步在擴(kuò)大。 因此,企業(yè)或用戶系統(tǒng)的數(shù)據(jù)庫(kù),一定要做好備份。不僅要完整的全量備份,還需要日志增量備份。相互結(jié)合起來,可以保證任意時(shí)刻的數(shù)據(jù)都能被找回。這一定是數(shù)據(jù)管理者深入骨髓的理念! 閱讀原文:原文鏈接 該文章在 2025/1/10 11:11:58 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |