第二步、检查系统配置环境，包括硬盘、内存与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的权限，如果没有这个权限，在明细日志中查看不到上面的日志记录，该问题的解决方法也很简单，只需要将需要权限加上就可，加权限的方式如下：
经过上面的步骤基本，完成数据的软硬件检测过程。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第三步、启动系统数据库master
master数据库是SQL Server系统启动过程中的第一个系统库，是非常关键的数据库。如果这个库不能被正常打开，则SQL Server就不能正常启动。
和其它数据库一样，master数据库也分为数据文件和日志文件，启动的过程是依次打开，然后做恢复动作，如果这个过程没问题的话，在Errorlog日志文件中，我们会看到如下的这句话：
如果这个过程出现了任何问题，SQL Server的启动过程都会被中断，启动过程失败。
而这个过程发生的错误，无非就集中以下几种情况，我们来分析一下：
<1>在指定的路径找不到master数据的数据文件或日志文件
关于这个SQL Server的最主要的系统数据库的路径，它是以注册表形式存在的，在一下注册表项，可以看到
如果在该路径下找不到这个系统数据库的话，服务是启动不了的，并且会产生相应的错误日志信息，我们来模拟下，关掉服务，将这两个文件移除走，然后启动看一下：
首先，该服务是启动失败的
我们来看一下系统日志
看Errorlog的日志信息
可以看到，该问题提示错误信息还是挺详细的。我们来看第二种情况
<2>文件找到了，但是没有权限访问，或者不能以排他的方式打开该文件（默认的是独占锁进行文件打开的）
此种情况也是有可能产生的，比如某些NB的杀毒软件就可以干这个事，让你的系统库无法访问，这样同样也是启动不了的，我们这样来看，提示的错误的信息有哪些：
来看Errorlog的错误记录：
<3>文件找到了，访问权限也有，但是文件有问题，就是说是数据库损坏了
这个问题也经常出现，比如磁盘坏掉了，恢复后发现文件有问题，不能正常打开，这种问题我们来看错误信息：
日志中的信息
关于master系统库的启动过程，基本就是上面的三种错误，关于这三种问题，我们该如何解决呢？
解决方法：首先如果根据错误日志定位出问题的性质，如果是前两种问题其实是挺好解决的，比如文件没找到、权限项不对等，这些问题相应的去解决就可以，最棘手的就是第三种情况，出现这种情况最理想的情况是master数据库进行了备份，通过备份文件进行恢复就可以，一切就可以正常，当然通过暴力的停掉服务，拷贝文件进去也可以解决。
最揪心的就是这个库就没备份，那该如何解决呢？这种方式的解决就得借助SQL Server的安装程序，进行重建master数据了，但是这种方式重建的master数据库会导致以前的SQL Server的设定全部清空掉。
清空的信息包括：所有的账户信息（意味着需要重建）、msdb中的所有job信息等（也需要重建）、用户数据库信息（必须全部重新附加attch上）
而这一系列过程如果是一个生产库，可能会是一个非常大的工作量！
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第四步、启动系统资源数据库，并检查数据版本信息
资源数据库是SQL Server2005中引入的逻辑数据库，在实例下是看不到的，但是有它的物理文件，主数据库默认名称为：mssqlsystemresource.mdf、日志名称为：mssqlsystemresource.ldf
如果该数据库启动的过程中也出现了问题，那SQL Server也不能正常启动。
这个系统数据库比较特别，它是一个只读数据库，完全由SQL Server自己维护，用户是不能更改的，所以我们只要保证它的是数据库文件和日志完好就可以，不需要对它进行任何的跟踪和维护。
当然如果非要看这个数据库，可以通过单用户的DAC方式进行连接。
所以这个数据库在一般情况下不会发生意外，基本上是能正常启动，不过特殊情况下，不能启动的情况就以下两种：
<1>数据库文件不存在，无法访问，或者文件坏掉了
其实它的报的错误信息，类似于上面的master数据库，我来截个图，看一下：
这个是errorlog记录的错误信息
在windows层面也有它自己的错误日志信息：
<2>资源数据库的版本和SQL Server的版本不一致
这个有可能是人为的更改了这个资源数据库，导致现有的资源数据库文件和数据库版本不一致，这样的话也会导致错误的形成
windwos平台也记录下了该错误的信息，看下面的图片：
解决方法：
关于资源库的这两个问题解决方法，非常的简单。只要找到和这台服务器上的SQL Server的版本一致的数据库，拷贝过来就行。
当然最好的预防措施是：每当安装完SQL Server或者打完补丁之后，就及时的备份这个两个文件，放在安全的地方，用的时候拷贝过来就行，备份是数据库管理员的天职
当然有时候在紧急的情况下，找不到��同版本的数据库，理论上这个库是只读的，所以不会发生任何改变，我们随便找一台机器，安装一下同版本数据库，然后拷贝过来就行，当然一定注意的是这里面是相同版本。