2014-05-04 14:42:08.73 Server SQL Server detected 1 sockets with 2 cores per socket and 2 logical processors per socket, 2 total logical processors; using 2 logical processors based on SQL Server licensing. This is an informational message; no user action is required.

2014-05-04 14:42:08.73 Server SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.

2014-05-04 14:42:08.73 Server Detected 3838 MB of RAM. This is an informational message; no user action is required.

2014-05-04 14:42:08.76 Server Using conventional memory in the memory manager.

之后会显示NUMA信息和lock的信息，或为每个节点分配2500个锁块，5000个锁拥有者

注意，在32bit系统下，每个锁块需要64字节，锁拥有者32字节，64bit下，锁块96字节，锁拥有者56个字节：

2014-05-04 14:42:10.38 Server Node configuration: node 0: CPU mask: 0x0000000000000003:0 Active CPU mask: 0x0000000000000003:0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.

2014-05-04 14:42:10.40 Server Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.

显示CLR版本信息和默认TRACE的开启：

2014-05-04 14:42:11.33 Server CLR version v4.0.30319 loaded.

2014-05-04 14:42:12.44 spid8s Resource governor reconfiguration succeeded.

2014-05-04 14:42:12.49 spid8s SQL Server Audit is starting the audits. This is an informational message. No user action is required.

2014-05-04 14:42:12.60 spid8s SQL Server Audit has started the audits. This is an informational message. No user action is required.

2014-05-04 14:42:13.93 spid8s SQL Trace ID 1 was started by login "sa".

2014-05-04 14:42:14.09 spid8s Server name is 'FANRCO-PC'. This is an informational message only. No user action is required.

5.1.3 数据库启动

系统数据库的启动顺序是master，msdb，mssqlsystemresource，model，tempdb，也可以在errorlog中找到相关信息：

2014-05-04 14:42:10.57 spid8s Starting up database 'master'.

2014-05-04 14:42:16.67 spid21s Starting up database 'msdb'.

2014-05-04 14:42:16.67 spid22s Starting up database 'AdventureWorks2012'.

2014-05-04 14:42:16.74 spid10s Starting up database 'mssqlsystemresource'.

2014-05-04 14:42:16.74 spid23s Starting up database 'tst'.

2014-05-04 14:42:16.75 spid24s Starting up database 'AdventureWorksDW2012'.

2014-05-04 14:42:18.27 spid10s Starting up database 'model'.

2014-05-04 14:42:19.42 spid10s Clearing tempdb database.

2014-05-04 14:42:20.13 spid10s Starting up database 'tempdb'.

启动完成后，会打印一下信息：

2014-05-04 14:42:22.40 spid8s Recovery is complete. This is an informational message only. No user action is required.

5.1.4 准备网络

启动完成master数据库之后，就开始准备网络了，从注册表中读取注册表信息。然后开启功能：

Shard Memory启动后，errorlog会有：

2014-05-04 14:42:15.45 spid15s Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].

Named Pipe启动后，会有：

2014-05-04 14:42:15.45 spid15s Server local connection provider is ready to accept connection on [ \\.\pipe\sql\query ].

还有tcp启动之后监听的端口：

2014-05-04 14:42:15.52 Server Server is listening on [ ::1 <ipv6> 1433].

2014-05-04 14:42:15.52 Server Server is listening on [ 127.0.0.1 <ipv4> 1433].

如果有DAC专用管理连接，那么还会打印：

2014-05-04 14:42:15.52 Server Server is listening on [ ::1 <ipv6> 1434].

2014-05-04 14:42:15.52 Server Server is listening on [ 127.0.0.1 <ipv4> 1434].

2014-05-04 14:42:15.52 Server Dedicated admin connection support was established for listening locally on port 1434.

当网络准备完成之后会打印：

2014-05-04 14:42:15.59 spid15s SQL Server is now ready for client connections. This is an informational message; no user action is required.

在准备网络中，如果某个协议不能被加载，SQL Server会报错但是不会影响实例的启动。只有一个例外，使用SSL对连接加密的，SSL在启动需要SQL Server加载证书，如果证书无法加载那么SQL Server启动会被终止。

5.2 数据库状态切换

5.2.1 Recovering

Recovering主要处理3件事情：

1.分析要做的工作：就是在事务日志文件中，找到那些事务要重做，那些事务要回滚

2.Redo：将已经提交的但是没有写入数据文件的事务，做前滚

3.undo：对没有提交的事务做回滚

一下几个动作会让数据库进入Recovering：

1.创建数据库

2.Alter Online，上线数据库

3.RESTORE WITH RECONVERY：恢复数据库

4.DatabaseStartup，数据库启动，如果数据库设置了自动关闭，就会在用户第一次访问的时候做这个动作。

恢复正常之后，数据库会进入online状态。

5.2.2 Online

这个状态下用户可以访问，修改。

5.2.3 RECOVERY PENDING

如果在数据恢复的时候不能正确打开数据库文件，数据库会进入RECONVERY PENDING的状态。

解决办法：用ALTER ONLINE再恢复一次，或者使用备份恢复

5.2.4 SUSPECT

数据库进入SUSPECT状态在这个状态下管理员有3个选择：

1.在一次ALTER ONLINE，命令SQL Server再恢复一次

2.放弃当前数据库，再还原一个

3.将数据库状态设置为，EMERGENCY，然后尝试修复

5.2.5 EMERGENCY

在这个模式下，SQL Server对没有完全恢复的数据库开放一个只读窗口

5.2.6 RESTORING

数据库在还原状态下，如果是WITH RECOVERY，还原的最后一步会进入RECONVERY状态。

5.2.7 Offline

数据库处于离线状态，可以使用ALTER ONLINE让数据库上线。

5.3 数据库长时间处于RECOVERING状态

RECONVERING主要做3件事：

1.查看需要恢复那些事务

2.redo事务

3.undo事务

如果在redo和undo遇到问题数据库就会进入SUSPECT状态，在完成恢复之前数据库必须等待完成。

如果长期处于RECOVERING可以使用，以下sql查看进度

SELECT*FROMsys.sysprocesses

SELECT*FROMsys.dm_exec_requests

如果没有什么变化，可以开了重启服务，再做一次恢复。

有时候不是很忙的数据库恢复要很长时间，是因为有过多的VLF（虚拟日志文件），导致恢复计算量过大，导致恢复很慢。

可以使用DBCC LOGINFO查看虚拟日志情况。

5.3.1 多线程并行处理重做和回滚

在企业版上，SQL Server会启动多个线程来重做和回滚动作。

5.3.2 延迟事务

这个和找不到数据文件不同，延迟事务是在恢复过程中，出现IO错误，那个事务所修改的数据都会被适当的锁定。SQL Server会放弃这个事务的回滚，继续回滚其他事务。上面的锁会在dbcc checkdb修复一致性后释放。

5.4 数据库无法启动的常见问题

5.4.1 Master数据库不能启动

Master数据库不能启动一般是有怎么几种情况：

1.sql server启动参数中，指定的文件路径不对。

2.找到了数据库文件但是没有权限

3.数据库文件出现损坏，如果出现损坏，要不从备份中恢复，要不重建master数据库（重建master数据库可以看联机文档）。

5.4.2 资源数据库

Mssqlsystemresouce数据库，对用户透明，用户无法直接访问这个数据库。出现的问题一般如下：

1.sql server启动参数中，指定的文件路径不对。

2.发现资源数据库的版本和数据库版本不一致。

如果发现不一致相同版本的其他实例中复制一个。

5.4.3 model数据库

Model数据库是所有用户数据库的样板，根据model数据库创建的用户数据库。出现的问题和master类似。

如果出现问题：

方法一、

1.带traceno 3608启动，可以绕过model的恢复

2.恢复model数据库

3.重启

方法二、

直接替换model文件

方法三、

重建model数据库

5.4.4 tempdb数据库

Tempdb数据库是每次服务重启就会重建，所以可能出现的问题是：

1.物理文件路径不对

a.traceno 3608启动

b.修改数据库文件路径

c.重启

2.tempdb创建文件失败，创建失败一般是没有权限或者空间不够，如果空间不够：

a.traceno 3608启动

b.修改数据库文件大小

c.重启

5.4.5 用户数据库

用户数据库不能启动的常见问题是：缺少或者无法打开部分文件，恢复失败。前者数据库进入RECOVERY_PENDING状态，后者会进入SUSPECT状态。

5.4.5.1 文件打开问题

文件打开分为2类：数据文件，日志文件。

数据库文件

如果主文件组出现问题，只有当主文件组全部恢复后才能打开数据库

如果是辅助文件组可以先把辅助文件组offline，然后 ALTER ONLINE数据库。

然后从备份中恢复这个文件组

日志文件

如果是简单恢复模式，在上次数据库正常关闭（写入所有提交的数据，撤销所有未提交的事务），那么下次SQL Server启动这个数据库的时候，发现日志文件不存在会重新创建一个。

如果是完全恢复模式，或者上次没有正常关闭，就不会为这个数据库创建日志文件

如果要恢复数据库，可以使用备份还原，也可以通过dbcc checkdb来恢复，不过可能会丢失一部分数据。

5.4.5.2 恢复失败

在恢复中会出现3累错误

1.在redo过程中遇到能延迟的错误

2.在undo过程中遇到能延迟的错误

3.遇到不能延迟的错误

重做中遇到错误

如果错误是可以延迟的，遇到错误的页面被锁定。

撤销中遇到错误

在侧小的时候发生错误，SQL Server会标记整个事务涉及到的页面，然后继续其他undo。该锁的对象属于session -3

遇到这个问题可以通过备份恢复，也可以用dbcc checkdb恢复，不会可能要丢失一部分数据

SUSPECT模式

当数据库恢复失败不能延迟，最终会进入SUSPECT模式。一般出现这种情况，要不就是有大量的损坏，要不就是分配页出现损坏。