SQL Server資料庫啟動過程及使用者資料庫載入過程的疑難雜症

SQL Server資料庫啟動過程及使用者資料庫載入過程的疑難雜症

前言

本篇主要是上一篇文章的補充篇，上一篇我們介紹了SQL Server服務啟動過程所遇到的一些問題和解決方案，可點擊查看，我們此篇主要介紹的是SQL Server啟動過程中關於使用者資料庫載入的流程，並且根據載入過程中所遇到的一系列問題提供解決方案。

其實SQL Server作為微軟的一款優秀RDBMS，它啟動的過程中，本身所帶的那些系統庫發生問題的情況相對還是很少的，我們在平常使用中，出問題的大部分集中於我們自己建立的使用者資料庫。

而且，相對於側重面而言，其實我們更關注的是我們自己建立的使用者資料庫，假如系統資料庫出現問題，甚至執行個體出現問題，最壞的情況我們重搭環境，但是如果我們應用的使用者資料庫壞掉了，那可不是重搭環境就能解決的。這牽扯到公司利益問題，問題嚴重性不言而喻！

閑言少敘，我們速度進入本篇的正題。

 

上一篇我們介紹了SQL Server執行個體啟動的過程，並且分析了其詳細的過程，而在這一流程中，有一個步驟非常關鍵，就是載入恢複使用者資料庫的過程，我們來截取這段日誌資訊：

 

上面是一個正常啟動各個使用者庫的流程，SQL Server會採用多線程的進行資料庫啟動，並且在這個過程中進行一致性校正，確保啟動的資料庫能夠正常使用。

而這過程中會發生很多問題，在分析問題之前，我先要介紹SQL Server資料庫的幾個常見狀態：

 RECOVERING（恢複中）：

這個狀態表示資料在啟動完成後，正在發生恢複，也就是上面日誌中的 Recovery過程，和其它的關係型資料庫一樣，SQL Server對所有的資料庫行為都是先寫交易記錄，然後在修改記憶體中的資料，然後通過背景一個進程在適當的時候進行寫入硬碟（Lazy write），所以在資料庫運行過程中，磁碟中的資料並不是最新的，如果這個時候關閉了，在下一次啟動過程中SQL Server就要根據交易記錄中的記錄，將磁碟中的舊的資料改寫，改寫過程為：

1、重做redo

2、復原和撤銷 undo/rollback

上面的目的就是為了保證資料庫一致性。

如果上面的流程發生了問題，就會進去到下面這個狀態：

RECOVERY PENDING（掛起還原）：

這個過程就是將恢複資料的過程掛起，掛起的原因基本就是不能正常開啟所用的資料庫檔案。這裡先記住這個狀態就行，我在後面的內容會再現這個問題，以及給出解決方案。

如果能找到檔案或者能開啟檔案，但是檔案有問題，機會出現下面這個狀態：

SUSPECT（質疑）：

這個狀態，我相信很多使用者如果在玩資料庫久了的時候，會偶爾遇到，相對於其它狀態，這個狀態是出現最高的。

原因很簡單：資料庫檔案壞掉了。

當經曆了上面的這個幾個狀態都不出現問題，上面的這幾個狀態下，資料庫都是不能使用的，會進入到下面這個狀態：

ONLINE（線上）：

這個狀態應該是最期待的了，資料庫線上，正常使用，預設都是正常的線上狀態。

 

當然，除了上面幾個資料庫自己形成的資料庫狀態，在我們管理員處理資料庫的時候也會更改狀態，這裡我們順便提一下：

OFFLINE(離線)：有線上狀態就有離線狀態，很簡單，讓資料庫離線，使用者不能使用

RESTORING（還原中）：這個狀態很簡單，管理員正在還原該資料庫，不解釋

EMERGENCY（緊急）：這個狀態也是管理員用的，就是說明資料庫有問題了，它正在盡量解決

 

以上幾個狀態中，發生在啟動過程中，並且會發生問題就是上面的RECOVERY PENDING（掛起還原）、SUSPECT（質疑）、RECOVERING（恢複中）：

我們依次來看：

RECOVERY PENDING（掛起還原）：

出現這個狀態通常的原因是資料庫檔案找不到，或者檔案找到許可權訪問不到，我們來看該問題報錯資訊：

在資料庫中儲存方式中，分為主檔案組和輔助檔案組和記錄檔，為了展示方便我們特意建立了個測試庫，來重現該部分問題：

 

 

<1>主檔案組問題

當不能訪問主檔案組檔案的時候，也就是上面的CnblogsTestDB.mdf檔案，會報如下錯誤：

我們先來看資料庫：

在執行個體啟動的過程，恰巧有一個庫顯示了上面我們提到的一個狀態：RECOVERING（恢複中），我順便把圖給了，當然出現這個情況很正常，有時候重新整理一下就正常，其它使用者庫沒有顯示是因為庫太小，恢復太短，我們捕捉不到。

我們來看，上面我們建立的測試庫CnblogsTestDB已經不能訪問了，我們來看一下Error中的錯誤資訊：

錯誤資訊很明顯，說這個該檔案不能訪問，並且確切的說出了這個為作業系統錯誤，那我們看作業系統的錯誤記錄：

可以看到在Windows系統日誌中也能看到該部分錯誤資訊。

解決方案：

此問題的解決方案還是很簡單的，一般主要是因為許可權問題，只需要將資料庫管理員賬戶組，提權到可讀寫權限就可以，然後重啟服務:

 

上面的情況是找到資料庫檔案，但是不能開啟資料庫檔案，當然還有可能是直接找不到資料庫檔案，系統會報出如下錯誤：

會給出17204錯誤，報找不到檔案錯誤

解決方案：

a、如果能找到資料檔案最好了，拷貝到錯誤制定的路徑下既可以，然後重啟執行個體

b、不能找到檔案了，那就得只能刪除該庫，重新建立同名庫，從備份檔案中還原

一般上述問題發生在實體儲存體出現了故障，當然不排除某些軟體操作，比如殺毒軟體、還有人為誤刪等原因。如果沒有備份，這可能是一個很大的遭難，基本可以確定的完全還原的可能性不高！所以記住：備份資料庫的重要性！

 

<2>輔助檔案組問題

上面的出現問題的檔案為資料庫的主檔案組，當我們資料庫在承載到一定資料量的情況下，我麼採取多個輔助檔案組來容納資料，下面我們來看一下輔助檔案組的問題：

同樣的提示的輔助檔案組不能正常開啟，或者找不到相關的輔助檔案組，遇到這樣的問題我們怎麼解決呢?

其實SQL Server資料庫輔助檔案儲存體的主要為資料庫的資料內容資訊，關於本庫的一些架構資訊是放在主（primary）檔案組中，所以我們可以先這樣

解決方案：

a、我們將打不開或者不能訪問的資料庫檔案（輔助檔案）設定成離線，然後先將能夠正常的資料檔案上線，確保除了損壞的那部分檔案的其它庫資訊能正常訪問，我們通過以下代碼更改：

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

這樣，我們重新整理下資料庫，既可以正常訪問正確的資料資訊：

當我們處於生產環境中，生產庫不能正常啟動的時候，此刻的火燒眉毛的時刻，採取上面的方法先確保一部分資料能正常訪問也不失為一種緩議之計。

下面的步驟就是找到該輔助檔案，並且確保有正常的許可權訪問，更重要的是找到的輔助檔案不能是損壞的，然後拷貝至錯誤檔案中給出的路徑，然後重啟執行個體，上線該庫。

b、當然大部分情況下，我們找不到該檔案，或者這個檔案已經損壞，那就得採取第二種方案，通過備份還原，根據以往的經驗，建議採取的措施是：

先將能訪問的資料庫做一次備份，然後通過檔案組恢複的方式，恢複上面出問題的檔案組。

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 3 下一��