总结以上分析，如果数据库应用开发者或管理员想要影响SQLServer锁的申请和释放行为，以缓解阻塞或死锁问题，需要考虑的因素有：1.   事务隔离级别的选定。事务隔离级别越高，隔离度就越高，并发度也就越差。如果选择了比较高的隔离级别，SQLServer不可避免地要申请更多的锁，持有的时间也会增加。所以在设计应用的时候，一定要和用户谈好，尽量选择默认的隔离级别（READCOMMITTED）。

在分析不同形式的语句执行对申请锁行为的影响之前，管理员要先了解怎么去监视一个连接当前持有的锁，以及怎么去监视一个语句的执行过程中，SQL Server对锁的申请和释放行为。检查一个连接当前锁持有的锁 通常可以使用sp_lock这句命令来列出当前SQL Server里所有的连接持有的锁的内容。我们也可以查询sys.dm_tran_locks这张系统动态管理视图来实现。SELECT

数据库有并发操作的时候，修改数据的事务会影响同时要去读取或修改相同数据的其他事务。如果数据存储系统没有并发控制，则事务可能会看到以下负面影响：·        脏读：当一个事务开始更新数据，但是这一个事务并没有完成提交，这时候，第二个事务开始读取数据，把第一个事务所更改的数据读了出来。第二个事务读取的数据是临时的，而且很危险的，因为有可能第一个事务最终做rollback操作·

SQL Server数据库引擎具有多粒度锁定，允许一个事务锁定不同类型的资源。为了尽量减少锁定的开销，数据库引擎自动将资源锁定在适合任务的级别。锁定在较小的粒度（例如行上）可以提高并发度，但开销较高，因为如果锁定了许多行，就需要维护很多锁。锁定在较大的粒度（例如表）上，会降低并发度，因为锁定整个表限制了其他事务对表中任意部分的访问，但其开销较低，因为需要维护的锁数目较少。数据库引擎通常必须获取

事务是关系型数据库的一个基础概念。它是作为单个逻辑工作单元执行的一系列操作。一个逻辑工作单元必须有4个属性，称为原子性、一致性、隔离性和持久性属性（ACID），只有这样才能成为一个事务。  原子性事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。比如一个事务要修改100条记录，要不就100条都修改，要不就都不修改。不能发生只修改了其中50条，而另外50条没有改的情况。

在SQL Server 2008Enterprise或更高版本上有一个很诱人的新功能。如果某个配置了数据库镜像或者AlwaysOn的数据库发生数据页面访问错误（823、824和829），数据库伙伴会自动尝试解决错误。无法读取页的伙伴会从其他伙伴请求新副本。如果此请求成功，则将以新副本替换不可读的页，这通常会解决发生在镜像或AlwaysOn的主服务器上的页面损坏。1. 数据库镜像的页面自动修

如果数据库或数据库备份受损，在检查数据库完整性的时候，会发现各种各样的错误。在这一节里，我们针对不同的损坏部位，给出不同的应对方法。首先，我们创建一个测试数据库。 CREATE DATABASE TESTDBGOUSE TESTDBGOCREATE TABLE TESTTABLE(ID int,NAME nvarchar(50))  --建立两个索引，其

DBCC CHECKDB指令可以完成两项任务：（1）检查数据库里有没有损坏发生。（2）尽力修复数据库损坏，使数据能够重新被正常访问。所以哪怕是一个正常运行的数据库，也建议定期运行这句指令，以确保没有损坏发生。对于已经发生访问错误的数据库，应该在第一时间运行这句指令，了解损坏的范围和程度。那么DBCCCHECKDB究竟做了哪些检查呢？在做些什么DBCC CHECKDB通过依次执行下列操作

SQL Server 对数据库损坏的错误类型做了细化，在此对几个典型的错误作一下介绍。 错误信息是：“在文件 '%ls'中、偏移量为 %#016I64x 的位置执行 %S_MSG 期间，操作系统已经向 SQL Server 返回了错误 %ls。”“The operating systemreturned error %ls to SQL Server during a %S_MSGat

数据库管理员最大的梦魇，莫过于已经做了备份，但是在想恢复的时候，发现备份文件也是坏的。这将意味着数据库的丢失，后果非常可怕。发生这种情况的原因一般有3个：·        备份文件和数据库放在同一个（或一组）物理硬盘上。硬盘出故障，备份也保不住。·        备份介质损坏；或者做的是网络备份，数据在网络传输中发生了损坏。·        数据库在做完整备份、文件备份或者文件组备份的

从SQL Server 2008开始，数据库引入了FILESTREAM这个功能。对于BLOB数据，如Images, Video, Word文档等等，可以存放在文件系统中，而不是在数据库文件里。这对数据库备份和恢复有什么影响呢。我们通过一个例子，来检查一下带有FILESTREAM功能的数据库备份和恢复方案。 第一步，在数据库服务级别，启动FILESTREAM，我们可以打开数据库的配置管理器，

前面我们讲的备份与恢复，都是集中在用户数据库上。SQLServer还维护着一组系统级数据库（称为“系统数据库”），这些数据库对于服务器实例的运行至关重要。每次进行过系统更新后，都必须备份多个系统数据库。必须备份的系统数据库包括msdb、master和model。如果有任何数据库在服务器实例上使用了复制，则还必须备份distribution系统数据库。备份这些系统数据库，就可以在发生系统故障（例如硬

为了帮助用户能以最快的速度还原数据库，SQLServer也在不断引入新的还原方法。SQL Server一共可以支持4个级别的数据还原：   数据库（“数据库完整还原”）级还原和恢复整个数据库。数据库在还原和恢复操作期间会处于离线状态。   数据文件（“文件还原”）级还原和恢复一个数据文件或一组文件。在文件还原过程中，包含相应文件的文件组在还原过程中自动变为离线状态。访问离线文件组的

SQL Server提供了足够多的技术来做各种各样的数据库备份。作为一个数据库管理员，应该选择怎样的备份策略呢？建议您问自己两个问题。（1）您管理的数据库最多能够容忍多长时间的数据丢失？（2）您准备投入多少人力物力来做数据库备份与恢复策略？问题似乎有点残酷。但是世界上大多数事情，要获得越好的效果，就需要越多的投入。数据库备份策略尤其是这样。不考虑镜像技术（包括SQLServer自己的数

SQL Server的开发部门一直在致力完善SQL Server的备份恢复功能，希望帮助数据库管理员用最小的代价保证数据安全。所以基本上每个版本在这方面都有功能扩充。丰富的功能带来的一个副作用是，在联机丛书或其他介绍备份恢复的文档里，会看到很多种备份方法，让人有点莫衷一是。它们之间是什么关系呢？这里让我们来梳理一下。SQL Server数据库分数据文件和日志文件。为了使得数据库能够恢复到某个一

数据安全是数据库的生命。管理员可以小心地在软件层面配置各种安全策略，防止数据的意外丢失。可是再小心，也很难保证数据的100%安全。难免会有一些意外灾难发生，例如：   使用者错误比如，一个有管理员权限的使用者不小心把整张表都删掉了；或者安全策略有漏洞，数据被人恶意修改。   硬件故障比如硬盘损坏，里面的数据文件无法再被访问;或者服务器整个故障，甚至无法启动。   自然灾害例

通过前面的介绍，你可以发现AlwaysOn是一项集合了故障转移群集、数据库镜像和日志传送的优点于一身的、功能强大的“高可用性+灾难恢复”技术。有了它，你不需要通过结合多种技术，就可以获得一个或多个和本地完全同步的远程数据副本，像群集一样，副本之间可以进行自动故障转移，同时还可以对客户端完全透明。通过AlwaysOn来构架方案，能够降低部署的难度以及后期维护的复杂度。如果你对你的SQLServer数

SQL Server 2012提供了非常多的信息来方便你监视可用性组的运行状态。系统视图和动态管理视图首先，AlwaysOn提供了大量的系统视图和动态管理视图，可以通过视图来监视以下对象的状态：（1）        可用性组所在的Windows故障转移群集·        sys.dm_hadr_cluster·        sys.dm_hadr_cluster_membe

相对数据库镜像，AlwaysOn的一个重要优势就是可以将辅助数据库配置成可读模式。这极大地增强了数据库整体的伸缩性。通过将只读请求分流到辅助数据库，主副本的工作负载得到了减轻，读和写之间的冲突可以得到缓解，辅助副本的硬件资源也能得到利用。同时，通过AlwaysOn的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。利用这个功能，SQLServer可以实现工作

前面我们介绍了AlwaysOn是如何实现副本之间的数据同步的。那它的另一大功能：故障转移又是怎么实现的呢？首先，来了解下AlwaysOn是如何发现可用性组出现问题的。由于AlwaysOn可用性组是建立在Windows故障转移群集之上的，因此和SQLServer群集类似的，AlwaysOn可用性组也需要一个群集resourceDLL来连接Windows群集和SQLServer实例。由于可用性

可用性模式是每个可用性副本的一个属性。可用性模式决定了主副本在提交事务之前是否需要等待某个辅助副本将事务日志记录固化到磁盘。AlwaysOn可用性组支持两种可用性模式：“异步提交模式”和“同步提交模式”。如果你曾经使用过数据库镜像，你会发现可用性模式的概念和镜像的概念（异步操作模式和同步操作模式）非常相似。异步提交模式使用此可用性模式的可用性副本称为“异步提交副本”。当辅助副本处于异步提交

像数据库镜像技术一样，AlwaysOn会在各个副本上都维护一套数据拷贝。主副本上发生的数据变化，会同步到辅助副本上。所以和镜像一样，AlwaysOn也要完成三件事：1.把主副本上发生的数据变化记录下来2.把这些记录传输到各个辅助副本3.把数据变化在辅助副本上同样完成一遍。那AlwaysOn又是怎么做的呢？在主副本和辅助副本上，SQL  Server都会启动相应的线程，完成相应的任务

要部署一套AlwaysOn的方案，必须首先要部署一套Windows2008或者Windows2008 R2的群集环境。在Windows群集的节点上，你可以在群集的节点上安装SQLServer单机实例，也可以使用群集中的多个节点安装SQLServer群集实例。无论是单机实例，还是群集实例，只要这些实例上都配置了同一个AlwaysOn可用性组，这些实例就被称为该可用性组的可用性副本（Availabil

前一章我们讨论了SQLServer过去几个版本所包含的高可用性和灾难恢复技术，也详细地介绍了它们彼此的优缺点。可能你对高可用的要求非常高，任何一种技术都无法完全满足你的要求。而把几种技术组合起来，又会给部署和维护带来太多的复杂性。你会觉得有一点遗憾，为什么没有一种更强大更完善的技术来满足你所有的诉求呢？从SQLServer 2012开始，SQLServer引入了一种新的高可用技术，它的名字叫做Al

通过前面的介绍，相信你对各种高可用和灾难恢复技术已经有一定程度的了解。这些技术都已经被广泛的应用在了全世界的各种企业环境中，为应用持续运行提供保障。高可用和灾难恢复技术的比较每一种技术都有其优点和局限，这些因素决定了它适用于怎么样的环境。要比较各种不同的高可用和灾难恢复技术，就要了解它们的优点和局限。这样才能根据你的需求选择最合适的一款。故障转移群集故障转移群集是SQL Serve

复制（replication）也是SQLServer上一个非常“资深”的功能了。它采用了独特的“发布-订阅”的模式，将SQLServer中的数据分发到各个服务器或客户端上去。需要说明的是，复制并不是一个为灾难恢复而设计的的功能，它更注重的，是数据同步。用复制来作为灾难恢复的解决方案，往往是使用较多的代价和资源，但只是实现的效果很一般，可以说是性价比不高。大多数情况下，你可以使用日志传送或者数据

根据前面的介绍读者会发现，故障转移群集技术和日志传送技术都不是那么“完美”。故障转移群集可以让系统在遇到故障时自动恢复，但是不能提供数据冗余，以对抗数据库损坏事故。日志传送可以提供冗余的数据拷贝，但是主数据库和辅助数据库之间的时间差可能比较长，故障切换也比较麻烦。所以仅有这两种技术，还是不能满足SQLServer用户的需求。数据库镜像功能首次出现在SQL Server 2005 SP1中。它设

SQL Server有多种技术可以用于实现自动创建冗余数据拷贝，提供数据灾难恢复的功能。其中，日志传送（logshipping）是最早出现的技术之一。虽然日志传送“年纪”很大，但是它依旧凭借着其独有的特点，在SQLServer的灾难恢复技术中扮演着重要的角色。日志传送的结构日志传送的工作机制非常简单。它主要是通过最基本的数据库事务日志备份和还原任务，来保持两台或者多台机器之间数据库同步，以

SQL Server使用最广的高可用性技术叫做故障转移群集（SQLServer Failover Cluster）。这是一项基于Windows故障转移群集的一种技术。SQLServer故障转移群集技术集成了微软技术一贯简单易用的特点，在部署和管理上都非常容易，同时又能提供非常良好高可用性，因此目前得到了非常广泛的使用。可以说，它是SQL2012之前的各个版本，实现高可用性的必选技术。故障转移群

作为一个数据库服务，SQL Server其实可以分成两个部分：1)  SQL Server服务本身SQL作为一个应用服务，接受用户的连接，处理用户发过来的各项请求等。这部分功能是由一组安装在Windows上的可执行文件来提供的。如果这部分出问题，就需要恢复Windows系统、网络连接、SQLServer的可执行文件、以及SQL的一切相关配置。如何能保证这部分的正常运行，在系统故障时能够快速