第五步、启动系统数据库model
model系统数据库同样也是SQL Server启动过程中用到的一个非常关键的数据库，如果这个库损坏，SQL Server启动也会失败，关于model数据不能启动的原因基本和master的类似，同样也是两种：1、数据库文件早不到或者不能访问；2、数据库文件能访问但是是损坏的文件。
诊断此种问题的方式也和上面的两种方式一样，查看启动过程产生的errorlog文件或者windows系统日志，这里我们就不重现该问题了。
我们只给出此种问题的解决方法：
1、如果该库我们已经做过备份，那最直接也是最有效的解决方式就是直接还原，这里的还原方式可能和普通库的还原方式不一样，因为SQL Server实例还没有启动，我们恢复过程采取以下过程：
a.用参数启动SQL Server，在命令提示行中执行以下命令，这样的话SQL Server启动就会跳过model数据库恢复这一步
net start MSSQLSERVER /f /m /T3608
b.现在恢复model数据库，打开SSMS，直接输入
RESTORE DATABASE model FROM DISK ='G:\data\model.bak' WITH MOVE 'modeldev' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.mdf' MOVE 'modellog' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.ldf' ,replace
c.恢复成功后，直接重启SQL Server既可以。
2、将SQL Server关闭，然后直接采取暴力的方式将model数据文件拷贝回来就可以，这种方式简单有效，但是非常规操作
3、还有一种方式是利用setup安装文件，重建该数据库，过程缓慢，稍显复杂，很不推荐。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第六步、开始网络配置进行连接，对外提供服务，使用的默认的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:\right path....\temdb.mdf'); go ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdblog.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进行了多种无情的蹂躏、各种的摧残��力求能够重显各种不同的应用场景问题现象，然后尽可能的找到合适的解决方案，当然还有很多的情况没有展现出来，后续遇到，会一一补充进来，当然有遇到不能解决的，也可以留言，我们一起分析解决。
关于用户数据库启动过程，这个过程是一个问题较易发生的步骤，神马质疑、恢复中、不可用等等现象，我后续的文章中列举分析。
已经补充出该篇的关联篇：SQL Server数据库启动过程及用户数据库加载过程的疑难杂症