<1>主文件組問題

當(dāng)不能訪問主文件組文件的時(shí)候，也就是上面的CnblogsTestDB.mdf文件，會(huì)報(bào)如下錯(cuò)誤：

我們先來(lái)看數(shù)據(jù)庫(kù)：

在實(shí)例啟動(dòng)的過(guò)程，恰巧有一個(gè)庫(kù)顯示了上面我們提到的一個(gè)狀態(tài)：RECOVERING（恢復(fù)中），我順便把圖給截圖了，當(dāng)然出現(xiàn)這個(gè)情況很正常，有時(shí)候刷新一下就正常，其它用戶庫(kù)沒有顯示是因?yàn)閹?kù)太小，恢復(fù)時(shí)間太短，我們捕捉不到。

我們來(lái)看，上我們建立的測(cè)試庫(kù)CnblogsTestDB已經(jīng)不能訪問了，我們來(lái)看一下Error中的錯(cuò)誤信息：

錯(cuò)誤信息很明顯，說(shuō)這個(gè)該文件不能訪問，并且確切的說(shuō)出了這個(gè)為操作系統(tǒng)錯(cuò)誤，那我們看操作系統(tǒng)的錯(cuò)誤記錄：

可以看到在Windows系統(tǒng)日志中也能看到該部分錯(cuò)誤信息。

解決方案：

此問題的解決方法還是很簡(jiǎn)單的，一般主要是因?yàn)闄?quán)限問題，只需要將數(shù)據(jù)庫(kù)管理員賬戶組，提權(quán)到可讀寫權(quán)限就可以，然后重啟服務(wù):

上面的情況是找到數(shù)據(jù)庫(kù)文件，但是不能打開數(shù)據(jù)庫(kù)文件，當(dāng)然還有可能是直接找不到數(shù)據(jù)庫(kù)文件，系統(tǒng)會(huì)報(bào)出如下錯(cuò)誤：

會(huì)給出17204錯(cuò)誤，報(bào)找不到文件錯(cuò)誤

解決方案：

a、如果能找到數(shù)據(jù)文件最好了，拷貝到錯(cuò)誤制定的路徑下既可以，然后重啟實(shí)例

b、不能找到文件了，那就得只能刪除該庫(kù)，重新新建同名庫(kù)?從備份文件中還原

一般上述問題發(fā)生在物理存儲(chǔ)出現(xiàn)了故障，當(dāng)然不排除某些軟件操作，比如殺毒軟件、還有人為誤刪等原因。如果沒有備份，這可能是一個(gè)很大的遭難，基本可以確定的完全還原的可能性不高！所以記?。?span style="margin: 0px; padding: 0px; color: rgb(255, 0, 0);">備份數(shù)據(jù)庫(kù)的重要性！

<2>輔助文件組問題

上面的出現(xiàn)問題的文件為數(shù)據(jù)庫(kù)的主文件組，當(dāng)我們數(shù)據(jù)庫(kù)在承載到一定數(shù)據(jù)量的情況下，我么采取多個(gè)輔助文件組來(lái)容納數(shù)據(jù)，下面我們來(lái)看一下輔助文件組的問題：

同樣的提示的輔助文件組不能正常打開，或者找不到相關(guān)的輔助文件組，遇到這樣的問題我們?cè)趺唇鉀Q呢?

其實(shí)SQL Server數(shù)據(jù)庫(kù)輔助文件存儲(chǔ)的主要為數(shù)據(jù)庫(kù)的數(shù)據(jù)內(nèi)容信息，關(guān)于本庫(kù)的一些架構(gòu)信息是放在主（primary）文件組中，所以我們可以先這樣

解決方案：

a、我們將打不開或者不能訪問的數(shù)據(jù)庫(kù)文件（輔助文件）設(shè)置成離線，然后先將能夠正常的數(shù)據(jù)文件上線，確保除了損壞的那部分文件的其它庫(kù)信息能正常訪問，我們通過(guò)以下代碼更改：

ALTER DATABASE CnblogsTestDB MODIFY FILE(NAME=CnblogsTestDB2,OFFLINE)
GO
ALTER DATABASE CnblogsTestDB set ONLINE
GO

這樣，我們刷新下數(shù)據(jù)庫(kù)，既可以正常訪問正確的數(shù)據(jù)信息：

當(dāng)我們處于生產(chǎn)環(huán)境中，生產(chǎn)庫(kù)不能正常啟動(dòng)的時(shí)候，此刻的火燒眉毛的時(shí)刻，采取上面的方法先確保一部分?jǐn)?shù)據(jù)能正常訪問也不失為一種緩議之計(jì)。

下面的步驟就是找到該輔助文件，并且確保有正常的權(quán)限訪問，更重要的是找到的輔助文件不能是損壞的，然后拷貝至錯(cuò)誤文件中給出的路徑，然后重啟實(shí)例，上線該庫(kù)。

b、當(dāng)然大部分情況下，我們找不到該文件，或者這個(gè)文件已經(jīng)損壞，那就得采取第二種方案，通過(guò)備份還原，根據(jù)以往的經(jīng)驗(yàn)，建議采取的措施是：

先將能訪問的數(shù)據(jù)庫(kù)做一次備份，然后通過(guò)文件組恢復(fù)的方式，恢復(fù)上面出問題的文件組。

<3>日志文件組

其實(shí)從市面上的所有數(shù)據(jù)庫(kù)而言，其本身所有的機(jī)制都是通過(guò)先寫日志，然后通過(guò)一個(gè)進(jìn)程后寫入（lazy write）方式寫入到磁盤，這種方式是為了避免IO的阻塞，因?yàn)槲覀兌贾来疟PIO這個(gè)問題一直是所有文件讀寫的最大瓶頸。

所以，日志文件是數(shù)據(jù)庫(kù)不可分割的一部分。當(dāng)數(shù)據(jù)庫(kù)在啟動(dòng)的過(guò)程，會(huì)通過(guò)日志中的記錄做一次數(shù)據(jù)的一致性校驗(yàn)，文章的開端有介紹。

所以說(shuō)，如果日志文件不能訪問，或者說(shuō)出問題，那我們的SQL Server數(shù)據(jù)庫(kù)出現(xiàn)什么問題呢？

我們先來(lái)看數(shù)據(jù)庫(kù)模式為簡(jiǎn)單（SIMPLE）模式的，我將咱們的測(cè)試庫(kù)設(shè)置成簡(jiǎn)單模式：

USE CnblogsTestDB
GO
ALTER DATABASE [CnblogsTestDB] SET RECOVERY SIMPLE WITH NO_WAIT
GO

然后我們停掉實(shí)例，然后刪除掉該庫(kù)的日志文件，然后重新啟動(dòng)

可以看到處于簡(jiǎn)單模式下，如果日志文件出現(xiàn)錯(cuò)誤，在啟動(dòng)的過(guò)程是不會(huì)發(fā)生任何問題的，這里的原因我們?cè)趩?dòng)Error日志文件中能找到答案：

經(jīng)過(guò)上面的日志分析，我們可以看到，當(dāng)數(shù)據(jù)庫(kù)處于簡(jiǎn)單模式下，數(shù)據(jù)庫(kù)在啟動(dòng)的過(guò)程中，如果發(fā)現(xiàn)任何與日志相關(guān)的信息，則會(huì)重新創(chuàng)建一份日志文件，保證數(shù)據(jù)庫(kù)的正常訪問。

如果這樣那我們數(shù)據(jù)庫(kù)的完整性怎么保證呢，是這樣，如果數(shù)據(jù)庫(kù)處于簡(jiǎn)單模式，在我們數(shù)據(jù)庫(kù)關(guān)閉的時(shí)候，系統(tǒng)會(huì)先將該提交的所有事務(wù)都寫入到磁盤中去，所有該回滾的就撤銷。

上面能正常創(chuàng)建數(shù)據(jù)庫(kù)日志文件的前提條件有兩條：1、數(shù)據(jù)庫(kù)為簡(jiǎn)單模式；2、數(shù)據(jù)庫(kù)正常關(guān)閉，保證事務(wù)都已正常寫入磁盤

下面我們?cè)诳?如果恢復(fù)模式為“完整”模式下的，數(shù)據(jù)庫(kù)上次沒有正常的情況，SQL Server數(shù)據(jù)庫(kù)是如何處理的，

我們先將數(shù)據(jù)庫(kù)改成完整恢復(fù)模式，停掉實(shí)例，然后刪除日志，然后啟動(dòng)

然后我們啟動(dòng)，可以看到這個(gè)時(shí)候，數(shù)據(jù)庫(kù)不能正常訪問的，該錯(cuò)誤的Error的日志信息為：

windows平臺(tái)下也為我們記錄了該錯(cuò)誤的日志信息：

其實(shí)出現(xiàn)上面的錯(cuò)誤，很正常，因?yàn)橛行?shù)據(jù)庫(kù)的事務(wù)性操作已經(jīng)記錄到事務(wù)日志中，還未寫入磁盤數(shù)據(jù)頁(yè)中，這時(shí)候發(fā)生了宕機(jī)，或者非正常關(guān)閉，這個(gè)對(duì)SQL Server數(shù)據(jù)庫(kù)是能應(yīng)付的，但是，而在啟動(dòng)的過(guò)程找不到相關(guān)的事務(wù)日志盡心回滾和寫入操作，所以該庫(kù)的數(shù)據(jù)時(shí)非一致性的，所以SQL Server是不讓我們使用該庫(kù)，出現(xiàn)此種錯(cuò)誤，我們的解決方式有如下幾種：

解決方案：

a、如果有備份，最好最快的方式就是恢復(fù)數(shù)據(jù)庫(kù)備份或者找到了該日志文件拷貝到錯(cuò)誤路徑下（推薦）

b、如果沒有備份，我們只能通過(guò)使用CHECKDB命令修復(fù)數(shù)據(jù)庫(kù)（不推薦）

上述解決方案中CHECKDB命令，是一種萬(wàn)不得已的方式?而且，我可以明確的告訴你這命令使用的時(shí)候會(huì)可能造成數(shù)據(jù)丟失，并且在大數(shù)據(jù)庫(kù)中，運(yùn)行周期很長(zhǎng)！

當(dāng)然在萬(wàn)不得已的情況下，我們還的采取，過(guò)程如下：

我們先將數(shù)據(jù)庫(kù)設(shè)置成EMERGENCY（緊急）模式，并且為單用戶（SINGLE_USER）模式

USE CnblogsTestDB
GO
ALTER DATABASE CnblogsTestDB SET EMERGENCY
GO
ALTER DATABASE CnblogsTestDB SET SINGLE_USER
GO

經(jīng)過(guò)我們上面的設(shè)置，將庫(kù)設(shè)置成了“緊急”模式，并且只為單用戶方式訪問，便于我們進(jìn)行數(shù)據(jù)?復(fù)

然后我們執(zhí)行CHECKDB命令，進(jìn)行數(shù)據(jù)庫(kù)的修復(fù)

DBCC CHECKDB(CnblogsTestDB,REPAIR_ALLOW_DATA_LOSS)
GO

經(jīng)過(guò)該命令的修復(fù)，數(shù)據(jù)庫(kù)會(huì)為系統(tǒng)新建一個(gè)日志，但是不能保證事務(wù)的一致性，也就是說(shuō)會(huì)因此而丟失數(shù)據(jù)，所以非常不推薦的一種方式！

并且，在這過(guò)程中，如果是大數(shù)據(jù)庫(kù)的話，該修復(fù)過(guò)程會(huì)很漫長(zhǎng)，當(dāng)然我不能給出一個(gè)漫長(zhǎng)參考值，因?yàn)檫@過(guò)程還有會(huì)出現(xiàn)其它的錯(cuò)誤需要修復(fù)。

所以酌情考量。

當(dāng)然，在恢復(fù)完成之后，不要忘記將數(shù)據(jù)庫(kù)改回多用戶模式

USE [master]
GO
ALTER DATABASE [CnblogsTestDB] SET  MULTI_USER WITH ROLLBACK IMMEDIATE
GO

至此，這個(gè)有問題的庫(kù)就能夠正常訪問了。