第六步、開始網(wǎng)絡(luò)配置進行連接，對外提供服務(wù)，使用的默認的1433端口

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

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

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

Named Pipe方式正常啟動，也會顯示出上面的日志?？梢钥吹?。

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

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

并且在windows 系統(tǒng)日志?也會有記錄

解決方法：

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

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

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

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

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

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

第七步、開始啟動msdb系統(tǒng)數(shù)據(jù)庫

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

我們知道m(xù)sdb這個庫中主要的存儲的信息是應(yīng)用各個庫的備份信息，各種job的歷史跑批信息等，其實諸多的都是來自于用戶數(shù)?庫所產(chǎn)生的一些客觀數(shù)據(jù)。

我們來看一下這個庫出現(xiàn)了問題會產(chǎn)生什么現(xiàn)象：

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

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

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

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

解決方法：

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

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

2、關(guān)掉服務(wù)，利用暴力的拷貝文件的方式進行恢復，簡單有效，非常規(guī)操作

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

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

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

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

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

但有一點需要記?。涸谶@一步之前SQL Server會將tempdb這個系統(tǒng)庫清空掉，也就是說，每次的重啟操作，系統(tǒng)都會將tempdb清空，然后重建，這一步一般不會發(fā)生異常，成功之后會出現(xiàn)以下日志信息：

第九步、開始重建系統(tǒng)的另外一個數(shù)據(jù)庫tempdb

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

關(guān)于temdb這個庫的所有配置信息是存儲于master的數(shù)據(jù)庫中的，里面的內(nèi)容信息是存儲于model系統(tǒng)庫中的

這樣就帶來了一個問題，有時候我們的master的庫是從別的機器下面?zhèn)浞菹聛淼?，所以它里面會記錄這個tempdb這個庫在原來機器上的路徑，這樣在啟動創(chuàng)建的時候就會報錯。

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

a、用參數(shù)啟動SQL Server

net start MSSQLSERVER /f  /m  /T3608

b.修改數(shù)據(jù)文件和日志文件路徑

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.正常啟動數(shù)據(jù)庫既可以

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

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

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

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

結(jié)語

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

關(guān)于用戶數(shù)據(jù)庫啟動過程，這個過程是一個問題較易發(fā)生的步驟，神馬質(zhì)疑、恢復中、不可用等等現(xiàn)象，后續(xù)的文章中列舉分析。