您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
SQL Server数据库启动过程详解
 
来源:码农网 发布于:2015-2-6
1061 次浏览     评价:      
 

目前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的权限,如果没有这个权限,在明细日志中查看不到上面的日志记录,该问题的解决方法也很简单,只需要将需要权限加上就可,加权限的方式如下:

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

第三步、启动系统数据库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或者打完补丁之后,就及时的备份这个两个文件,放在安全的地方,用的时候拷贝过来就行,备份是数据库管理员的天职

当然有时候在紧急的情况下,找不到相同版本的数据库,理论上这个库是只读的,所以不会发生任何改变,我们随便找一台机器,安装一下同版本数据库,然后拷贝过来就行,当然一定注意的是这里面是相同版本。

第五步、启动系统数据库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进行了多种无情的蹂躏、各种的摧残,力求能够重显各种不同的应用场景问题现象,然后尽可能的找到合适的解决方案,当然还有很多的情况没有展现出来,后续遇到,会一一补充进来,当然有遇到不能解决的,也可以留言,我们一起分析解决。

关于用户数据库启动过程,这个过程是一个问题较易发生的步骤,神马质疑、恢复中、不可用等等现象,我后续的文章中列举分析。

   
 订阅
  捐助
相关文章 相关文档 相关课程



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
 

MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


领先IT公司 android开发平台最佳实践
北京 Android开发技术进阶
某新能源领域企业 Android开发技术
某航天公司 Android、IOS应用软件开发
阿尔卡特 Linux内核驱动
艾默生 嵌入式软件架构设计
西门子 嵌入式架构设计
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号