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

當上面的幾個重要的?統庫都已經啟動完成之后，下一步就是開始檢查網絡環境，進行網絡服務的配置，對外進行提供服務了，一般來講，在SQL Server中利用的網絡啟動協議有三種：Shared Memory、Named Pope和TCP/IP，其實在日常我們最常用的就是TCP/IP這種方式了，并且默認開啟的是1433端口。

我們來看一下正常啟動過程中，該部?的詳細日志：

這?的Shared Memory是專供本地連接通過LPC(Local Procedure Call)技術向SQL Server做的連接。它不走網絡層，所以他是速度最快的連接方式。正常啟動后會顯示上面的正常日志。

Named Pipe方式正常啟動，也會顯示出上面的日志。可以看到。

這其中我們最常用的TCP/IP這種方式，也正常的啟動了，并且指定了兩種訪問方式，ipv4/ipv6，然后后面加上了1433端口號。

在這個過程中最常出現的問題就是，1433端口被其它程序占用，這樣就導致TCP/IP協議無法正常啟動，這樣我們會看到如下日志信?

并且在windows 系統日志?也會有記錄

解決方法：

其實這里出現的問題還是挺好解決的，只需要找到占用這個端口的應用程序，采取措施讓它把這個端口給讓出來就可以。

當然出現這些問題?意味著客戶端已經無法通過TCP/IP這種遠程連接的方式進行連接訪問了。

這時候一般管理員可以采用SQL Server給其提供的“專用管理員連接”（DAC）進行連接，這種方式我們以后再介紹。

當然，在SQL Server啟動的過程中，一般出現這種網絡問題，或者協議不能成功加載，SQL Server會報出錯誤信息，但是一般情況下是不會影響SQL Server的正常啟動的。受影響的可能只是出問題的那種協議功能。

我們只需要根據日志，定位問題，然后解決掉，重新啟動就可以了。

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

第七步、開始啟動msdb系統數據庫

關于msdb這個系統數據庫，它是被安排在系統庫中接近最后一個了，除了用戶數據庫和臨時庫tempdb之外，當啟動過程中已經進行到這一步的時候，其實我們的實例就已經啟動起來了，并且能夠連接。

我們知道msdb這個庫中主要的存儲的信息是應用各個庫的備份信息，各種job的歷史跑批信息等，其實諸多的都是來自于用戶數?庫所產生的一些客觀數據。

我們來看一下這個庫出現了問題會產生什么現象：

我將這個庫文件移除走，然后重新啟動服務，啟動過程中沒有報任何錯誤，并且能夠順利啟動?我們用SSMS直接連接過去，也可以正常連接

但是當我們點擊開數據的時候，其實是看不到任何用戶數據庫的，并且會產生一個錯誤提示：

看來是不能使用的，我們來查看一下錯誤日志：

雖然這個庫的重要性比起master之類的庫重要性要稍顯差一些，但是缺少了它我們的SQL Server雖然能啟動，但是依然不能使用。

解決方法：

要解決這個問題其實方式就很多種了，因為到此我們的SQL Server實例已經能夠正常啟動了，我們可以采取：

1、利用備份還原該庫，參考文章前面的方式（推薦）

2、關掉服務，利用暴力的拷貝文件的方式進行恢復，簡單有效，非常規操作

3、找臺相同的環境，找到相同的文件，直接拷貝?來使用

4、利用安裝文件進行恢復（不推薦）

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

第八步、啟動用戶數據庫，并且完整各個庫的完整性校驗，并且在啟動用戶數據庫之前，先將系統庫的tempdb進行清空

本步驟所遇到的問題層出不窮，各種樣式，?打算再重新組織一篇文章，專門列舉，此篇就?介?了。

但有一點需要記住：在這一步之前SQL Server會將tempdb這個系統庫清空掉，也就是說，每次的重啟操作，系統都會將tempdb清空，然后重建，這一步一般不會發生異常，成功之后會出現以下日志信息：

第九步、開始重建系統的另外一個數據庫tempdb

tempdb這個庫比較特殊，每次重啟的時候都是重新創建的，SQL Server會根據master數據庫里的記錄的信息以model數據庫為本進行創建。所以只要我們保證model數據庫沒有問題，然后硬盤沒有問題，tempdb的數據庫文件就應該沒有問題。

關于temdb這個庫的所有配置信息是存儲于master的數據庫中的，里面的內容信息是存儲于model系統庫中的

這樣就帶來了一個問題，有時候我們的master的庫是從別的機器下面備份下來的，所以它里面會記錄這個tempdb這個庫在原來機器上的路徑，這樣在啟動創建的時候就會報錯。

所以我們需要執行以下命令更改這個庫路徑

a、用參數啟動SQL Server

net start MSSQLSERVER /f  /m  /T3608

b.修改數據文件和日志文件路徑

ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:
ight path....	emdb.mdf');
go
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:
ight path....	emdblog.ldf');
go

c.正常啟動數據庫既可以

還有一種情況，就是創建該文件的時候，提供的硬盤空間不足，或者權限不夠，我們也是根據上面的方式，修改到一個正確的路徑，并且確保權限正確。

也可以更改temp文件的大小，默認是4M，代碼如下：

ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
go
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
go

至此，如果上面的整個過程都沒出問題的話，?個正常的SQL Server就可以啟動成功的。

結語

本篇文章到此結束了.....此篇耗時三天.....為了盡可能的呈現出所有的問題現象，我對本地的SQL Server進行了多種無情的蹂躪、各種的摧殘，力求能夠重顯各種不同的應用場景問題現象，然后盡可能的找到合適的解決方案，當然還有很多的情況沒有展現出來，后續遇到，會一一補充進來，當然有遇到不能解決的，也可以留言，我們一起分析解決。

關于用戶數據庫啟動過程，這個過程是一個問題較易發生的步驟，神馬質疑、恢復中、不可用等等現象，后續的文章中列舉分析。