目前SQL Server數據庫作為微軟一款優秀的RDBMS，其本身啟動的時候是很少出問題的，我們在平時用的時候，很少關注起啟動過程，或者很少了解其底層運行過程，大部分的過程只關注其內部的表、存儲過程、視圖、函數等一系列應用方式，而當有一天它運行的正常的時候突然啟動不起來了，這時候就束手無策了，能做的或許只能是重裝、配置、還原等，但這一個過程其實是一個非常耗時的過程，尤其當我們面對是龐大的生產庫的時候，可能在這火燒眉毛的時刻，是不允許你再重搭建一套環境的。

所以作為一個合格的數據庫使用者，我們要了解其啟動、運行過程的事情，一旦發生問題，我們也?及時定位，迅速解決。

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

SQL Server本身就是一個Windows服務，每一個實例對應的就是一個sqlserver.exe進程。這是一個可執行的文件，默認就放在SQL Server的安裝目錄下，當我們啟動的時候，就是直接調用這個文件，然后啟動這個服務。 

第一部分、SQL Server實例啟動的方法和啟動所發生的問題

  SQL Server實例分為下面幾種啟動方法：

（1）在Windows服務控制臺里手動啟動，或者自動啟動（默認），這個也是最常用的方式

（2）第二種方式是SQL Server本身自己提供的啟動方式，我們這里可以手動啟動

（3）在SQL Server的SSMS里面手動啟動它，這個方式一般大部分利用這種方式進行手動重啟

（4）通過Windows命令窗口，用'net start'命令手動啟動，這種方法也可以用

以上這幾種方式都可以啟動SQL Sever,并且都會在SQL 日志信息中有所記錄。

第二部分、SQL Server實例啟動的詳細過程以及所發生的問題項

第一步、檢查注冊表項

當一個sqlserver.exe文件開始啟動的時候，首先要干的第一件事就是先檢查它的配置信息存放于注冊表的值項

比較重要的幾個鍵值有下面幾個：

這里的

AuditLevel:其實就是SQL 如何記錄用戶登錄記錄；

LoginMode:是SQL Server服務器身份驗證方式等；

BackupDirectory:默認的備份路徑等信息；

關于注冊表信息簡要了解即可，不建議做任何修改，當然這些值的信息默認在SQL Server中都能設置：

在不修改注冊表的情況下，一般這一步的啟動順序一般不會出現問題，當然出現問題了也通常沒有辦法解決，大?分的解決方式只有重裝了。

但這一步驟，通常出現以下兩個個問題通常是可以解決的：

<1>啟動賬號權限問題

如果我們啟動SQL Server的進程使用的賬號連讀注冊表的權限都沒有，那這個服務是怎么也啟動不了的，通常這時候連SQL 的錯誤日志都沒有能力生成出來。

這時候我們該如何發現呢，雖然這時候它沒有能力創建SQL 的錯誤日志，但是它在Windows層面留下了痕跡，我們來看：

我將服務啟動賬號設置成gust來賓賬號，來啟動該服務

這時候會產生以下錯誤信息：

在Windows的日志信息里也會產生一條錯誤日志記錄：

這里的拒絕訪問指的就是拒絕訪問注冊表信息了。

解決方法：

此問題的解決方式就很簡單了，只需要將當然的用戶提權到SQL Server服務的啟動賬號就行了，提權的方式也很簡單，只需要添加到SQL的本地用戶的啟動服務組就可以了。

當然，也可以直接換一個更高級別的用戶登錄。一般默認都用的超級管理員賬戶。

<2>訪問日志和文件夾出現問題

默認在SQL Server啟動的時候會創建一個啟動日志文件，記錄所有正確的日志信息，當然也?括錯誤的日志信息，如果這時候找不到這個日志信息的路徑，或者已經存在一個日志，但是日志被鎖定了（某些NB的殺毒軟件擅長干這個），這時候這個服務也是啟動不了的，同樣也創建不出SQL Server的日志文件，這時候我們還得借助于Windows平臺本身，來解決。

SQL Server啟動的創建的日志文件路徑，同樣存在于注冊表項里，我們來看這個參數：

這里我們故意改成一個錯誤的路徑，來啟動下看看：

會產生以下錯誤

系統的錯誤日志信息

錯誤說明的很清楚。

解決方法：

這個問題解決起來也很簡單，只需要檢查好該路徑，確保路徑下的文件正確就可以。

不過有一點需?注意，當SQL Server還沒啟動起來的時候，有部分錯誤信息日志需要檢查Windows平臺下的系統日志。

----------------------------------------------------------分割線-----------------------------------------------------------------------

 第二步、檢查系統配置環境，包括硬盤、內存與CPU等

當我們進行完第一步的時候，SQL Server已經讀取完注冊表信息，完成了它的errorlog文件的創建，然后開始進行第二步的進行，這一步驟所有的信息就會按照順序依次記錄到errorlog文件中，我們可以通過查看該文件來詳細跟蹤這一步驟的進行，根據上一步的注冊表信息，我們先來手動清空下這個日志，然后重啟一下SQL Server服務，查看下這個日志記錄

我們簡單大致分了以下幾大步驟：

一、首先檢查系統的軟件環境，包括OS版本、電腦信號、內存、硬盤、注冊表基礎配置項是否正確等

二、啟動系統數據庫master

三、開始利用服務用戶登錄系統、啟動系統資源數據庫、檢查數據庫版本信息等

四、啟動系統數據庫model

五、開始網絡配置進行連接，對外提供服務，使用的默認的1433端口

我們接著分析下面的日志：

六、其實完成上面的第五步之后，也就開始啟動msdb系統數據

七、這時候開始真正的啟動用戶數據庫，并且完整各個庫的完整性校驗，并且在啟動用戶數據庫之前，先將系統庫的tempdb進行清空

八、在搭建完成之后，才開始啟系統的?外一個數據庫tempdb

上面的整個SQL  Server系統啟動的過程產生了詳細的日志記錄，我們下面會依次按照該步驟進行詳細的進行逐步分析。

在檢查系統軟硬件環境的過程中，基本不會發生什么致命錯誤。比較常見的問題就是內存配置問題，其實在上面的日志記錄中有一句特別重要，它反映的就是SQL Server利用內存的情況，我們來看：

這句話的意思是將所有的數據頁鎖定到內存中，作為大部分數據庫而言，內存就是生命線，SQL Server同樣也是，如果系統（64bit中）沒有內存壓?的情況下，才能將數據頁正常的鎖定到內存中，如果內存壓力過大，系統內存是不允許將數據頁也加入到內存中，而這樣導致的問題就是SQL  Server嚴重的性能問題。

很多用戶希望限制SQL Server內存使用，并且有些客戶機將它限制到服務都不能啟動的情況，這時候在SQL Server的日志中是這樣展現的，我們來看：

可以看到，該錯誤的原因還是挺清楚的，修復該錯誤的解決方法也很簡單，將內存配置調大就可以。

跟內存有關的還有一種特殊的情況，就是SQL Server的啟動賬號在服務器上沒有Lock page in memory的權限，如果沒有這個權限，在明細日志中查看不到上面的日志記錄，該問題的解決方法也很簡單，只需要將需要權限加上就可，加權限的方式如下：

經過上面的步驟基本，完成數據的軟硬件檢測過程。