此篇主要介紹的是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（掛起還原）：

出現這個狀態通常的原因是數據庫文件找不到，或者文件找到權限訪問不到，我們來看該問題報?信息：

在數據庫中存儲方式中，分為主文件組和輔助文件組和日志文件，為了展示方便我們特意建立了個測試庫，來重現該部分問題：