博客园_飞洋过海

SQLServer 数据库镜像+复制切换方案

2012-05-25T09:40:00Z

目标：

主机做了Mirror和Replication，当主机出现问题时，Replication和Mirror实现自动的故障转移（Mirror 和Replication都切换到备机，而当主机

重新启动后，自动充当备机的角色）。

环境：

五台虚拟机，配置均为Windows2008 Enterprise + SQLServer2008R2 Enterprise

08R201：Mirror 见证机(WITNESS) IP:192.168.56.101

08R202：主机（Rep+Mirror） IP:192.168.56.102

08R203：Rep分发机 IP:192.168.56.103

08R204：Rep订阅机 IP:192.168.56.104

08R205：镜像机（Mirror） IP:192.168.56.105

步骤：

配置有见证服务器的镜像

创建证书和Endpoint

08R202(Master) 上运行下面的脚本：

--主机执行：
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '123456abc';
CREATE CERTIFICATE HOST_A_cert WITH SUBJECT = 'HOST_A certificate' ,
START_DATE = '11/08/2010',EXPIRY_DATE = '10/31/2099';

--主机执行：
CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS
TCP ( LISTENER_PORT=5022 , LISTENER_IP = ALL )
FOR
DATABASE_MIRRORING
( AUTHENTICATION = CERTIFICATE HOST_A_cert , ENCRYPTION = REQUIRED ALGORITHM AES , ROLE = ALL );

--主机执行：

BACKUP CERTIFICATE HOST_A_cert TO FILE = 'D:\HOST_A_cert.cer';

08R205(Mirror) 上运行下面的脚本：

--备机执行：
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '123456abc';
CREATE CERTIFICATE HOST_B_cert WITH SUBJECT = 'HOST_B certificate',
START_DATE = '11/08/2010',EXPIRY_DATE = '10/31/2099';

--备机执行：
CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS
TCP ( LISTENER_PORT=5022 , LISTENER_IP = ALL )
FOR
DATABASE_MIRRORING
( AUTHENTICATION = CERTIFICATE HOST_B_cert , ENCRYPTION = REQUIRED ALGORITHM AES , ROLE = ALL );

--备机执行：
BACKUP CERTIFICATE HOST_B_cert TO FILE = 'D:\HOST_B_cert.cer';

08R201(WITNESS) 上运行下面的脚本：

--见证机执行
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '123456abc';
CREATE CERTIFICATE HOST_W_cert WITH SUBJECT = 'HOST_W certificate',
START_DATE = '11/08/2010',EXPIRY_DATE = '10/31/2099';

--见证机执行
CREATE ENDPOINT Endpoint_Mirroring
STATE = STARTED
AS
TCP ( LISTENER_PORT=5022 , LISTENER_IP = ALL )
FOR
DATABASE_MIRRORING
( AUTHENTICATION = CERTIFICATE HOST_W_cert , ENCRYPTION = REQUIRED ALGORITHM AES , ROLE = ALL );

--见证机执行
BACKUP CERTIFICATE HOST_W_cert TO FILE = 'D:\HOST_W_cert.cer';

交换证书

将HOST_B_cert.cer和HOST_W_cert.cer拷贝到 08R202 机器的”D:\Cert“目录；

将HOST_A_cert.cer和HOST_W_cert.cer拷贝到 08R205 机器的”D:\Cert“目录；

将HOST_A_cert.cer和HOST_B_cert.cer拷贝到 08R201 机器的”D:\Cert“目录；

08R202(Master) 上运行下面的脚本：

--Master
CREATE LOGIN HOST_B_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_B_user FOR LOGIN HOST_B_login;
CREATE CERTIFICATE HOST_B_cert AUTHORIZATION HOST_B_user FROM FILE = 'D:\Cert\HOST_B_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_B_login];

CREATE LOGIN HOST_W_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_W_user FOR LOGIN HOST_W_login;
CREATE CERTIFICATE HOST_W_cert AUTHORIZATION HOST_W_user FROM FILE = 'D:\Cert\HOST_W_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_W_login];

08R205(Mirror) 上运行下面的脚本：

--Mirror
CREATE LOGIN HOST_A_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_A_user FOR LOGIN HOST_A_login;
CREATE CERTIFICATE HOST_A_cert AUTHORIZATION HOST_A_user FROM FILE = 'D:\Cert\HOST_A_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_A_login];

CREATE LOGIN HOST_W_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_W_user FOR LOGIN HOST_W_login;
CREATE CERTIFICATE HOST_W_cert AUTHORIZATION HOST_W_user FROM FILE = 'D:\Cert\HOST_W_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_W_login];

08R201(WITNESS) 上运行下面的脚本：

--WITNESS
CREATE LOGIN HOST_A_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_A_user FOR LOGIN HOST_A_login;
CREATE CERTIFICATE HOST_A_cert AUTHORIZATION HOST_A_user FROM FILE = 'D:\Cert\HOST_A_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_A_login];

CREATE LOGIN HOST_B_login WITH PASSWORD = '123abc!@#';
CREATE USER HOST_B_user FOR LOGIN HOST_B_login;
CREATE CERTIFICATE HOST_B_cert AUTHORIZATION HOST_B_user FROM FILE = 'D:\Cert\HOST_B_cert.cer';
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [HOST_B_login];

备份还原数据库

08R202(Master) 上备份数据库：

BACKUP DATABASE RepTest TO DISK='D:\temp\RepTest.bak'
BACKUP LOG RepTest TO DISK='D:\temp\RepTest.trn'

将备份文件拷贝到 08R205(Mirror) 上做还原（最好以SA帐号登录，使得数据库所有者为”SA“）：

--RESTORE
RESTORE DATABASE RepTest FROM DISK = N'D:\RepTest.bak'
WITH FILE = 1,
MOVE N'RepTest' TO N'D:\Data\RepTest.mdf',
MOVE N'RepTest_log' TO N'D:\Data\RepTest_log.ldf',
NORECOVERY, NOUNLOAD, STATS = 10
GO

RESTORE LOG RepTest FROM DISK ='D:\RepTest.trn' WITH NORECOVERY

建立镜像

在08R205(Mirror) 上执行：

--Mirror
ALTER DATABASE RepTest SET PARTNER = 'TCP://192.168.56.102:5022';

在 08R202(Master)上执行：

ALTER DATABASE RepTest SET PARTNER = 'TCP://192.168.56.105:5022';

ALTER DATABASE RepTest SET WITNESS = 'TCP://192.168.56.101:5022';

ALTER DATABASE RepTest SET SAFETY FULL

到此，镜像已经建立完成。

配置Replication（事务型复制）

Replicaiton不做具体的搭建过程，只做几点说明：

1. 08R202和08R205都需要搭建到08R203的Distribution；

2. 08R202和08R205上的发布库的所有者必须为“SA”，否则切换会出现如下错误：The process could not execute 'sp_replcmds' on 'WIN-08R205'.

3. 08R203分发机上配置文件需要做如下修改（配置故障转移Partner）：

--配置复制故障转移参数
--查看代理配置，在分发服务器运行
exec sp_help_agent_profile
--Agent_Type含义
--1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent;
--4 = Merge Agent; 9 = Queue Reader Agent.
--对于事务复制，需查看Agent_Type=1,2的Profile_id

--对于事务复制，需要配置快照代理(Snapshot Agent)和日志读取代理(Log Reader Agent)
exec sp_add_agent_parameter @profile_id = 1,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'WIN-08R205'--镜像服务器名称

exec sp_add_agent_parameter @profile_id = 2,
@parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'WIN-08R205'--镜像服务器名称

修改完成后，记得重启Agent服务，使之生效。

4. 从08R202创建到08R204的同步链。

模拟故障转移并观察结果

1. 暂停08R202的SQLServer服务；

2. 到08R205上观察镜像和同步链是否转移过去了；

3. 如果同步链正常，修改某个表中的数据，看是否能同步到08R204上；

4. 重新启动08R202的SQLServer服务，看其是否成为了镜像机；

5. 如果一起都正常，那恭喜啦，我们的测试成功。

本文链接

更改SQLServer实例默认字符集

2012-05-15T06:56:00Z

需求

安装数据库时，将字符集安装成了“SQL_Latin1_General_CP1_CI_AS”，现在需要将其更改为“Chinese_PRC_CI_AS”。

方法

重新生成系统数据库，然后还原配置信息。

局限

重新生成 master、model、msdb 和 tempdb 系统数据库时，将删除这些数据库，然后在其原位置重新创建。如果在重新生成语句中指定了新排序规则，则将使用该排序规则设置创建系统数据库。用户对这些数据库所做的所有修改都会丢失。例如，您在 master 数据库中的用户定义对象、在 msdb 中的预定作业或在 model 数据库中对默认数据库设置的更改都会丢失。

前期准备

在重新生成系统数据库之前执行下列任务，以确保可以将系统数据库还原至它们的当前设置。

记录所有服务器范围的配置值。
SELECT * FROM sys.configurations;
记录所有应用到 SQL Server 实例和当前排序规则的 Service Pack 和修补程序。重新生成系统数据库后必须重新应用这些更新。
SELECT
SERVERPROPERTY('ProductVersion ') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ResourceVersion') AS ResourceVersion,
SERVERPROPERTY('ResourceLastUpdateDateTime') AS ResourceLastUpdateDateTime,
SERVERPROPERTY('Collation') AS Collation;

记录系统数据库的所有数据文件和日志文件的当前位置。重新生成系统数据库会将所有系统数据库安装到其原位置。如果已将系统数据库数据文件或日志文件移动到其他位置，则必须再次移动这些文件。
SELECT name, physical_name AS current_file_location
FROM sys.master_files
WHERE database_id IN (DB_ID('master'), DB_ID('model'), DB_ID('msdb'), DB_ID('tempdb'));

如果将 SQL Server 的实例配置为复制分发服务器，请找到该分发数据库的当前备份。
确保您有重新生成系统数据库的相应权限。必须是 sysadmin 固定服务器角色的成员才能执行此操作。有关详细信息，请参阅服务器级别角色。

将原数据库的帐号、JOB等与系统数据库相关的信息全部备份起来（可以先生成相应的脚本），分离掉所有用户库。

重新生成系统数据库

运行下面的命令就可重建数据库（根据您的系统，需要做相应的修改；D:/Setup 是数据库安装文件所在的路径）

D:/Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER/SQLSYSADMINACCOUNTS=Administrators /SAPWD=XXXX /SQLCOLLATION=Chinese_PRC_CI_AS

参数说明:

参数名称	说明
/QUIET 或 /Q	指定在没有任何用户界面的情况下运行安装程序。
/ACTION=REBUILDDATABASE	指定安装程序将重新创建系统数据库。
/INSTANCENAME=InstanceName	SQL Server 实例的名称。对于默认实例，请输入 MSSQLSERVER。
/SQLSYSADMINACCOUNTS=accounts	指定要添加到 sysadmin 固定服务器角色中的 Windows 组或单个帐户。指定多个帐户时，请用空格将帐户隔开。例如，请输入 BUILTIN\Administrators MyDomain\MyUser。当您在帐户名称内指定包含空格的帐户时，用双引号将该帐户引起来。例如，输入 NT AUTHORITY\SYSTEM。
[ /SAPWD=StrongPassword ]	指定 SQL Server sa 帐户的密码。如果实例使用混合身份验证（SQL Server 和 Windows 身份验证）模式，则此参数是必需的。安全说明 sa 帐户是一个广为人知的 SQL Server 帐户，并且经常成为恶意用户的攻击目标。因此，为 sa 登录名使用强密码非常重要。不要为 Windows 身份验证模式指定此参数。
[ /SQLCOLLATION=CollationName ]	指定新服务器级排序规则。此参数可选。如果没有指定，则使用服务器的当前排序规则。重要提示更改服务器级排序规则不会更改现有用户数据库的排序规则。默认情况下，所有新创建的用户数据库都将使用新排序规则。有关详细信息，请参阅设置或更改服务器排序规则。

安装程序完成后，将显示如下信息，（你也可以检查Summary.txt 日志文件以验证重新生成过程是否成功完成。此文件位于C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Logs）。

检查和修复

系统数据库恢复完成后，先检查一下字符集是否按要求恢复了：

字符集更改完成后，我们还需要附加上用户数据库，将原来的帐号和JOB等信息以及配置信息做修复，还需要修复孤立帐号等。

附加说明

如果您只需要更改某个用户数据库的字符集，非常简单：

--修改数据库字符集

alterdatabase DBName collate Chinese_PRC_CI_AS

注意

以上恢复是在SQLServer2008R2版本上面完成的，不同的版本您可能需要做一些修改，另外此方法存在一定的风险（主要是在重建数据库阶段），产品环境

最好还是重新安装数据库。

本文链接

SQLServer资源调控器--自由分配您的资源

2012-05-07T13:51:00Z

很早之前就有朋友问过我，能否按业务的优先等级分配SQLServer的资源，使得不同的应用能得到不同的响应，SQLServer2008之前对这个需求貌似没有什么

解决方法，不过从SQLServer2008开始，这个需求就变得很简单了，SQLServer直接就为我们提供了按用户的要求分配资源的能力，下面我们就来介绍这个功能。

SQLServer资源调控器分成三个部分：资源池、负载组和分类器函数；资源池为我们提供了将资源（CPU、Memory等）划分到不同的载体中，负载组承载负载并

将这些负载映射到资源池，分类器函数将不同的会话映射到不同的负载组中。

资源池：

08提供了两种预先定义好的资源池

内部池：内部池只用于SQLServer数据库引擎，系统管理员不能改变和设置；

默认池：默认池用于没有分配资源池的各种负载，因此，如果你不指定资源调控器，全部负载将使用默认池。默认池也不能改变或删除，但是可以修改它的资源上

下限。

资源池上下限要求：

各个资源池的下限之和不能超过100%，因为SQLServer会尽力满足每个下限；

上限可以设置为下限和100%之间的任意值。

以下是关于资源池的基本操作：

--创建资源池
Create Resource Pool UserQueries with(max_cpu_percent=100)

--删除资源池
drop Resource Pool UserQueries

负载组：

负载组可以让管理员轻松地监控资源使用情况，在不同的资源池之间移动某类负载。

负载组被映射到资源池上，一个资源池可以有零个或更多负载组，一个负载组为一组用户会话提供一个桶。

--创建负载组
Create WorkLoad Group DailyExecReports USING UserQueries;

--删除负载组
drop WorkLoad Group DailyExecReports

分类器函数：

分类器函数将接入的会话分类，并为会话的请求和查询分配一个负载组。你可以根据连接串中的任意属性（IP地址/应用程序名、用户名等）分别分配组。

按以下条件分配组：

一个用户接入并使用SAP_Login登录名，则为他分配SAPUsers负载组；
一个用户接入程序名是SSMS，则让它成为AdhocAdmin负载组的一员；
一个用户是ReportUsers组一员，则让它成为DaliyExecReports负载组一员；
一个用户以共享内存连接，并在NightlyAdmin用户组中，则分配NightlyMaintanceTask组。

--创建资源池
Create Resource Pool AdminQueries with(max_cpu_percent=100)
Create Resource Pool UserQueries with(max_cpu_percent=100)

--创建负载组
Create WorkLoad Group NightlyMaintenanceTasks USING AdminQueries;
Create WorkLoad Group AdhocAdmin USING AdminQueries;
Create WorkLoad Group SAPUsers USING UserQueries;
Create WorkLoad Group DailyExecReports USING UserQueries;

--创建分类器函数
USE master
GO
create FUNCTION class_func_1()
Returns sysname with schemabinding
begin
Declare @val sysname
--Handle workload groups defined by login names
IF SUSER_SNAME()='SAP_Login'
begin
SET @val='SAPUsers';
Return @val;
end

IF APP_NAME() like 'Microsoft SQL Server Management Studio%'
begin
Set @val='AdhocAdmin';
Return @val;
end

IF IS_MEMBER('ReportUsers')=1
begin
Set @val='DailyExecReports';
Return @val;
end

IF CONNECTIONPROPERTY('net_transport')='Shared memory' and IS_MEMBER('NightlyAdmin')=1
begin
Set @val='NightlyMaintenanceTasks';
Return @val;
end

Return @val;
end

绑定分类器函数：

--将分类器函数绑定到资源调控器上
Alter Resource Governor With(Classifier_Function=dbo.class_func_1);

启用和禁用分类器函数：

--启用
ALter Resource Governor Reconfigure;
--禁用
ALTER RESOURCE GOVERNOR DISABLE;

测试：

现在我们分别使用SAP_Login和sysadmin用户调用此脚本

--测试脚本(分别使用SAP_Login和sysadmin用户调用此脚本）
set nocount on
Declare @i int=100000000;
Declare @s varchar(100),@count int;
While @i>0
begin
Select @s=@@VERSION;
select @count=COUNT(0) from sys.sysobjects
set @i=@i-1;
end

通过性能计数器查看资源分配：

我们可以选择性能计数器的资源统计：SQL Server:Resource Pools Stats;

我们先将资源池按一比一的比例分配：

Create Resource Pool AdminQueries with(max_cpu_percent=100)
Create Resource Pool UserQueries with(max_cpu_percent=100)

运行测试脚本，显示的CPU利用率图如下

现在将资源分配做如下调整：

Create Resource Pool AdminQueries with(max_cpu_percent=10)
Create Resource Pool UserQueries with(max_cpu_percent=90)

再次运行测试脚本，显示的CPU利用率图如下

可以看到，当我们调整资源后，两个Session中运行同样的脚本，它们所使用的资源差别很大，这样就达到了根据不同的应用分配不同的资源的目的。

DMV查看资源池：

--查看Session所在的资源池
select s.session_id,s.login_name ,s.program_name,s.group_id,g.name
from
sys.dm_exec_sessions s join sys.dm_resource_governor_workload_groups g
on s.group_id=g.group_id
where session_id>50

--查看资源池情况
select * from sys.dm_resource_governor_resource_pools

可以看到，我们创建的两个资源池（还有两个是系统资源池和默认资源池），而且不同的Session对应到了不同的资源池中。

本文链接

SQL Server dump 介绍（转载）

2012-04-28T08:17:00Z

转储的英文单词是dump，但这边我们说的dump不是SQL Server本身的DUMP备份命令，而是指通过sqldumper.exe中的dump。那什么是dump呢，dump指的是将某种

内容转换为另外一种更具可读性的方式。在ORACLE中，有专门的dump命令可以dump出数据文件等的内容，其trace也相当于另外一种dump。通过dump，我们便可以了解

整个系统的运行原理。

SQL Server这方面的资料很少，当然，这也符合了微软不开源的策略。不过这几年来，关于这方面的资料比较多了，通过google可以获得相关的内容。

最早对此感兴趣的是碰到了很多人经常问的.mdmp文件，mdmp的叫mini dmp，也可以叫memory dmp，这是由于SQL Server 在运行过程中，遇到了一些bug或者错误而进行

转储以便记录出错信息的文件。一般对这类文件的处理，都是建议打包后提交给微软分析的。在无法获得微软帮助的情况，就需要自己对此类文件进行分析了，然后找出问题原因，

从而进行解决。

一、SQLDumper.exe介绍

前面介绍了SQL Server 会在运行时自动产生一些dump文件，我们也可以手工产生dump文件，产生dump文件的方式，就是通过Sqldumper来进行的。

自 SQL Server 2000 Service Pack 3 (SP3) 起，Microsoft SQL Server 2000 中开始附带 Sqldumper.exe。Sqldumper.exe 可根据任一 Microsoft Windows 应用程序的

需要生成转储文件。Sqldumper.exe不仅可以转储SQL Server，还可以转储其他的windows application。

我使用的环境是SQL Server 2008，因此SQLDumper位于C:\Program Files\Microsoft SQL Server\100\Shared下，我们可以运行SQLDumper /? 查看其使用方法

C:\Program Files\Microsoft SQL Server\100\Shared>SqlDumper.exe /?
Usage: SqlDumper.exe [ProcessID [ThreadId [Flags[:MiniDumpFlags] [SqlInfoPtr [DumpDir [ExceptionRecordPtr [ContextPtr [E
xtraFile]]]]]]]] [-I<InstanceName>] [-S<ServiceName>][-remoteservers:[print|dump|freeze|resume|remote:guid\dumporigin\si
gnature\localId\port\operationType]]
Flags:
dbgbreak = 0x0001
nominidump = 0x0002
validate_image = 0x0004
referenced_memory = 0x0008
all_memory = 0x0010
dump_all_threads = 0x0020
match_file_name = 0x0040
no_longer_used_flag = 0x0080
verbose = 0x0100
wait_at_exit = 0x0200
send_to_watson = 0x0400
defaultflags = 0x0800
maximumdump = 0x1000
mini_and_maxdump = 0x2000
force_send_to_watson= 0x4000
full_filtered_dump = 0x8000

MiniDumpFlags:
Normal = 0x0000
WithDataSegs = 0x0001
WithFullMemory = 0x0002
WithHandleData = 0x0004
FilterMemory = 0x0008
ScanMemory = 0x0010
WithUnloadedModules = 0x0020
WithIndirectlyReferencedMemory = 0x0040
FilterModulePaths = 0x0080
WithProcessThreadData = 0x0100
WithPrivateReadWriteMemory = 0x0200
WithoutOptionalData = 0x0400
WithFullMemoryInfo = 0x0800
WithThreadInfo = 0x1000

从上面的命令可以看出，要想对某一application进行dump，需要先找出其pid(processes id)，然后加上一些Flags的控制标识来控制dump内容。

比如，我现在想对我的SQL Server 进行dump，先找到SQL Server 的pid 为900，想dump所有的内存信息，那就可以用下面的命令来进行：
C:\Program Files\Microsoft SQL Server\100\Shared>SqlDumper.exe 900 0x0010
其中，0x0010 表示all_memory，这样，在C:\Program Files\Microsoft SQL Server\100\Shared目录下会产生SQLDmprnnn.mdmp的文件，这就是转储文件(.mdmp)。

以下是几个比较常见的dump 标识：

0x0120 - Minidump，这个flag只dump 一个Process的堆栈和载入模块的信息，这是最小的转储方式，也是SQL Server自动产生dump文件的方式。

0x01100 – Full Dump，这个flag会转储Process的整块信息，如果在64位的系统上，其文件大小还是很大的。

0x8100 – Filtered Dump,这个flag用来转储用于于其他服务器用途（包括过程缓存）的内存信息

二、SQL Server方式的DUMP

使用Sqldumper只是手工产生dump文件的一种方式，当然，产生dmp文件的方式还是很多的，SQL Server内部也提供了这样的工具。主要是DBCC STACKDUMP 和dbcc dumptrigger 这

两个命令。当然还可以通过TraceFlag来控制是否产生dmp文件或者遇到什么错误时才产生文件。比如，我们想产生一个Full Dump，必须打开Trace Flag 2544 和 2546

dbcc traceon(2544, -1)

go

dbcc traceon(2546, -1)

go

dbcc stackdump

如果想让SQL Server 只针对某个错误而产生转储文件，可以使用dbcc dumptrigger，下面是一个例子

dbcc traceon(2544, -1)
go
dbcc traceon(2546, -1)
go
--设置dump的触发器为错误802
dbcc dumptrigger('set', 802)
go
-- 查看当期的dump触发器内容
dbcc traceon(3604, -1)
go
dbcc dumptrigger('display')
go
dbcc traceoff(3604, -1)
go
-- 关闭当期的dump触发器。
dbcc dumptrigger('clear', 802)
go

网上有听说可以使用2542 Trace Flag 来控制mdmp文件的产生，至今仍没有去试，有试过的朋友可以分享下。启用2542 TF，在启动参数后面添加 -T2542就是了。

三、分析mdmp文件的一些知识说明

以上只是介绍了mdmp的产生，以及如何自己手工产生mdmp文件，但如何对mdmp文件进行分析才是重点。曾经对其进行了一些分析，但道行有限，能获得的信息不多。把如何分析

mdmp文件的过程分享出来，希望更厉害的人能从中找到一些SQL Server的运行原理。

说到分析mdmp文件，也顺便提一个人，就是The guru guide系列的作者Ken Henderson(http://www.amazon.com/Ken-Henderson/e/B001IOFJL2/ref=ntt_athr_dp_pel_pop_1)，他的

《The Guru's Guide to Transact-SQL》就是中文版的《T-SQL权威指南》，其他的两本貌似没有找到中文版。他在Guru Guide 里面常常会介绍一些微软未公开的内容

(undocument commands)，而《The Guru's Guide to SQL Server Architecture and Internals》
就是介绍了SQL Server 2000的体系结构很是深入的一本书。可惜其在2008年已经英年早逝了(http://sqlblog.com/blogs/kalen_delaney/archive/2008/01/29/ken-henderson.aspx)，不然肯定能够提供更多关于SQL Server Interal的内容了。

1，调试

由于SQL Server 也是在windows平台是运行的一款程序，有问题时，把它当成一款普通的windows程序来进行调试就行了。在windows上，有两方面的调试，一个是内核模式调试，

一个是用户模式调试。内核调试是针对Windows操作系统进行调试的，反应windows OS内部和硬件设备的运行。用户模式的调试就是对应用程序进行调试，因为应用程序就是运行在

用户模式上的。二者的调试是不同的，这边就不做过多的介绍，有疑问，就google吧。

调试还有另外一个区别：是在程序运行时对其调试(live-debugging)，还是读取mdmp分析调试(post-mortem debugging)。这二者也是不一样的。在live-debugging时会使程序挂起

，然后设置bp(break point)，观察程序的运行行为。这边主要介绍post-mortem debugging.

2，windbg

要调试，当然得有工具，这个工具就是windbg，其主页为：

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

安装完成后，除了有图形界面的调试工具(windbg)，还会有命令行的调试工具(kd,cdb,ntsd)。

在调试过程中，我们最常见的是分析线程(thread)的堆栈(stack)的跟踪信息。因为在windows平台上，application是以process来运行的，而一个process又包含了thread，thread

才是真正在运行一些函数功能。我们可以通过select spid,kpid from sysprocesses 来看运行SQL Server的线程信息，也可以通ProcessExplorer
spidd kpid
------ ------
51 0
52 644

在ProcessExplorer里的查看如下，可以看到ProcessExplorer就提供了查看堆栈的功能，但仍有一些像 10 sqlservr.exe+0x58d36b的内容无法查看。

从上图可以看到，stack的内容格式一般如下：

MyModule!Func03
MyModule!Func01

从底往上看，Func03是在Func01之后执行的。通过windbg，还会看到一些指针信息(Child-sp：Stack Pointer)和地址信息(RetAddr：Return Address)

Child-SP RetAddr Call Site
00000000`09cbe9e8 00000000`777b2f60 ntdll!NtSignalAndWaitForSingleObject+0xa
00000000`09cbe9f0 00000000`00bdc99e kernel32!SignalObjectAndWait+0x110
00000000`09cbeaa0 00000000`00bc4575 sqlservr+0x1c99e
00000000`09cbed40 00000000`00bc3ea8 sqlservr+0x4575
00000000`09cbed80 00000000`00bdcfad sqlservr+0x3ea8
00000000`09cbf370 00000000`01139d9c sqlservr+0x1cfad
00000000`09cbf430 00000000`032b34c7 sqlservr+0x579d9c
00000000`09cbf650 00000000`00bd2abb sqlservr!TlsGetValueForMsxmlSQL+0x4706d7
00000000`09cbf6c0 00000000`00bd0fda sqlservr+0x12abb
00000000`09cbf7e0 00000000`00bd2665 sqlservr+0x10fda
00000000`09cbf870 00000000`0117abb0 sqlservr+0x12665
00000000`09cbf8e0 00000000`0117c4b0 sqlservr+0x5babb0
00000000`09cbf9a0 00000000`0117a060 sqlservr+0x5bc4b0
00000000`09cbf9d0 00000000`0117a9ef sqlservr+0x5ba060
00000000`09cbfa60 00000000`734937d7 sqlservr+0x5ba9ef
00000000`09cbfaf0 00000000`73493894 MSVCR80!endthreadex+0x47
00000000`09cbfb20 00000000`7775f56d MSVCR80!endthreadex+0x104
00000000`09cbfb50 00000000`77893281 kernel32!BaseThreadInitThunk+0xd
00000000`09cbfb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21

要看sqlservr+0x579d9c 这样的内容，需要使用symbol来map这些16进制的值所表示的函数。使用symbol后，会得到下面的形式的内容。

Child-SP RetAddr Call Site
00000000`09cbe9e8 00000000`777b2f60 ntdll!NtSignalAndWaitForSingleObject+0xa
00000000`09cbe9f0 00000000`00bdc99e kernel32!SignalObjectAndWait+0x110
00000000`09cbeaa0 00000000`00bc4575 sqlservr!SOS_Scheduler::SwitchContext+0x84e
00000000`09cbed40 00000000`00bc3ea8 sqlservr!SOS_Scheduler::SuspendNonPreemptive+0xc5
00000000`09cbed80 00000000`00bdcfad sqlservr!EventInternal<Spinlock<149,1,0> >::Wait+0x428
00000000`09cbf370 00000000`01139d9c sqlservr!ResQueueBase::Dequeue+0x19d
00000000`09cbf430 00000000`032b34c7 sqlservr!CheckpointLoop+0x1aa
00000000`09cbf650 00000000`00bd2abb sqlservr!ckptproc+0x47
00000000`09cbf6c0 00000000`00bd0fda sqlservr!SOS_Task::Param::Execute+0x11b
00000000`09cbf7e0 00000000`00bd2665 sqlservr!SOS_Scheduler::RunTask+0xca
00000000`09cbf870 00000000`0117abb0 sqlservr!SOS_Scheduler::ProcessTasks+0x95
00000000`09cbf8e0 00000000`0117c4b0 sqlservr!SchedulerManager::WorkerEntryPoint+0x110
00000000`09cbf9a0 00000000`0117a060 sqlservr!SystemThread::RunWorker+0x60
00000000`09cbf9d0 00000000`0117a9ef sqlservr!SystemThreadDispatcher::ProcessWorker+0x12c
00000000`09cbfa60 00000000`734937d7 sqlservr!SchedulerManager::ThreadEntryPoint+0x12f
00000000`09cbfaf0 00000000`73493894 MSVCR80!endthreadex+0x47
00000000`09cbfb20 00000000`7775f56d MSVCR80!endthreadex+0x104
00000000`09cbfb50 00000000`77893281 kernel32!BaseThreadInitThunk+0xd
00000000`09cbfb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21

在这个例子中，我们发现有sqlservr!CheckpointLoop+0x1aa 这个函数调用的信息，这就是我们说的checkpoint的实际运行信息了。通过select * from sys.dm_exec_requests
可以看出是哪个spid在运行checkpoint。

从上面也可以看出Call Site的格式一般如下：
<module_name>!<function call>
<module_name>!<class_name>::<method/function call>

四、使用windbg

在了解上述知识后，就可以使用windbg来进行分析了。

1，windbg环境的配置

到微软的网站下载windbg后直接安装，安装完成后，需要配置symbols的path，打开windbg，File --> Symbols File Path 在弹出的对话框输入

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

其中c:\symbols是本地硬盘的文件夹，在使用时，windbg会到http://msdl.microsoft.com/download/symbols下载相关的symbols，也可以自己手工下载相关操作系统的symbols。

配置好，可以使用.reload命令来强制下载某个symbols，如：

.reload /f sqlservr.exe

具体的命令可以参考windbg的帮助文档。

2，打开mdmp文件

打开windbg，File --> Open Crash Dump，选择mdump文件，在弹出的对话框里点击yes

3，分析mdmp

在下面的对话框输入 ~ 会出现线程的信息

0:000> ~
. 0 Id: 384.608 Suspend: 1 Teb: 7ffdd000 Unfrozen
1 Id: 384.698 Suspend: 1 Teb: 7ffda000 Unfrozen
2 Id: 384.6a8 Suspend: 1 Teb: 7ffd9000 Unfrozen
3 Id: 384.6a4 Suspend: 1 Teb: 7ffd8000 Unfrozen
4 Id: 384.6b0 Suspend: 1 Teb: 7ffd7000 Unfrozen
5 Id: 384.6ac Suspend: 1 Teb: 7ffd6000 Unfrozen
6 Id: 384.6c8 Suspend: 1 Teb: 7ffd5000 Unfrozen
7 Id: 384.6dc Suspend: 1 Teb: 7ffd4000 Unfrozen
8 Id: 384.6e0 Suspend: 1 Teb: 7ffd3000 Unfrozen
9 Id: 384.108 Suspend: 1 Teb: 7ff9f000 Unfrozen
10 Id: 384.6e8 Suspend: 1 Teb: 7ff9e000 Unfrozen
11 Id: 384.6e4 Suspend: 1 Teb: 7ff9d000 Unfrozen
12 Id: 384.604 Suspend: 1 Teb: 7ff9c000 Unfrozen
13 Id: 384.714 Suspend: 1 Teb: 7ff9b000 Unfrozen
14 Id: 384.718 Suspend: 1 Teb: 7ff9a000 Unfrozen
15 Id: 384.71c Suspend: 1 Teb: 7ff99000 Unfrozen
16 Id: 384.720 Suspend: 1 Teb: 7ff98000 Unfrozen
17 Id: 384.728 Suspend: 1 Teb: 7ffdc000 Unfrozen
18 Id: 384.730 Suspend: 1 Teb: 7ff97000 Unfrozen
19 Id: 384.74c Suspend: 1 Teb: 7ff96000 Unfrozen
20 Id: 384.784 Suspend: 1 Teb: 7ff95000 Unfrozen
21 Id: 384.788 Suspend: 1 Teb: 7ff94000 Unfrozen
22 Id: 384.1e0 Suspend: 1 Teb: 7ff93000 Unfrozen
23 Id: 384.284 Suspend: 1 Teb: 7ff92000 Unfrozen
24 Id: 384.280 Suspend: 1 Teb: 7ff91000 Unfrozen
25 Id: 384.23c Suspend: 1 Teb: 7ff8f000 Unfrozen
26 Id: 384.3d0 Suspend: 1 Teb: 7ff8e000 Unfrozen
27 Id: 384.3d4 Suspend: 1 Teb: 7ff8d000 Unfrozen
28 Id: 384.3d8 Suspend: 1 Teb: 7ff8c000 Unfrozen
29 Id: 384.204 Suspend: 1 Teb: 7ff8b000 Unfrozen
30 Id: 384.43c Suspend: 1 Teb: 7ff8a000 Unfrozen
31 Id: 384.450 Suspend: 1 Teb: 7ff89000 Unfrozen
32 Id: 384.454 Suspend: 1 Teb: 7ff88000 Unfrozen
33 Id: 384.458 Suspend: 1 Teb: 7ff87000 Unfrozen
34 Id: 384.45c Suspend: 1 Teb: 7ff86000 Unfrozen
35 Id: 384.464 Suspend: 1 Teb: 7ff84000 Unfrozen
36 Id: 384.44c Suspend: 1 Teb: 7ff83000 Unfrozen
37 Id: 384.1e8 Suspend: 1 Teb: 7ffdb000 Unfrozen
38 Id: 384.1cc Suspend: 1 Teb: 7ff82000 Unfrozen
39 Id: 384.1684 Suspend: 1 Teb: 7ff80000 Unfrozen
40 Id: 384.c38 Suspend: 1 Teb: 7ff90000 Unfrozen
41 Id: 384.1048 Suspend: 1 Teb: 7ff85000 Unfrozen
42 Id: 384.140c Suspend: 1 Teb: 7ff7f000 Unfrozen
43 Id: 384.a18 Suspend: 1 Teb: 7ff81000 Unfrozen

在我的这个例子中，我的spid在循环运行一个select命令，从sysprocesses中，可以看到spid对应的kpid是488

spid kpid
51 0
52 488

488转化为16进制刚好为1e8 ，对应的序号是37。

那我们如果想看线程37的内容，可以先使用 ~37s命令切换到线程37的上下文中

0:000> ~37s
eax=00000000 ebx=3f20f344 ecx=1f8dcf08 edx=00000001 esi=000009b5 edi=00000000
eip=7c92e514 esp=3f20f238 ebp=3f20f29c iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297
ntdll!KiFastSystemCallRet:
7c92e514 c3 ret

看起来是CPU的寄存器信息，可惜这些还看不太懂，不然可以更深入了。

接着用k命令，查看具体的函数调用信息

0:037> k
ChildEBP RetAddr
3f20f234 7c92df5a ntdll!KiFastSystemCallRet
3f20f238 7c8025db ntdll!ZwWaitForSingleObject+0xc
3f20f29c 7c802542 kernel32!WaitForSingleObjectEx+0xa8
3f20f2b0 011e7ced kernel32!WaitForSingleObject+0x12
3f20f324 011e7ddb sqlservr!Np::StatusWriteNoComplPort+0x9f
3f20f354 011e7ea2 sqlservr!SNIStatusWriteNoComplPort+0x82
3f20f374 012a8ae0 sqlservr!TDSSNIClient::WriteStatus+0x6a
3f20f4a0 0153d30c sqlservr!write_data+0x1a6
3f20f4d0 0117492e sqlservr!flush_buffer+0xdf
3f20f6a0 015490b6 sqlservr!CKatmaiTds::SendRowImpl+0x2faf
3f20f6ac 01532f0d sqlservr!CValOdsRow::SetDataX+0x29
3f20f6bc 01532d8b sqlservr!SetMultData+0x1e
3f20f734 0154962f sqlservr!CEs::GeneralEval4+0xd0
3f20f740 01547825 sqlservr!CEs::Eval+0x13
3f20f7f8 015499af sqlservr!CXStmtQuery::ErsqExecuteQuery+0x409
3f20f85c 015401c3 sqlservr!CXStmtSelect::XretExecute+0x268
3f20f8f8 01540cc0 sqlservr!CMsqlExecContext::ExecuteStmts<1,1>+0x28d
3f20f9e0 01540686 sqlservr!CMsqlExecContext::FExecute+0x70e
3f20fa84 0153cf8c sqlservr!CSQLSource::Execute+0x598
3f20fc08 01539f79 sqlservr!process_request+0x2f0

从下面的内容，可以看出几点(个人观点:) )

3f20f354 011e7ea2 sqlservr!SNIStatusWriteNoComplPort+0x82
3f20f374 012a8ae0 sqlservr!TDSSNIClient::WriteStatus+0x6a
3f20f4a0 0153d30c sqlservr!write_data+0x1a6
3f20f4d0 0117492e sqlservr!flush_buffer+0xdf

3f20f7f8 015499af sqlservr!CXStmtQuery::ErsqExecuteQuery+0x409
3f20f85c 015401c3 sqlservr!CXStmtSelect::XretExecute+0x268
3f20f8f8 01540cc0 sqlservr!CMsqlExecContext::ExecuteStmts<1,1>+0x28d
3f20f9e0 01540686 sqlservr!CMsqlExecContext::FExecute+0x70e

从底往上看，可以看到这是一个select动作，进行select时，先对内存的一些缓存进行清除(flush_buffer)，接着便是写入数据(write_data),然后再发送写状态(TDSSNIClient::WriteStatus),由于一直循环所以会有写未完成的提示(SNIStatusWriteNoComplPort)。这也基本符合一个select的动作。

如果遇到错误时，在函数调用中一般会抛出raiseerror等内容，类似如下：

00000000`220ce2d0 00000000`013a3d41 sqlservr!ex_raise2+0xcdd8bf

00000000`220ce630 00000000`02deb8ce sqlservr!ex_raise+0x51

这时，基本可以判断出现问题的原因了。

3，其他

windbg的功能是很强大的，是通往sql server内部一个强大工具。要想了解的话，估计得好好研究下<windows internal>，有兴趣的可以自行深入。

http://topic.csdn.net/u/20101024/16/48C19360-5E68-4A59-BD39-0FFEE8157E45.html

本文链接

SQLServerDBA十大必备工具---让生活轻松点

2012-04-25T04:14:00Z

曾经和一些DBA和数据库开发人员交流时，问他们都用过一些什么样的DB方面的工具，大部分人除了SSMS和Profile之外，基本就没有使用过其他工具了；

诚然，SSMS和Profile足够强大，工作的大部分内容都能通过它们搞定，但是MS、第三方公司甚至是个人开发者为SQLServer提供了很多其他的工具，如果你

能充分的掌握这些工具，无疑会给我们数据库的管理、优化、测试和排错节省大量的时间和精力，下面就来介绍除SSMS和Profile之外的其他有用的工具。

NO1: PD（PowerDesigner）

功能：SysBase公司提供的数据库设计工具，功能很强大，是做数据库设计时必备的工具；

下载：http://www.3ddown.com/soft/14524.htm

NO2: Log Explorer

功能：数据库日志读取工具，主要用来恢复误操作的数据（目前只支持到2005版本），详见：

http://blog.csdn.net/jinjazz/archive/2008/05/19/2459692.aspx ;

下载地址：http://www.pc6.com/softview/SoftView_57657.html

NO3：Tuning Advisor

功能：优化顾问，会根据数据库的运行情况，提示您做相关的优化（可靠性不是太高，需要自行判断）;

下载：SQLServer自带

NO4：SSMSTools

功能：SSMS工具的一个插件，能提供格式化代码、追溯历史等功能（通过它，也许你可以开发自己的插件）；

下载: http://www.ssmstoolspack.com/

NO5: DBDiff & TableDiff

功能：第一个是比较两个数据库结构的差异，第二个可用来比较表中数据的差异（而且能生成相关的脚本）；

下载：http://opendbiff.codeplex.com/

NO6：PAL Tool

功能：Performance Analysis of Logs，Perfmon日志分析工具；

下载：http://pal.codeplex.com/

NO7：RML

功能：这个工具非常强大，下图展示了完成安装后它的四个主要功能组件；ReadTrace工具能读取数据库的Profile跟踪文件，并生成报告；Ostress能将ReadTrace

生成的文件重播，而且还可以对数据库做压力测试；ORCA能保证重报时，按照事件发生的顺序播放；Reporter能将ReadTrace后的内容通过报表的形式展现，相当

的有用。

下载：http://support.microsoft.com/kb/944837

NO8：SqlNexus

功能：先通过SQLServer自带的SQLdiag.exe工具收集信息，然后再用SqlNexus分析这些信息，它是前面一些工具的整合，为数据库管理人员寻找SQLServer服务器

的性能瓶颈和排查故障提供了相当强大的支持（MS工程师很多都用这个哦，买技术支持的朋友们有木有经历过MS要求你开启SQLDiag，然后将收集的数据回传给他们

的；现场支持时，是不是也开启SQLDiag收集数据，然后就出来了服务器性能报告，有木有；所以掌握它，1k/时的定期服务器检查技术支持费用可以省了）；

下载：http://sqlnexus.codeplex.com/

NO9：SQLIO & SQLIOSim

功能：磁盘IO压力测试工具，SQLIO主要是模拟随机或者顺序的方式来测试磁盘IO的性能；SQLIOSim是模拟SQLServer的行为来测试IO性能；

下载：http://support.microsoft.com/kb/231619

NO10:SqlMonitor & SSBDiagnose

功能：SqlMonitor是监控Replication和Mirror的必会工具，SSBDiagnose是测试SSB配置的工具；

下载：SQLServer自带

本文链接

数据库架构的升级和变更

2012-03-23T01:54:00Z

SQLServer2008在数据的高安全、高性能、高可用方面的技术已经比较成熟，这些技术和方案都是随着很多公司的业务和数据访问压力的增加而不断的升级和

变迁的，同时经历了方方面面的考验，证明了它们都是成熟可靠的，下面就这方面的技术方案和变迁过程来做一些分析。

阶段一：

裸奔时代：

优点：裸奔最大的好处就是简单，成本低。

缺点：一旦服务器出现问题，恢复起来比较麻烦；如果访问压力变大，服务器可能不堪重负。

阶段二：

单库+Mirror+BackUp方案：

说明：Mirror有两种方式，同步和异步；同步方式能保证主库和Mirror端数据的一致性，而且不需要使用企业版，但是对主库的性能影响也比较大；异步方式需要

企业版才支持，绝大部分时刻能保证数据的一致性，但是也有丢失小部分的数据可能，不过它主库的影响比较小。

优点：此方案对主库的数据提供了可靠的保护，一旦主库出现问题，从库能在比较短的时间内恢复，尤其是数据库很大时（从备份恢复需要的时间会很长），能尽

快的恢复业务使用，而且Mirror端能生成快照，能给实时性要求不高的业务使用。

缺点：Mirror会影响主库的部分性能（异步方式影响比较小），主库出现问题后，前端需要更改访问的IP地址（或者将从服务器的IP地址改成主服务器的IP地址），

还需要账号、权限和作业等信息迁移过去。

单库+Replication+ BackUp方案：

优点：Replication端可以提供给前段访问，可以将读操作放到从库，分担主库的部分压力，还能提供数据库的备份功能，不过这种备份很可能数据会有丢失。

缺点：不能提供安全的数据保护功能，对主库有一些性能影响。

阶段三：

单库+Replication+Mirror+BackUp方案：

优点：这种方案是前面两种方案的结合，既能够解决数据保护的问题，也能够提供读写分离的功能。

缺点：主库上既有Mirror又有Replication，这种方式对主库影响会比较大，而且实际证明，Mirror和Replication在同一台机器上部署，在一个出现问题时，

会对另一个造成影响。

阶段四：

Cluster（双A）+BackUp方案：

说明：图中矩形部分代表存储，两台服务器做了双A的群集。

优点：Cluster能确保其中的一个服务器出现问题时所有的数据和服务能切换到另外一台机器，切换的时间很短，能尽快的恢复业务访问。

缺点：双A群集一般要求配置比较好，价格比较高；因数据都存放在存储上，所以群集不能保护数据，一旦数据或者存储出现问题，需要从备份中恢复数据；

SQLServer的群集不能提供负载均衡的功能。

阶段五：

Cluster（双A）+Mirror+BackUp方案：

说明：双A群集再加两个服务器上库的Mirror保护。

优点：这个方案能对数据提供可靠的保护，无论是服务器故障还是存储故障，都能保证数据的安全，而且数据恢复的时间比较短。

缺点：Mirror会消耗主服务器的部分性能，多了两台Mirror机器，成本会增加，如果存储出现问题，快速恢复的方案是启用Mirror机器，后面可能需要重做群集。

阶段六：

Cluster（双A）+Mirror+BackUp+Replication+单分发方案：

说明：双A 群集，Mirror保护，单分发机器和读写分离方案。

优点：群集和Mirror能充分保护数据的安全，读写分离能提高系统整体的性能。

缺点：成本较高，单分发机存在单点故障，如果分发机器出现问题，将需要重建，此时读和写都将集中到主库，压力会比较大。

Cluster（双A）+Mirror+BackUp+Replication+双分发方案：

优点：与单分发机相比，没有单点故障，即使某台分发机出现问题，也能保证读写分离机制继续运行。

缺点：成本增加，维护方面更复杂。

阶段七：

Cluster（双A）+双存储+BackUp+Replication+双分发方案：

优点：双存储方案使得数据能得到有效的保护，而且避开了Mirror和Replication同时在主库运行对主服务器造成的影响，节省主服务器资源，而且恢复比较方便。

缺点：成本增加。

阶段八：

Cluster（双A）+双存储+BackUp+Replication+双分发+SSB异步方案：

此方式的主要优势是将数据流异步处理，缓解瞬时高流量主库的压力，因为此方案比较复杂，暂时不做说明，可以参考数据库架构。

阶段九：

拆分业务和数据、采用分布式数据库、使用能负载均衡集群功能的数据库等。

此文档大致描述了随公司的发展、服务器压力的增加，数据库架构方面的变迁阶段，当然我们应该根据公司的具体情况，选择性的采用其中的技术，也可能是

直接跳过某些阶段，而上更高效的方案（如果成本能够接受），因此技术和方案的选择应该根据实际情况，灵活应对。

本文链接

数据库系统异常排查之DMV

2012-03-12T06:36:00Z

数据库系统异常是DBA经常要面临的情景，一名有一定从业经验的DBA，都会有自己一套故障排查的方法和步骤，此文为为大家介绍一下通过系统

性能视图（SQLServer05以上版本）来排查系统异常的基本方法，希望能对大家有所帮助。

这里分两部分来介绍：

一. 从数据库连接情况来判断异常：

1. 首先我们来看一下目前数据库系统所有请求情况：

--request info
select s.session_id, s.status,db_name(r.database_id) as database_name,
s.login_name,s.login_time, s.host_name,
c.client_net_address,c.client_tcp_port,s.program_name,
r.cpu_time, r.reads, r.writes,c.num_reads,c.num_writes,
s.client_interface_name,
s.last_request_start_time, s.last_request_end_time,
c.connect_time, c.net_transport, c.net_packet_size,
r.start_time, r.status, r.command,
r.blocking_session_id, r.wait_type,
r.wait_time, r.last_wait_type, r.wait_resource, r.open_transaction_count,
r.percent_complete,r.granted_query_memory
from Sys.dm_exec_requests r with(nolock)
right outer join Sys.dm_exec_sessions s with(nolock)
on r.session_id = s.session_id
right outer join Sys.dm_exec_connections c with(nolock)
on s.session_id = c.session_id
where s.session_id >50
order by s.session_id

某台生产机运行情况：

这个查询将目前数据库中的所有请求都显示出来了，其中比较重要的有Status、Login_name、Host_Name，Client_Net_Address、Program_name

等，但是信息比较多，我们很难查看有什么异常，但是可以通过一图中红色圈的数字：441 初步判断连接数是否超过了平时的标准（很多时候系统异常是连接

数过多造成的，而连接数过多又是因为其他原因影响的）。

2. 哪个用户连接数最多：

--request info by user
select login_name,COUNT(0) user_count
from Sys.dm_exec_requests r with(nolock)
right outer join Sys.dm_exec_sessions s with(nolock)
on r.session_id = s.session_id
right outer join Sys.dm_exec_connections c with(nolock)
on s.session_id = c.session_id
where s.session_id >50
group by login_name
order by 2 desc

运行结果：

从图中我们可以很方便的看出用户连接数情况，如果我们的不同的功能是使用不同的的数据库账号的话，就能初步判断是哪部分功能可能出现了异常。

3. 哪台机器发起到数据库的连接数最多：

--request info by hostname
select s.host_name,c.client_net_address,COUNT(0) host_count
from Sys.dm_exec_requests r with(nolock)
right outer join Sys.dm_exec_sessions s with(nolock)
on r.session_id = s.session_id
right outer join Sys.dm_exec_connections c with(nolock)
on s.session_id = c.session_id
where s.session_id >50
group by host_name,client_net_address
order by 3 desc

运行结果：

这个查询能够一下就帮我们找出来哪些机器发起了对数据库的链接，它们的链接数量是否有异常；这个其实对调查某些问题非常有用，我有一次就遇

到一个case：

用户反映，过一两个星期，系统就会出现一次异常，出问题时数据库连接数量很高，大量的访问被数据库拒绝，过半个小时左右，系统又自动恢复了，但是

在数据库里面查看，并没有发现有异常的进程和错误的信息，问题一时很棘手，很难定位，系统不稳定领导不满，DBA顶着压力一时不知道如何是好；后面

转换方向，通过调查问题发生时，为什么会产生这么多连接，这些连接是那些机器发过来的，这些连接发过来正常吗，是数据库不砍业务的重负，还是业务

在某个时间段内会出现暴涨等一系列原因，最终找出是一台Web因为开发人员代码写的有问题，内存出现内存泄露，导致大量的连接不能释放，出问题是，

发出的数据库连接数比平时高3-4倍，最终影响到了数据库，问题压根和数据库没关系（从这个事实看出，DBA真是的炮灰角色，不是自己的问题，也得顶

着压力调查出原因呀）；如果在类似问题发生时，我们能通过这个查询及早知道问题是出在某台Web机器上，那就不用费尽心力来调查数据库了。

4. 这些连接在访问哪个库：

--request info by databases
select db_name(r.database_id) as database_name,COUNT(0) host_count
from Sys.dm_exec_requests r with(nolock)
right outer join Sys.dm_exec_sessions s with(nolock)
on r.session_id = s.session_id
right outer join Sys.dm_exec_connections c with(nolock)
on s.session_id = c.session_id
where s.session_id >50
group by r.database_id
order by 2 desc

结果（为NULL的估计是没办法定位库）：

5. 进程状态：

--request info by status
select s.status,COUNT(0) host_count
from Sys.dm_exec_requests r with(nolock)
right outer join Sys.dm_exec_sessions s with(nolock)
on r.session_id = s.session_id
right outer join Sys.dm_exec_connections c with(nolock)
on s.session_id = c.session_id
where s.session_id >50
group by s.status
order by 2 desc

结果（running数比较多，表面数据库压力比较大）：

二. 从阻塞情况来判断异常（这部分内容不再一一贴图，直接上脚本）：

1. 查看数据库阻塞情况：

----------------------------------------Blocked Info----------------------------------
--记录当前阻塞信息
select t1.resource_type as [lock type] ,db_name(resource_database_id) as [database]
,t1.resource_associated_entity_id as [blk object]
,t1.request_mode as [lock req] -- lock requested
,t1.request_session_id as [waiter sid] -- spid of waiter
,t2.wait_duration_ms as [wait time]
,(select text from sys.dm_exec_requests as r with(nolock) --- get sql for waiter
cross apply sys.dm_exec_sql_text(r.sql_handle)
where r.session_id = t1.request_session_id) as waiter_batch
,(select substring(qt.text,r.statement_start_offset/2,
(case when r.statement_end_offset = -1 then len(convert(nvarchar(max), qt.text)) * 2
else r.statement_end_offset end - r.statement_start_offset)/2+1)
from sys.dm_exec_requests as r with(nolock)
cross apply sys.dm_exec_sql_text(r.sql_handle) as qt
where r.session_id = t1.request_session_id) as waiter_stmt --- statement executing now
,t2.blocking_session_id as [blocker sid] --- spid of blocker
,(select text from sys.sysprocesses as p with(nolock) --- get sql for blocker
cross apply sys.dm_exec_sql_text(p.sql_handle)
where p.spid = t2.blocking_session_id) as blocker_stmt,getdate() time
from sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)
where t1.lock_owner_address = t2.resource_address

2. 查看阻塞其他进程的进程（阻塞源头）：

--阻塞其他session的session
select t2.blocking_session_id,COUNT(0) counts
from sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)
where t1.lock_owner_address = t2.resource_address
group by blocking_session_id
order by 2

3. 被阻塞时间最长的进程：

--被阻塞时间最长的session
select top 10 t1.resource_type as [lock type] ,db_name(resource_database_id) as [database]
,t1.resource_associated_entity_id as [blk object]
,t1.request_mode as [lock req] -- lock requested
,t1.request_session_id as [waiter sid] -- spid of waiter
,t2.wait_duration_ms as [wait time]
,(select text from sys.dm_exec_requests as r with(nolock) --- get sql for waiter
cross apply sys.dm_exec_sql_text(r.sql_handle)
where r.session_id = t1.request_session_id) as waiter_batch
,(select substring(qt.text,r.statement_start_offset/2,
(case when r.statement_end_offset = -1 then len(convert(nvarchar(max), qt.text)) * 2
else r.statement_end_offset end - r.statement_start_offset)/2+1)
from sys.dm_exec_requests as r with(nolock)
cross apply sys.dm_exec_sql_text(r.sql_handle) as qt
where r.session_id = t1.request_session_id) as waiter_stmt --- statement executing now
,t2.blocking_session_id as [blocker sid] --- spid of blocker
,(select text from sys.sysprocesses as p with(nolock) --- get sql for blocker
cross apply sys.dm_exec_sql_text(p.sql_handle)
where p.spid = t2.blocking_session_id) as blocker_stmt,getdate() time
from sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)
where t1.lock_owner_address = t2.resource_address
order by t2.wait_duration_ms desc

此文大致总结了通过DMV调查数据库异常的基本方法和步骤，如果大家在调查问题时能够灵活运用，相信对数据库异常情况的定位和解决能够更快更有效。

本文链接

什么是列存储？

2012-02-20T02:15:00Z

列存储不同于传统的关系型数据库，其数据在表中是按行存储的，列方式所带来的重要好处之一就是，由于查询中的选择规则是通过列来定义的，

因此整个数据库是自动索引化的。按列存储每个字段的数据聚集存储，在查询只需要少数几个字段的时候，能大大减少读取的数据量，一个字段的

数据聚集存储，那就更容易为这种聚集存储设计更好的压缩/解压算法。这张图讲述了传统的行存储和列存储的区别：

（转至：http://blog.csdn.net/franklysun/article/details/6417483）

本文链接

讨论一个比较有意思的业务需求

2012-02-17T02:40:00Z

业务需求描述：

有一个用户登录表，用户每次登陆时，就会向这个表中插入一条数据，这个表记录了用户的用户ID和登录时间，表的数据量有几千万，

现在需要求出从今天开始算，用户持续登录的时间（也就是用户今天登陆了，昨天也登陆了，但是前天没有登录，那用户的持续登录时间就

是一天）。

分析：

看似蛮简单的一需求，在数据库里面实际操作起来不是那么简单的，并非一个简单的Select能够搞定的，从业务的描述我们起码可以得到如下

的分析结论：

1. 业务需要统计这样的数据，应该并不需要实时的数据，所以我们可以获取某个时间的快照数据来做计算；

2. 表数据量比较大，如果直接在这个表上操作，势必会对产品的使用造成影响（因为每个用户登录时，都需要再往里面插数据的）；

3. 需要统计每个用户的持续登录时间，那意味着如果没有持续登录时间的用户就是不需要的用户，这里面应该可以筛选掉一大批用户；

4. 每个用户都需要做统计计算，这个肯定是一个循环计算的过程，我们最好前期能过滤掉一部分用户，那后面的统计计算无疑可以节省很多的时间；

5. 用户持续登录，一般时间不可能很长（很少有人天天去登陆一个网站，持续100天的吧），意味着我们可以用持续天数来做为循环条件，

而不必以用户来作为循环条件（用户做循环条件的话，循环次数应该会比较大）；

6. 大数据量做统计，而且是定位到每个用户的，性能是必须要重点考虑的因素；

造测试数据：

测试数据其实有一个比较难的要求是能够尽量的接近真实数据，这样的测试效果才是最好的；我们预计造一个2千5百万的表，造几十万的用户，然后随机

的生成登陆时间，但是要求登录时间尽量能贴合真实的情况；

我们先创建测试表（其实最好是分区表）：

--Create Test Table
create table dbo.UserLoginInfo
(
userid int
,logintime datetime
,CONSTRAINT [PK_UserInfo] PRIMARY KEY CLUSTERED
(
userid ASC
,logintime ASC
)WITH
(
PAD_INDEX = OFF
,STATISTICS_NORECOMPUTE = OFF
,IGNORE_DUP_KEY = OFF
,ALLOW_ROW_LOCKS = ON
,ALLOW_PAGE_LOCKS = ON
,FILLFACTOR = 90
) ON [PRIMARY]
) ON [PRIMARY]

--DST Table
create table dbo.DST_UserLoginInfo
(
userid int
,logindate varchar(10)
,ContinueDays smallint
,IsOver bit
,CONSTRAINT [PK_UserLoginInfo] PRIMARY KEY CLUSTERED
(
userid ASC
,logindate ASC
)WITH
(
PAD_INDEX = OFF
,STATISTICS_NORECOMPUTE = OFF
,IGNORE_DUP_KEY = OFF
,ALLOW_ROW_LOCKS = ON
,ALLOW_PAGE_LOCKS = ON
,FILLFACTOR = 90
) ON [PRIMARY]
) ON [PRIMARY]

说明：我们创建了两个表，一个是模拟真实的用户登录数据的表，另外一个是我们准备做数据统计的表；

我们按时间由远到近，分几个批次来生成测试数据：

/*-----------造二千五百万用户登录记录的过程---------------------*/
--第一批次
set nocount on
go
--1000*5000=500W
declare @u_count int
set @u_count=0
--1000
while @u_count<1000
begin
declare @userid int,@count int
set @userid= rand()*100000
set @count=0
--5000
while @count<5000
begin
insert into dbo.UserLoginInfo(userid,logintime)
--4000
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%4000),getdate()-4000),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

--第二批次
set nocount on
go
--1000*6000=600W
declare @u_count int
set @u_count=0
while @u_count<1000
begin
declare @userid int,@count int
set @userid= rand()*1000000
set @count=0
while @count<6000
begin
--3000
insert into dbo.UserLoginInfo(userid,logintime)
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%3000),getdate()-3000),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

--第三批次
set nocount on
go
--1000*4000=400W
declare @u_count int
set @u_count=0
while @u_count<1000
begin
declare @userid int,@count int
set @userid= rand()*1000000
set @count=0
while @count<4000
begin
--2000
insert into dbo.UserLoginInfo(userid,logintime)
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%2000),getdate()-2000),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

--第四批次
set nocount on
go
--10000*700=700W
declare @u_count int
set @u_count=0
while @u_count<10000
begin
declare @userid int,@count int
set @userid= rand()*100000000
--select @userid
set @count=0
while @count<700
begin
--1000
insert into dbo.UserLoginInfo(userid,logintime)
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%1000),getdate()-1000),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

--第五批次
set nocount on
go
--100000*10=100W
declare @u_count int
set @u_count=0
while @u_count<100000
begin
declare @userid int,@count int
set @userid= rand()*100000000
set @count=0
while @count<10
begin
--500
insert into dbo.UserLoginInfo(userid,logintime)
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%500),getdate()-500),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

--第六批次
set nocount on
go
--100000*20=200W
declare @u_count int
set @u_count=0
while @u_count<100000
begin
declare @userid int,@count int
set @userid= rand()*100000000
set @count=0
while @count<20
begin
--365
insert into dbo.UserLoginInfo(userid,logintime)
select @userid,CAST(convert(varchar(10),dateadd(d,abs(checksum(newid())%365),getdate()-365),120)+' '+ str(5+abs(checksum(newid())%6),2)+':'+replace(str(abs(checksum(newid())%60),2),'','0')+':'+replace(str(abs(checksum(newid())%60),2),'','0') as datetime)
set @count=@count+1
end
set @u_count=@u_count+1
end
go
set nocount off

造这些数据，在我本机上花了大半天时间才完成（痛苦呀），这些脚本运行完之后，我本机生成的数据量情况如下：

用户数量：

随机生成的时间情况：

现在我们完成了一个两千五百万记录，用户数量二十二万，时间从2001-03-05到2012-02-15的用户登录记录；但是有个问题，就是今天的时间，

没有加上去，我们再补充一下今天登陆的记录（假定今天每个用户都登陆了）

--add today login recode for every user
insert into dbo.UserLoginInfo(userid,logintime)
select userid,DATEADD(MINUTE,-20,GETDATE()) from
(
select distinct userid from dbo.UserLoginInfo with(nolock)
) a

加完之后就应该有今天的数据了：

到这里造数据的过程就完了。

持续天数计算：

思路：1. 我们将UserLoginInfo的记录先做筛选，筛选掉那些今天有登陆，但是昨天没有登录的用户（也就是没有持续登录的用户）；

2. 将筛选后的数据放入到中间表，我们通过中间表来计算用户持续登录的天数；

3. 计算完成后，通过查询中间表，输出用户和持续登录天数；

以下就按照前面的思路来开展步骤：

1. 筛选掉不需要的记录，并将其导入中间表：

--find data into other table
insert into dbo.DST_UserLoginInfo(userid,logindate,ContinueDays,IsOver)
select distinct userid,convert(varchar(10),logintime,23) as logindate,0,0
from dbo.UserLoginInfo a with(nolock)
where exists
--login today
( select 1 from dbo.UserLoginInfo b with(nolock) where b.userid=a.userid
and b.logintime<=GETDATE() and b.logintime>=convert(varchar(10),GETDATE(),23))
--login yesterday
and exists
(select 1 from dbo.UserLoginInfo c with(nolock) where a.userid=c.userid
and c.logintime<convert(varchar(10),GETDATE(),23) and c.logintime>=convert(varchar(10),GETDATE()-1,23)
)

说明：在这里我们将时间字段变成了日期型的字符串，方便后面计算时做判断，另外中间表增加了持续时间和标识位字段，也是为了方便后面的计算。

2. 通过天数来循环中间表，计算持续天数：
我们先来看一下，筛选完成后的数据量为800多万，节省了持续天数计算时大量的计算量；

接着我们来计算持续天数：

这里有两种方式：

1. 按用户来循环计算：

每次取一个用户，然后根据用户ID来循环计算这个用户的持续登录天数；但是设想一下，如果我们有10万个用户，那我们第一层次取用户的循环将要

循环10万次，而且每个用户又需要在第一层的循环里面做持续时间天数的循环计算，可以想象计算量是非常大的，不可取；

2. 按持续天数来循环计算：

前面分析阶段已经提及过，正常情况下很少有用户能持续100天，每天都登陆到一个网站上面的，那意味着我们循环的天数不会是一个非常大的量，而

且这种循环一次性的将同一个持续天数的用户一次性计算完成了，效率应该是比较高的，我们采用这种方式来进行计算；

--Update ContinueDays
declare @days smallint
set @days=1
while exists (select 1 from dbo.DST_UserLoginInfo where IsOver=0)
begin
update a set ContinueDays=@days,IsOver=1
from dbo.DST_UserLoginInfo a
where IsOver=0
and exists
(select 1 from dbo.DST_UserLoginInfo b with(nolock) where a.userid=b.userid and IsOver=0
and b.logindate=convert(varchar(10),GETDATE()-@days,23))
and not exists
(select 1 from dbo.DST_UserLoginInfo c with(nolock) where a.userid=c.userid and IsOver=0
and c.logindate=convert(varchar(10),GETDATE()-@days-1,23))

set @days=@days+1
end

运行完成后，我们来查看下运行的结果：

一共是14639个用户有持续登录，最长的登录时间为259天（真实情况应该不会有这么大，计算的时候最耗时的就是这两个持续时间大的用户）。

验证结果：

我现在来抽查几条数据，看是否正确：

先在中间表中随便找一个持续时间为一天的记录，再到原登录表中找到他实际的登录数据：

打钩的是持续时间，正好是一天（其实这里的理解好像有点问题，用户明明是连续两天登录，而此处的持续时间只算做一天）；

接下来抽个三天的记录：

结果也是正确的。

总结：

分析、造数据、测试和计算我们都做完了，现在将上面的计算过程做成一个存储过程，这样就方便随时调用了：

Create Proc usp_UserContinueDays
as
begin
set nocount on
--truncate dst table
if OBJECT_ID('dbo.DST_UserLoginInfo') is null
begin
--DST Table
create table dbo.DST_UserLoginInfo
(
userid int
,logindate varchar(10)
,ContinueDays smallint
,IsOver bit
,CONSTRAINT [PK_UserLoginInfo] PRIMARY KEY CLUSTERED
(
userid ASC
,logindate ASC
)WITH
(
PAD_INDEX = OFF
,STATISTICS_NORECOMPUTE = OFF
,IGNORE_DUP_KEY = OFF
,ALLOW_ROW_LOCKS = ON
,ALLOW_PAGE_LOCKS = ON
,FILLFACTOR = 90
) ON [PRIMARY]
) ON [PRIMARY]

end
else
truncate table dbo.DST_UserLoginInfo

--find data to other table
insert into dbo.DST_UserLoginInfo(userid,logindate,ContinueDays,IsOver)
select distinct userid,convert(varchar(10),logintime,23) as logindate,0,0
from dbo.UserLoginInfo a with(nolock)
where exists
--login today
( select 1 from dbo.UserLoginInfo b with(nolock) where b.userid=a.userid
and b.logintime<=GETDATE() and b.logintime>=convert(varchar(10),GETDATE(),23))
--login yesterday
and exists
(select 1 from dbo.UserLoginInfo c with(nolock) where a.userid=c.userid
and c.logintime<convert(varchar(10),GETDATE(),23) and c.logintime>=convert(varchar(10),GETDATE()-1,23)
)

--Update ContinueDays
declare @days smallint
set @days=1
while exists (select 1 from dbo.DST_UserLoginInfo where IsOver=0)
begin
update a set ContinueDays=@days,IsOver=1
from dbo.DST_UserLoginInfo a
where IsOver=0
and exists
(select 1 from dbo.DST_UserLoginInfo b with(nolock) where a.userid=b.userid and IsOver=0
and b.logindate=convert(varchar(10),GETDATE()-@days,23))
and not exists
(select 1 from dbo.DST_UserLoginInfo c with(nolock) where a.userid=c.userid and IsOver=0
and c.logindate=convert(varchar(10),GETDATE()-@days-1,23))

set @days=@days+1
end

--Result
select userid,MIN(logindate) as LoginDate ,ContinueDays from dbo.DST_UserLoginInfo
group by userid,ContinueDays
order by ContinueDays desc

set nocount off
end

到此，测试计算的过程完成，不过有点遗憾的是，这个业务需求是另外一个公司的朋友提供的，我没办法拿到他们原始的计算方法，所以就没用办法比较

算法的最终效果了；如果大家有更好的方法，欢迎讨论。

本文链接

SQLServer内存数据写入磁盘的方法比较

2012-02-14T06:57:00Z

众所周知，SQLServer增删改数据最先都是在内存中进行的，这可以大大加快数据操作的速度；当内存中的数据被修改了，而磁盘中的数据

还没有被修改时，就产生了所谓的”脏页“，SQLServer是如何同步内存和磁盘的数据的呢？以下三种方法就是为同步内存和磁盘数据而产生的。

LazyWrite（惰性写入器）:
   作用：
   1.管理SQLServer空闲内存：
    a. 定期检查空闲缓冲列表的大小，当这个值过低的时候，它会扫描整个数据缓存，将一段时间没有使用的页面老化（通过LRU算法），释放内存空间；
    b. 如果找到一段时间没有被使用的脏页，它会将其写入磁盘，然后将这个页面的内存空间标记为空闲空间；

   2.协调Windows与SQLServer内存：
    a. 监视服务器内存，如果Windows物理内存很少，它会从空闲缓冲列表中释放内存给Windows；
    b. 在SQLServer负载很重时，它还会在分配给SQLServer的内存没有达到最大服务器内存阀值时，增加空闲缓冲列表的大小，以适应负载的需要。

CheckPoint：
   作用：检查点是检查点进程创建的一个时间点，在这个时间点，SQLServer可以确认所有提交的事物所做的修改都已经写入磁盘，它是一个标记，
         这个标记是数据库恢复的起始点，大约每分钟运行一次，这样在启动数据库时，确保数据库在一分钟内就能完成恢复操作；但是如果在这段
         时间内写入日志的数据不到10MB，SQLServer就不会自动发起检查点。

跟踪标记（trace flag）3502在错误日志中记录检查点的开始和结束位置。

    与LazyWrite比较，CheckPoint不会从缓存中移出脏页，CheckPoint进程的工作只是保证脏页被写入磁盘，并且在页头将缓存中的这个页面标记为
    干净的页面。

EagerWrite：
    通常在BCP、SELECT INTO, WRITETEXT,UPDATETEXT,BULK INSERT等操作时发生，为了加快这些操作的速度，EagerWrite会管理数据页

的创建和分配，这些操作不会等待所有的页面创建完成后才将内存中的数据写入到页面中，而是以更高的优先级边创建边将缓存中的数据写入页面中，

以保证缓冲池有足够的空间来完成这些操作。

本文链接