目前SQL Server數(shù)據(jù)庫作為微軟一款優(yōu)秀的RDBMS，其本身啟動(dòng)的時(shí)候是很少出問題的，我們?cè)谄綍r(shí)用的時(shí)候，很少關(guān)注起啟動(dòng)過程，或者很少了解其底層運(yùn)行過程，大部分的過程只關(guān)注其內(nèi)部的表、存儲(chǔ)過程、視圖、函數(shù)等一系列應(yīng)用方式，而當(dāng)有一天它運(yùn)行的正常的時(shí)候突然啟動(dòng)不起來了，這時(shí)候就束手無策了，能做的或許只能是重裝、配置、還原等，但這一個(gè)過程其實(shí)是一個(gè)非常耗時(shí)的過程，尤其當(dāng)我們面對(duì)是龐大的生產(chǎn)庫的時(shí)候，可能在這火燒眉毛的時(shí)刻，是不允許你再重搭建一套環(huán)境的。

所以作為一個(gè)合格的數(shù)據(jù)庫使用者，我們要了解其啟動(dòng)、運(yùn)行過程的事情，一旦發(fā)生問題，我們也?及時(shí)定位，迅速解決。

閑言少敘，我們進(jìn)入本篇的正題。 

SQL Server本身就是一個(gè)Windows服務(wù)，每一個(gè)實(shí)例對(duì)應(yīng)的就是一個(gè)sqlserver.exe進(jìn)程。這是一個(gè)可執(zhí)行的文件，默認(rèn)就放在SQL Server的安裝目錄下，當(dāng)我們啟動(dòng)的時(shí)候，就是直接調(diào)用這個(gè)文件，然后啟動(dòng)這個(gè)服務(wù)。 

第一部分、SQL Server實(shí)例啟動(dòng)的方法和啟動(dòng)所發(fā)生的問題

  SQL Server實(shí)例分為下面幾種啟動(dòng)方法：

（1）在Windows服務(wù)控制臺(tái)里手動(dòng)啟動(dòng)，或者自動(dòng)啟動(dòng)（默認(rèn)），這個(gè)也是最常用的方式

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

（3）在SQL Server的SSMS里面手動(dòng)啟動(dòng)它，這個(gè)方式一般大部分利用這種方式進(jìn)行手動(dòng)重啟

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

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

第二部分、SQL Server實(shí)例啟動(dòng)的詳細(xì)過程以及所發(fā)生的問題項(xiàng)

第一步、檢查注冊(cè)表項(xiàng)

當(dāng)一個(gè)sqlserver.exe文件開始啟動(dòng)的時(shí)候，首先要干的第一件事就是先檢查它的配置信息存放于注冊(cè)表的值項(xiàng)

比較重要的幾個(gè)鍵值有下面幾個(gè)：

這里的

AuditLevel:其實(shí)就是SQL 如何記錄用戶登錄記錄；

LoginMode:是SQL Server服務(wù)器身份驗(yàn)證方式等；

BackupDirectory:默認(rèn)的備份路徑等信息；

關(guān)于注冊(cè)表信息簡(jiǎn)要了解即可，不建議做任何修改，當(dāng)然這些值的信息默認(rèn)在SQL Server中都能設(shè)置：

在不修改注冊(cè)表的情況下，一般這一步的啟動(dòng)順序一般不會(huì)出現(xiàn)問題，當(dāng)然出現(xiàn)問題了也通常沒有辦法解決，大?分的解決方式只有重裝了。

但這一步驟，通常出現(xiàn)以下兩個(gè)個(gè)問題通常是可以解決的：

<1>啟動(dòng)賬號(hào)權(quán)限問題

如果我們啟動(dòng)SQL Server的進(jìn)程使用的賬號(hào)連讀注冊(cè)表的權(quán)限都沒有，那這個(gè)服務(wù)是怎么也啟動(dòng)不了的，通常這時(shí)候連SQL 的錯(cuò)誤日志都沒有能力生成出來。

這時(shí)候我們?cè)撊绾伟l(fā)現(xiàn)呢，雖然這時(shí)候它沒有能力創(chuàng)建SQL 的錯(cuò)誤日志，但是它在Windows層面留下了痕跡，我們來看：

我將服務(wù)啟動(dòng)賬號(hào)設(shè)置成gust來賓賬號(hào)，來啟動(dòng)該服務(wù)

這時(shí)候會(huì)產(chǎn)生以下錯(cuò)誤信息：

在Windows的日志信息里也會(huì)產(chǎn)生一條錯(cuò)誤日志記錄：

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

解決方法：

此問題的解決方式就很簡(jiǎn)單了，只需要將當(dāng)然的用戶提權(quán)到SQL Server服務(wù)的啟動(dòng)賬號(hào)就行了，提權(quán)的方式也很簡(jiǎn)單，只需要添加到SQL的本地用戶的啟動(dòng)服務(wù)組就可以了。

當(dāng)然，也可以直接換一個(gè)更高級(jí)別的用戶登錄。一般默認(rèn)都用的超級(jí)管理員賬戶。

<2>訪問日志和文件夾出現(xiàn)問題

默認(rèn)在SQL Server啟動(dòng)的時(shí)候會(huì)創(chuàng)建一個(gè)啟動(dòng)日志文件，記錄所有正確的日志信息，當(dāng)然也?括錯(cuò)誤的日志信息，如果這時(shí)候找不到這個(gè)日志信息的路徑，或者已經(jīng)存在一個(gè)日志，但是日志被鎖定了（某些NB的殺毒軟件擅長(zhǎng)干這個(gè)），這時(shí)候這個(gè)服務(wù)也是啟動(dòng)不了的，同樣也創(chuàng)建不出SQL Server的日志文件，這時(shí)候我們還得借助于Windows平臺(tái)本身，來解決。

SQL Server啟動(dòng)的創(chuàng)建的日志文件路徑，同樣存在于注冊(cè)表項(xiàng)里，我們來看這個(gè)參數(shù)：

這里我們故意改成一個(gè)錯(cuò)誤的路徑，來啟動(dòng)下看看：

會(huì)產(chǎn)生以下錯(cuò)誤

系統(tǒng)的錯(cuò)誤日志信息

錯(cuò)誤說明的很清楚。

解決方法：

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

不過有一點(diǎn)需?注意，當(dāng)SQL Server還沒啟動(dòng)起來的時(shí)候，有部分錯(cuò)誤信息日志需要檢查Windows平臺(tái)下的系統(tǒng)日志。

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

 第二步、檢查系統(tǒng)配置環(huán)境，包括硬盤、內(nèi)存與CPU等

當(dāng)我們進(jìn)行完第一步的時(shí)候，SQL Server已經(jīng)讀取完注冊(cè)表信息，完成了它的errorlog文件的創(chuàng)建，然后開始進(jìn)行第二步的進(jìn)行，這一步驟所有的信息就會(huì)按照順序依次記錄到errorlog文件中，我們可以通過查看該文件來詳細(xì)跟蹤這一步驟的進(jìn)行，根據(jù)上一步的注冊(cè)表信息，我們先來手動(dòng)清空下這個(gè)日志，然后重啟一下SQL Server服務(wù)，查看下這個(gè)日志記錄

我們簡(jiǎn)單大致分了以下幾大步驟：

一、首先檢查系統(tǒng)的軟件環(huán)境，包括OS版本、電腦信號(hào)、內(nèi)存、硬盤、注冊(cè)表基礎(chǔ)配置項(xiàng)是否正確等

二、啟動(dòng)系統(tǒng)數(shù)據(jù)庫master

三、開始利用服務(wù)用戶登錄系統(tǒng)、啟動(dòng)系統(tǒng)資源數(shù)據(jù)庫、檢查數(shù)據(jù)庫版本信息等

四、啟動(dòng)系統(tǒng)數(shù)據(jù)庫model

五、開始網(wǎng)絡(luò)配置進(jìn)行連接，對(duì)外提供服務(wù)，使用的默認(rèn)的1433端口

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

六、其實(shí)完成上面的第五步之后，也就開始啟動(dòng)msdb系統(tǒng)數(shù)據(jù)

七、這時(shí)候開始真正的啟動(dòng)用戶數(shù)據(jù)庫，并且完整各個(gè)庫的完整性校驗(yàn)，并且在啟動(dòng)用戶數(shù)據(jù)庫之前，先將系統(tǒng)庫的tempdb進(jìn)行清空

八、在搭建完成之后，才開始啟系統(tǒng)的?外一個(gè)數(shù)據(jù)庫tempdb

上面的整個(gè)SQL  Server系統(tǒng)啟動(dòng)的過程產(chǎn)生了詳細(xì)的日志記錄，我們下面會(huì)依次按照該步驟進(jìn)行詳細(xì)的進(jìn)行逐步分析。

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

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

很多用戶希望限制SQL Server內(nèi)存使用，并且有些客戶機(jī)將它限制到服務(wù)都不能啟動(dòng)的情況，這時(shí)候在SQL Server的日志中是這樣展現(xiàn)的，我們來看：

可以看到，該錯(cuò)誤的原因還是挺清楚的，修復(fù)該錯(cuò)誤的解決方法也很簡(jiǎn)單，將內(nèi)存配置調(diào)大就可以。

跟內(nèi)存有關(guān)的還有一種特殊的情況，就是SQL Server的啟動(dòng)賬號(hào)在服務(wù)器上沒有Lock page in memory的權(quán)限，如果沒有這個(gè)權(quán)限，在明細(xì)日志中查看不到上面的日志記錄，該問題的解決方法也很簡(jiǎn)單，只需要將需要權(quán)限加上就可，加權(quán)限的方式如下：

經(jīng)過上面的步驟基本，完成數(shù)據(jù)的軟硬件檢測(cè)過程。