目前SQL Server数据库作为微软一款优秀的RDBMS，其本身启动的时候是很少出问题的，我们在平时用的时候，很少关注起启动过程，或者很少了解其底层运行过程，大部分的过程只关注其内部的表、存储过程、视图、函数等一系列应用方式，而当有一天它运行的正常的时候突然启动不起来了，这时候就束手无策了，能做的或许只能是重装、配置、还原等，但这一个过程其实是一个非常耗时的过程，尤其当我们面对是庞大的生产库的时候，可能在这火烧眉毛的时刻，是不允许你再重搭建一套环境的。

所以作为一个合格的数据库使用者，我们要了解其启动、运行过程的事情，一旦发生问题，我们也?及时定位，迅速解决。

闲言少叙，我们进入本篇的正题。 

SQL Server本身就是一个Windows服务，每一个实例对应的就是一个sqlserver.exe进程。这是一个可执行的文件，默认就放在SQL Server的安装目录下，当我们启动的时候，就是直接调用这个文件，然后启动这个服务。 

第一部分、SQL Server实例启动的方法和启动所发生的问题

  SQL Server实例分为下面几种启动方法：

（1）在Windows服务控制台里手动启动，或者自动启动（默认），这个也是最常用的方式

（2）第二种方式是SQL Server本身自己提供的启动方式，我们这里可以手动启动

（3）在SQL Server的SSMS里面手动启动它，这个方式一般大部分利用这种方式进行手动重启

（4）通过Windows命令窗口，用'net start'命令手动启动，这种方法也可以用

以上这几种方式都可以启动SQL Sever,并且都会在SQL 日志信息中有所记录。

第二部分、SQL Server实例启动的详细过程以及所发生的问题项

第一步、检查注册表项

当一个sqlserver.exe文件开始启动的时候，首先要干的第一件事就是先检查它的配置信息存放于注册表的值项

比较重要的几个键值有下面几个：

这里的

AuditLevel:其实就是SQL 如何记录用户登录记录；

LoginMode:是SQL Server服务器身份验证方式等；

BackupDirectory:默认的备份路径等信息；

关于注册表信息简要了解即可，不建议做任何修改，当然这些值的信息默认在SQL Server中都能设置：

在不修改注册表的情况下，一般这一步的启动顺序一般不会出现问题，当然出现问题了也通常没有办法解决，大?分的解决方式只有重装了。

但这一步骤，通常出现以下两个个问题通常是可以解决的：

<1>启动账号权限问题

如果我们启动SQL Server的进程使用的账号连读注册表的权限都没有，那这个服务是怎么也启动不了的，通常这时候连SQL 的错误日志都没有能力生成出来。

这时候我们该如何发现呢，虽然这时候它没有能力创建SQL 的错误日志，但是它在Windows层面留下了痕迹，我们来看：

我将服务启动账号设置成gust来宾账号，来启动该服务

这时候会产生以下错误信息：

在Windows的日志信息里也会产生一条错误日志记录：

这里的拒绝访问指的就是拒绝访问注册表信息了。

解决方法：

此问题的解决方式就很简单了，只需要将当然的用户提权到SQL Server服务的启动账号就行了，提权的方式也很简单，只需要添加到SQL的本地用户的启动服务组就可以了。

当然，也可以直接换一个更高级别的用户登录。一般默认都用的超级管理员账户。

<2>访问日志和文件夹出现问题

默认在SQL Server启动的时候会创建一个启动日志文件，记录所有正确的日志信息，当然也?括错误的日志信息，如果这时候找不到这个日志信息的路径，或者已经存在一个日志，但是日志被锁定了（某些NB的杀毒软件擅长干这个），这时候这个服务也是启动不了的，同样也创建不出SQL Server的日志文件，这时候我们还得借助于Windows平台本身，来解决。

SQL Server启动的创建的日志文件路径，同样存在于注册表项里，我们来看这个参数：

这里我们故意改成一个错误的路径，来启动下看看：

会产生以下错误

系统的错误日志信息

错误说明的很清楚。

解决方法：

这个问题解决起来也很简单，只需要检查好该路径，确保路径下的文件正确就可以。

不过有一点需?注意，当SQL Server还没启动起来的时候，有部分错误信息日志需要检查Windows平台下的系统日志。

----------------------------------------------------------分割线-----------------------------------------------------------------------

 第二步、检查系统配置环境，包括硬盘、内存与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的权限，如果没有这个权限，在明细日志中查看不到上面的日志记录，该问题的解决方法也很简单，只需要将需要权限加上就可，加权限的方式如下：

经过上面的步骤基本，完成数据的软硬件检测过程。