柔中带刚，刚中带柔，淫荡中富含柔和，刚猛中荡漾风骚，无坚不摧，无孔不入！
全部博文（1669）
分类： SQLServer
2014-07-08 12:48:42
前一章我们讨论了SQLServer过去几个版本所包含的高可用性和灾难恢复技术，也详细地介绍了它们彼此的优缺点。可能你对高可用的要求非常高，任何一种技术都无法完全满足你的要求。而把几种技术组合起来，又会给部署和维护带来太多的复杂性。你会觉得有一点遗憾，为什么没有一种更强大更完善的技术来满足你所有的诉求呢？从SQLServer 2012开始，SQLServer引入了一种新的高可用技术，它的名字叫做AlwaysOn。而它可能就是你一直以来在寻求的解决方案。
AlwaysOn在开发初期代号叫做HADRon。从开发代号就可以看出，AlwaysOn是一种集合了高可用性（HA）和灾难恢复（DR）两种功能于一身的技术。从它的正式名称也可以看出，它的设计目标是尽可能地保持你的数据库系统永远可用。虽然永远可用更多的是一句口号，但是AlwaysOn相对于故障转移群集、数据库镜像和日志传送而言，的确是拥有许多优势。甚至可以说，AlwaysOn是这三种技术的集大成者。
AlwaysOn所支持的高可用单位，既不像Cluster一样，是整个SQL实例；也不像数据库镜像和日志传送一样，只能是单个用户数据库。AlwaysOn支持的，是一个“可用性组”（AvailabilityGroup）。每个可用性组是一个包含了一个或数个用户数据库的容器，可用性组里的所有数据库作为一个整体发生故障转移。
AlwaysOn利用了Windows故障转移群集的健康监测和自动故障转移的特性，因此它必须建立在Windows故障转移群集之上。但是和SQLServer群集不同的是，可用性组里的数据库并不是一定要求存放在共享存储（SharedDisk）上的，它们也可以存储在本地磁盘上。另外，可用性组是以用户数据库的集合为单位进行健康检测和故障转移的，而不像SQLServer群集那样是以整个实例为单位。
AlwaysOn具有以下这些关键特性：
1. 像群集一样，AlwaysOn支持故障转移，但是它具有其独特的特点：
2. 像镜像和日志传递一样，AlwaysOn在辅助服务器上有数据库的另外一份拷贝。所不同的是，这份拷贝可以支持更多的只读功能。
通过上面这些特性，相信你已经很清楚地看到，AlwaysOn集合了许多以往SQLServer高可用和灾难恢复技术的优点，同时又具有自己独特的功能。这些特性不但保证了SQLServer更高的可用性，而且还实现了一定程度上的负载均衡，减轻了SQLServer主服务器的压力。可以预期AlwaysOn将会成为SQLServer最炙手可热的高可用和灾难恢复的技术。
要部署一套AlwaysOn的方案，必须首先要部署一套Windows2008或者Windows2008 R2的群集环境。在Windows群集的节点上，你可以在群集的节点上安装SQLServer单机实例，也可以使用群集中的多个节点安装SQLServer群集实例。无论是单机实例，还是群集实例，只要这些实例上都配置了同一个AlwaysOn可用性组，这些实例就被称为该可用性组的可用性副本（AvailabilityReplica）。AlwaysOn仅要求所有SQLServer实例都运行在同一个Windows群集上，但SQLServer实例本身不需要是群集模式的。如果没有特殊的理由，推荐所有的可用性副本都使用单机模式的SQLServer。
AlwaysOn可用性组里包含一个或多个用户数据库，这些数据库被称为可用性数据库（AvailabilityDatabase）。每个可用性副本上都有这些可用性数据库的副本，这些数据库副本彼此之间互相同步。如果可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
AlwaysOn可用性组从Windows群集角度来看，其实就是一个群集资源，因此可用性组中包含的所有数据库是作为一个整体在群集的节点间进行故障转移的。这使得AlwaysOn非常适合那些需要用到多个数据库的应用程序，避免了像数据库镜像那样只能切换单个数据库的问题。但是，可用性组不能包含系统数据库，也就是说系统数据库不能通过AlwaysOn实现高可用性，这点和数据库镜像是类似的。
在多个可用性副本间，只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），而这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。
AlwaysOn可用性副本利用了Windows群集的特性来进行故障的侦测和转移，因此它也受到群集的一些限制：
· 一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
· 一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
· 如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
· 一个数据库只能属于一个可用性组。
你可以通过图3-1来理解AlwaysOn的可用性副本，可用组和群集节点的关系。
图3-1AlwaysOn的可用性副本，可用组和群集节点的关系
假设一个Windows群集分布在两个子网(NetworkSubnet A和NetworkSubnet B)里。在子网A，有三个节点。子网B有两个节点。节点A1与节点A2上安装了一个群集的SQLServer实例Instance1。其他节点上分别安装了三个单机的SQLServer实例。这四个实例，就可以组成一个可用性组(AvailabilityGroup)。这些实例都是这个可用性组的可用性副本（AvailabilityReplica）。在图中(3-1)所显示的状态，SQL实例Instance1是主副本，其他实例都是辅助副本。这些实例上都存储有同样的一套用户数据库组（AvailabilityDatabase），但是只有Instance1上的数据库是可读写的。
如果NodeA1或NodeA2上安装有任何其他SQL实例，这些实例都不能被加入到这个可用性组里来。
接下来，让我们了解另一个重要的AlwasyOn组件: Listener（侦听器）。
假设我们建立了如下的这个AlwaysOn方案：可用性组(AvailabilityGroup)名叫testAG。它拥有三个可用性副本：Denali1、Denali2和Denali3。（图3-2）
Denali1现在是主副本，可用性组包含两个数据库：testdb1和testdb2。Denali1上还有一个不属于任何可用性组的数据库nonAGdb。在两个辅助副本Denali2和Denali3上，只有testdb1和testdb2这两个可用性数据库，没有其他数据库。
如果仅这样设置，在Windows故障转移群集管理器里就只能看到一个资源，即可用性组资源。但是SQL客户端不能使用这个资源的名字登陆SQLServer。它们必须知道当前主副本的实例名称，使用这个名字来连接SQLServer。一旦发生了AlwaysOn故障转移，就需要通过修改应用程序的连接字符串、添加别名等方式来把应用程序重新指向到新的主副本上去。在上面的例子里，用户开始时需要用Denali1这个名字来连接。如果AlwaysOn发生了故障转移，切换到了Denali2上，那所有的用户都要用Denali2这个名字来连接。这是非常不方便的。
为了可以让应用程序能够透明的连接到主副本而不会受到故障转移的影响，你需要创建一个Listener。一个Listener包含虚拟IP地址，虚拟网络名（DNS名）和端口号三个要素。创建了Listener之后，就会为可用性组资源添加虚拟IP地址和虚拟网络名资源。应用程序通过连接虚拟网络名而非主副本的实例名来访问到主副本实例和其上面运行的数据库，这点和故障转移群集很像。和故障转移群集不同的是，除了虚拟网络名可以使用之外，主副本本身的真实实例名依旧可以被用来连接到这个实例。
还是上面那个例子。我们可以创建一个名字（即虚拟网络名）是testAGvname的Listener。SQLServer Management Studio既可以用Denali1这个名字，也可以用testAGvname这个名字来连接SQLServer。用testAGvname连接上SQLServer之后，除了可用性组中的数据库，你也可以看到nonAGdb，证明你已经通过testAGvname连接到了Denali1这个副本上了。
SQL Server 2012以前版本的SQL Server，只有在实例启动的时候才会尝试绑定IP地址和端口。但是SQLServer 2012却允许你在副本实例处于运行状态的时候，随时绑定新的IP地址，网络名和端口号。因此你可以随时为可用性组添加Listener，而且这个操作会立刻生效。当添加了Listener之后，你会在SQLServer的错误日志中看到类似这样的信息。
你可以在创建可用性组的时候就为这个可用性组配置一个Listener。你也可以在可用性组创建完毕之后再动态的添加或删除listener。
要注意的是，SQLBrowser服务是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。
如果Listener使用的端口是默认端口1433的话，那么可用端程序可以很简单的直接使用虚拟网络名连接到主副本。但是如果Listener使用的端口是一个非默认端口的话，那么情况就有点复杂了：
（1） 如果主副本实例是侦听在默认端口上的话，那么客户端通过Listener的虚拟网络名依旧可以直接连接到主副本。其实客户端是使用了主副本侦听的1433端口，而非Listener所用的端口。
（2） 如果主副本实例是侦听在一个非默认端口上，那么客户端就必须在连接字符串中指定端口号才能连接到主副本实例。你可能会问，如果主副本上的SQL Browser服务在运行的话，客户端不能通过它找到主副本的端口从而连接上主副本吗？不行。即使你的主副本是个命名实例，客户端在使用AlwaysOn虚拟网络名时还是会把它当做一个默认实例，从而根本不会发UDP包到1434端口去访问SQL Brower服务。于是也就没法通过主副本的SQL Browser或的主副本侦听的端口。
如果各个可用性副本所使用的端口不相同，有的副本使用1433端口，而有的副本使用非默认端口，你就必须在连接字符串中指定端口号。如果客户端仅使用虚拟网络名来进行连接，当主副本是使用默认端口的实例时，连接可以建立；但一旦发生故障转移，应用程序的连接就会失败。这会影响数据库服务的高可用性。所以按照现有的设计，我们建议加入AlwaysOn的SQLServer实例，最好使用同样的固定端口。
像数据库镜像技术一样，AlwaysOn会在各个副本上都维护一套数据拷贝。主副本上发生的数据变化，会同步到辅助副本上。所以和镜像一样，AlwaysOn也要完成三件事：
1.把主副本上发生的数据变化记录下来
2.把这些记录传输到各个辅助副本
3.把数据变化在辅助副本上同样完成一遍。
那AlwaysOn又是怎么做的呢？在主副本和辅助副本上，SQL Server都会启动相应的线程，完成相应的任务。现在先从主副本谈起。
任何一个SQLServer里都有个叫LogWriter的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录有这个修改的日志信息，先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）。所以对于任何一个数据库，日志文件里都会有所以数据变化的记录。
对于配置为AlwaysOn主副本的数据库，SQLServer会为它建立一个叫LogScanner的工作线程。这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不停工作，主副本上的数据变化，可以不断地向辅助副本上传播。
在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化(Harden)和重做(Redo)。固化线程会将主副本LogScanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为“固化”）。而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。
当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通讯，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。
这些线程在工作上各自独立，以达到更高的效率。LogScanner负责传送日志块，而无须等待LogWriter完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。
读到这里，你或许会想，既然这些线程都是独立工作的，那主副本和辅助副本之间的数据差异量是怎么控制的呢？如何能保证主副本上的所有数据变化，都能被安全地传递到各个辅助副本上呢？AlwaysOn里有相应的机制，让这些线程相互协作。而副本之间是否允许有数据差异，则是由AlwaysOn的可用性模式决定的。可用性模式是每个可用性副本的一个属性。可用性模式决定了主副本在提交事务之前是否需要等待某个辅助副本将事务日志记录固化到磁盘。AlwaysOn可用性组支持两种可用性模式：“异步提交模式”和“同步提交模式”。如果你曾经使用过数据库镜像，你会发现可用性模式的概念和镜像的概念（异步操作模式和同步操作模式）非常相似。
异步提交模式
使用此可用性模式的可用性副本称为“异步提交副本”。当辅助副本处于异步提交模式下时，主副本无需确认该辅助副本已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。但是，辅助数据库的更新可能会滞后于主数据库，如果发生故障转移，可能会导致某些数据丢失。如果为当前主副本配置了异步提交可用性模式，则它将通过异步方式为所有辅助副本提交事务，而不管这些副本各自的可用性模式设置如何。
对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本性能的灾难恢复方案，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。
在异步提交模式下，辅助副本会尽量与自主副本的日志记录保持一致。不过，即使辅助数据库和主数据库上的数据事实上是同步的，可用性组也始终认为辅助数据库处于“SYNCHRONIZING”状态（即“未同步”状态），因为理论上在异步模式下，辅助数据库在任何时点都可能会落后。
同步提交模式
使用此可用性模式的可用性副本称为“同步提交副本”。在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。这样就保证两边的数据始终是同步的。只要一直在进行数据同步，辅助数据库就会保持“已同步”(SYNCHRONIZED)的状态。
同步提交模式能够保障给定的辅助数据库与主数据库上的数据保持完全的同步。但是这种保障的代价是主数据库上的事务提交会有滞后时间。可以说，同步提交模式相对于性能而言更强调高可用性。
为了优化AlwaysOn可用组在同步提交模式下的性能，SQLServer在AlwaysOn的工作线程和消息传递上动了很多脑筋。首先来看看，在辅助副本联接可用性组并与主副本建立会话之后，两者是如何同步日志的。
|
步骤 |
行为 |
|
1.连接 |
辅助副本通过主副本的镜像端点建立两者之间的连接 |
|
2.请求数据 |
辅助副本发出一个请求到主副本，要求主副本发送日志块。辅助副本和主副本会协商出一个日志块的LSN初始位置以及一些其他的信息。 |
|
3.运行Log Scanner |
在主副本上，log Scanner的工作线程开始工作。Log Scanner负责将日志块传送到辅助副本。 |
|
4. 固化和重做日志 |
辅助副本会使用固化(harden)线程和重做(redo)线程的工作线程来处理Log Scanner发送过来的日志块，固化线程将日志块固化到辅助副本的磁盘上，而重做线程负责将日志中记录的事务在辅助副本上重新演绎。 |
|
5.反馈进度 |
每当辅助副本收到3条来自主副本的消息的时候，就把固化和重做的进度作为一个消息返回给主副本。如果超过1秒钟还没收到3条消息的话，进度消息也会被返回。反馈到主副本的消息里包含了哪些LSN已经在辅助副本上被重做和固化。 |
通过上述的过程，最终辅助数据库上已经固化的日志会赶上主数据库的日志末尾。此时辅助数据库的状态就会设置为SYNCHRONIZED。这个同步阶段所需的时间主要取决于会话开始时辅助数据库滞后于主数据库的程度。另外，你需要明确重做线程和固化线程的区别，这点对理解事务提交的工作机制很重要。固化线程是将日志写入到日志文件，而重做线程是负责将日志中包含的数据更新真是的反映到数据文件上，这两个线程在AlwaysOn中是完全独立工作的。
接下里来看看在主副本上提交一个事务会发生些什么。
|
步骤 |
行为 |
|
1. 提交事务 |
在主副本上运行COMMIT TRAN命令来提交事务。 |
|
2. 写入到本地日志记录 |
在主副本上，COMMIT TRAN命令会被写成一条日志记录（此时记录还在主数据库的日志缓存中）。然后主副本上的log writer工作线程会把直到COMMIT命令为止的所有日志记录组成一个日志块从缓存写入到磁盘上的LDF文件中去。当日志被写入到磁盘之后，主数据库就开始等待来自辅助副本的消息来确认日志在辅助数据库上被成功写入磁盘。在这之前，该事务提交操作会保持等待。 |
|
3. 扫描日志 |
当日志块开始被从缓存写入到磁盘上时，它也会发信号给Log Scanner工作线程，告诉Log Scanner“日志已经准备好了，可以被发送到辅助副本上去了”。 Log Scanner从缓存中取出日志块，把它发送给AlwaysOn的日志块解码器(Log Block Cracker)。解码器会搜索日志中那些需要特别处理的操作，比如file stream操作，文件增长等。解码器会把这些操作作为一个消息发送给辅助副本。一旦日志块被解码完毕，整个日志块也会被作为消息发送给辅助副本。 |
|
4. 处理日志块消息 |
日志块消息在辅助副本上得到处理。固化线程负责将日志固化到磁盘上。然后日志被保存到辅助数据库的日志缓存中，重做线程从缓存中获得日志块并开始执行重做操作。 |
|
5. 反馈进度 |
每当辅助副本收到3条来自主副本的消息的时候，就把固化和重做的进度作为一个消息返回给主副本。如果超过1秒钟还没收到3条消息的话，进度消息也会被返回。进度信息中包含当前哪些LSN被固化了，哪些LSN已经被重做了。由于重做线程晚于固化操作启动，被固化的LSN可能会多于被重做的LSN。 |
|
6. 完成提交 |
主数据库受到了辅助副本来的确认消息，完成事务提交处理并向客户端发送一条确认消息。 |
在同步提交模式下，日志块必须在主副本和辅助副本上都被固化到磁盘上，事务才能真正在主数据上提交。但是它并不要求日志在辅助副本上完成重做，这样可以减轻对主副本的性能影响。
另外，AlwaysOn会定期检查各个副本，以及副本上的各个数据库的健康情况。如果某个副本不能正常通信，那这个主副本和辅助副本间的连接进入DISCONNECTED状态。如果某个数据库不能正常进行数据同步，则这个数据库会进入“NOTSYNCHRONIZING”状态。
可用性副本之间的“DISCONNECTED”连接状态
AlwaysOn 可用性组有一个会话超时机制。所有的主副本和辅助副本之间，会按固定间隔互相发送ping。在会话超时期限内，如果收到ping命令，就说明副本之间的连接正常。收到ping 后，副本将重置此连接上的超时计数器。主副本和辅助副本之间就通过ping来判断彼此是否依旧处于活动状态。
一旦某个副本因为网络故障、操作系统、SQLServer宕机等原因失去响应，它将不能按时把ping命令发给它的伙伴。如果主副本和某个辅助副本间的会话发生超时（没有收到辅助副本的ping），主副本和这个辅助副本之间的连接就会进入DISCONNECTED状态。进入DISCONNECTED状态后，即使可用性副本处于同步提交模式，事务也不需要等待该副本的响应就可以在主副本上提交。
会话超时限制是一个可用性组级别的设置，你可以通过在SQLServer Management Studio中打开可用组的属性来修改它的值，默认值为10 秒，允许的最小值为5秒。通常建议你将超时期限设置为10 秒或更长。因为如果低于10 秒，可能会使那些非常繁忙的系统错误地进入DISCONNECTED状态。
辅助数据库的“NOT SYNCHRONIZING”状态
无论使用什么可用性模式，如果一个事务在辅助数据库上重做失败，就会导致辅助数据库进入“NOTSYNCHRONIZING”状态。和DISCONNECTED状态类似，此时即使可用性副本设置为同步提交模式，事务也可以在主副本上之间直接提交而无需等待辅助副本响应。
如果你想中断某个数据库的数据同步，而不想影响可用性组中的其它数据库，可以通过在ManagementStudio中选择Suspenddata movement来手动挂起（图3-5）。挂起之后，该数据库在各个可用性副本（无论是什么可用性模式）上的状态都会变成“NOTSYNCHRONIZING”。
图3-5挂起可用性数据库
本节的最后，要提一下可用性模式对事物复制的影响。如果你把主数据库作为复制的发布数据库，事务复制的LogReader代理程序不会去处理那些尚未在辅助副本上固化的日志。因此，一旦辅助副本和主副本断开连接，那么复制就会停止工作。只有当辅助副本恢复和主副本的对话后，复制才能继续。此时主副本的日志可能会由于复制停止工作而变的很大。这种设计的主要目的是确保复制的数据发送速度，要慢于AlwaysOn的发送速度。因为辅助副本可能会通过故障转移成为新的主副本，从而变成新的发布服务器。如果复制跑得比AlwaysOn快，可能会发生订阅服务器比发布服务器数据更加新的情况。
前面我们介绍了AlwaysOn是如何实现副本之间的数据同步的。那它的另一大功能：故障转移又是怎么实现的呢？
首先，来了解下AlwaysOn是如何发现可用性组出现问题的。
由于AlwaysOn可用性组是建立在Windows故障转移群集之上的，因此和SQLServer群集类似的，AlwaysOn可用性组也需要一个群集resourceDLL来连接Windows群集和SQLServer实例。由于可用性组是一个群集资源，Windows群集需要透过AlwaysOn的resourceDLL来控制资源的上线/离线，检查资源是否失败，更改资源的状态和属性，以及发生各种命令给可用性副本实例。你可以透过故障转移群集管理器查看可用性组资源的各种属性。
AlwaysOn可用性组的资源类型是“SQLServer Availability Group”，该资源类型使用的resourceDLL的叫做hadrres.dll，在hadrres.exe中定义了如何对AlwaysOn可用性组经行Isalive检查的方法。和SQLServer群集的resourceDLL（sqsrvres.dll）一样，hadrres.dll也是由群集的RHS.exe进程加载的。由于AlwaysOn可用性组使用的是非Windows群集自带的资源类型和resourceDLL，默认情况下Windows群集单独产生一个RHS.exe来专门加载hadrres.dll。这样即使该RHS.exe由于异常而崩溃，整个群集的其他资源也不会受到影响。
那么AlwaysOn可用性组是如何执行Isalive检查来判断它的健康状况的呢？还记得之前讲到过SQLServer 2012群集使用了存储过程sp_server_diagnostics来进行群集的健康检查吗？其实Always也是使用了sp_server_diagnostics来检查可用性组的健康状况。Hadrres.dll会建立并保持一个连接到SQLServer，并通过这个连接运行sp_server_diagnostics，然后不断的获得诊断信息。sp_server_diagnostics的评估结果会被用来和AlwaysOn可用组的FailureConditionLevel设置向比较，来约定是够符合发生故障转移的条件。一旦条件满足，则可用性组就被切换到新的可用性副本上。更多关于sp_server_diagnostics存储过程的介绍，你可以参考第二章。
有几点需要注意的是：
1. 可用性组也是一种群集资源，但是它的HealthCheckTimeout属性默认是30000毫秒，而不像群集资源那样是60000毫秒。所以可用性组的获取诊断信息并记录到扩展事件日志的频率更高。
2. 无论你在一个实例上配置多少个可用性组，该实例上只会运行一条sp_server_diagnostics语句来诊断所有的可用性组。如果每个可用性组的HealthCheckTimeout设置不同，hadrres.dll会挑选最小的那个值并除以3来作为sp_serevr_diagnostics返回诊断信息的间隔（max(5, min(HealthCheckTimeout/3))）。这个最小的HealthCheckTimeout值被称为“有效HealthCheckTimeout”。
3. Sp_server_diagnostics只是检测实例的健康状态，而不是检测每个数据库的状态。所以如果当前SQL Server实例还能正常工作，但可用性组所包含的数据库发生诸如数据文件损坏、置疑等问题而不能被正常使用，sp_server_diagnostics是无法发现问题的。就算你为当前的可用性副本配置了自动故障转移，这种情况下也是不会触发故障转移的。
当Windows群集触发故障转移后，故障转移目标（原先的辅助副本）能够接管主副本角色，恢复自己管理的数据库，使它们作为新的主数据库。原先的主副本如果在故障转移后还可用的话，就会成为辅助副本，它上面的数据库就成为了辅助数据库。
AlwaysOn发现故障之后，是否会立刻触发故障转移呢？这取决于可用性副本的可用性模式和故障转移模式。
根据副本间数据同步的模式，可用性模式有两种：同步提交和异步提交。根据故障转移的方式，可用性副本也有两种故障转移模式：自动故障转移和手动故障转移。自动故障转移模式只有当副本的可用性模式为“同步提交”时才可以选择。
可用性模式和故障转移模式的组合形成了可用组的三种故障转移形式：自动故障转移、计划的手动故障转移（通称为“手动故障转移）、强制手动故障转移（通称为“强制故障转移”）。
需要注意的是，故障转移形式是由主副本和故障转移目标两者的模式所共同决定的。两个副本间要能发生自动故障转移，需要两者都配置为同步提交模式+自动故障转移模式。两者中有一个配置了手动故障转移，则自动故障转移就不能发生。两者间有一个配置了异步提交模式，则它们之间就只能发生强制故障转移。
三种故障转移形式中，只有强制故障转移可能会丢失数据。自动故障转移和手动故障转移会保证数据的安全。为了防止丢失数据，自动故障转移和手动故障转移都要求故障转移目标是使用同步提交模式的辅助副本且当时处于SYNCHRONIZED状态。如果已处于SYNCHRONIZED状态的辅助副本发出强制故障转移命令，其行为与手动故障转移时的行为相同。对于异步提交模式的辅助副本，无论数据是否已经达到同步，它永远只会处于 SYNCHRONIZING状态，于是它只能支持强制故障转移这一种形式。
自动故障转移形式
自动故障转移使得AlwaysOn可用组成为了一种高可用方案，确保在丢失主副本之后快速使数据库再次变为可用。要发生自动故障转移，要满足这些条件：
· 当前主副本和一个辅助副本都设置为同步提交模式以及自动故障转移模式。
· 辅助副本必须与主副本同步。即辅助数据库处于SYNCHRONIZED状态.
· 主副本变得不可用，此时将发生自动故障转移。
当发生自动故障转移时，整个步骤是：
1. 如果运行当前主副本的副本实例仍在运行，则它会将主副本和辅助副本的连接状态更改为 DISCONNECTED 并断开所有客户端的连接。
2. 如果在故障转移目标副本上还有任何日志记录处于重做队列中，辅助副本会继续执行重做，以完成对辅助数据库的前滚操作。
3. 完成前滚操作后，辅助副本就转换为了主副本，其数据库成为了主数据库。新的主副本将尽快回滚任何未提交的事务。
4. 新的主副本在连接到一个辅助副本形成新的对话之前，会把自己置为 NOT SYNCHRONIZED状态。无论回滚操作是否已经结束，只要有辅助副本可以连接到新的主副本，主数据库就会转换为 SYNCHRONIZED 状态。
5. 当原来的主副本解决了故障重新开始运行后，它会发现其他某个可用性副本现在变成了主副本，于是它就把自己转换为辅助副本，将其数据库将成为辅助数据库。当新的辅助数据库连接上新的主数据库后，辅助数据库就开始进行同步来赶上主数据库的日志末尾。
手动故障转移形式
当主副本和辅助副本连接在一起并且数据库处于SYNCHRONIZED状态，就可以执行手动故障转移。如果辅助副本停止运行，主副本不会受到影响。如果主副本停止运行，辅助副本将进入一种特殊的角色 –“ RESOLVING”角色（注意，RESOLVING是可用性副本的一种角色，而不是它所处的状态）。此时该副本既不是主副本也不是辅助副本，但你可以执行强制故障转移把辅助副本转换成主副本，不过你可能会因此承受数据损失。
当发生手动故障转移时，整个步骤和自动故障转移基本是一样的。它们的区别仅仅是在“谁触发了故障转移”。
你有四种途径来执行手动故障转移：
1. 通过Windows的故障转移群集管理器来切换可用性组所在的资源组
2. 通过T-SQL语句
3. 通过SQL Server ManagementStudio使用UI来进行手动故障转移。
4. 使用Powershell脚本。
只有设置为自动故障转移模式的可用性副本才允许通过Windows的故障转移管理器来切换主副本所在的实例。如果辅助副本没有设置自动故障转移模式，那么你只能使用其余三种途径来执行手动故障转移。
强制故障转移形式
从数据安全的角度来讲，强制故障转移是一个风险很大的操作。一旦执行了强制故障转移，主副本尚未发送到原来的辅助副本的任何事务日志都会丢失。这意味着，新的主数据库可能会缺少一些最近提交的数据。需要特别注意的是，强制故障转移后，剩余的所有辅助副本上的辅助数据库都处于挂起状态。在最坏的情况下，你可能需要重新初始化所有的辅助副本才能重新恢复可用性组。举例来说，假设你有三个可用性副本，主副本A和一个辅助副本B是同步提交模式，另一个辅助副本C是异步提交模式。当主副本A和辅助副本B的日志都比辅助副本C更加新的时候（这很容易发生），你执行了强制故障转移把主副本转移到C上。于是新的主副本C的日志晚于其余两个副本，这使得副本A和B无论如何都无法继续和副本C的对话。要重新恢复三个副本的配置，你必须以某个副本上的数据库为基础，重新在三个副本上配置可用性组。
你只能通过SQLServer Management Studio来执行强制故障转移。在转移开始前，SQLServer Management Studio会通过向导来和你确认你是否已经了解且愿意接受强制故障转移可能带来的后果。
多子网可用性组的故障转移
可用性组支持多子网环境，即可用性副本可以处于不同的子网当中。在2.2.5节介绍过，多子网的SQLServer群集一旦发生了故障转移，为了使得客户端能够更快的重新连接到新的活跃节点，你可以在连接字符串中使用MultiSubnetFailover参数并将其置为true。对于多子网的可用性组而言，在客户端程序中使用MultiSubnetFailover参数也能帮助客户端在可用性组发生不同子网间的故障转移时快速的恢复连接。要使用MultiSubnetFailover参数，除了客户端要使支持该参数的驱动程序之外，你还必须要使用TCP协议并通过Listener来连接可用性副本。
无论可用性组是单子网还是多子网，都建议在客户端的连接字符串中将MultiSubnetFailover设置为true。对于单子网的环境，MultiSubnetFailover能够为迁移至多子网环境做好预先准备。一旦发生这样的迁移，你无需再去更改连接字符串。
Split Brain（大脑分裂）
在理论上，如果发生故障转移，原先的主副本会先离线，然后某个辅助副本会上线。网络里不会同时出现两个主副本。但是在意外情况下，如果原先的主副本还没有离线，新的主副本就上线了，那一个可用组就出现了两个主副本。客户端可以连接其中的任何一个，做数据修改动作。就像人的大脑，被分裂成了两个。所以这种情况被起名为SplitBrain（大脑分裂），是AlwaysOn要坚决杜绝的。所以在可用性组资源的属性中，你还能看到一个叫做LeaseTimeout的属性。Windows群集服务会定期跟它认为的主副本通信。如果主副本在”LeaseTimeout”之前没有收到Windows群集服务的消息，它就自认为自己已经被群集服务切换掉了。这个SQLServer会自动终止自己的运行。因为Windows群集服务在任何一个时间点只会认定一个主副本，所以这样的方法可以避免“大脑分裂”。
连接、可用性副本和可用性数据库的状态
在前面的介绍中，你会发现AlwaysOn中的各种对象在不同的情况会处于各自不同的状态。如果你已经眼花缭乱的话，这里我们做一个小小的归纳。
连接状态：
· Disconnected – 说明辅助副本和主副本间已经断开了连接。
o 如果主副本发现辅助副本断开了和它的连接，在主副本上会将那些辅助副本上的辅助数据库标记为“未同步”，主副本等待辅助副本重新连接。
o 当辅助副本检测到它和主副本的连接断开后，辅助副本会尝试重新连接主副本。
· Connected - 辅助副本和主副本间连接正常
可用性副本状态：
· NotSynchronized - 副本中的一个或多个数据库未同步或尚未联接到可用性组。
· Synchronizing - 正在同步副本中的一个或多个数据库。
· Synchronized - 辅助副本中的所有数据库均与主副本主副本上的相应主数据库同步。
注意，不要将可用性副本的状态和可用性副本的角色（Primary,secondary, resolving）搞混。
可用性数据库状态：
· Not synchronizing
o 如果是主数据库处于该状态，说明该数据库未做好准备将其事务日志与相应的辅助数据库进行同步。
o 如果是辅助数据库处于该状态，说明数据库可能（1）由于连接问题或者重做失败，不再进行日志同步，（2）和主数据库的日志同步被“挂起”，（3）由于角色切换，正处于转换的中间状态。
· Synchronizing
o 如果是主数据库处于该状态，说明该数据库已做好接受来自辅助数据库的同步请求的准备。
o 如果是辅助数据库处于该状态，说明该辅助数据库和主数据之间有正在进行同步的数据。
· Synchronized
o 如果是主数据库处于该状态，说明它至少同步了一个辅助数据库。
o 如果是辅助数据库处于该状态，说明该数据库与相应的主数据库保持同步。
要注意，在异步提交模式下，可用性数据库和可用性副本永远不会处于“Synchronized”状态。
相对数据库镜像，AlwaysOn的一个重要优势就是可以将辅助数据库配置成可读模式。这极大地增强了数据库整体的伸缩性。通过将只读请求分流到辅助数据库，主副本的工作负载得到了减轻，读和写之间的冲突可以得到缓解，辅助副本的硬件资源也能得到利用。同时，通过AlwaysOn的“只读路由”功能，只读操作可以动态地被转向辅助副本。在一定程度上，可以实现对终端用户透明。利用这个功能，SQLServer可以实现工作负荷的Scale-out（由多台SQLServer同时响应客户端发来的工作负载）。对于高端应用，这的确是一个令人激动人心的新功能。
当然，主副本的数据和辅助副本上查询到的数据可能会存在一定程度的滞后。通常情况下，只要AlwaysOn工作正常，这个滞后时间一般都很短。当辅助数据库I/O较慢或者副本之间网络状况不佳的情况下，滞后时间可能会比较长。当辅助副本的数据移动挂起的时候，滞后时间就更长了。如果应用的读操作不能容忍任何程度的数据滞后，操作还是只能放在主副本上运行。
要让只读操作能“透明”地被自动转向辅助副本，必须解决下面三个问题：
1. 客户端要标明自己发来的操作是“只读”操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的。而不是SQL Server端来判定的。
2. 辅助数据库要被配成可读模式。
3. 客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用“只读路由”机制来实现的。
下面来详细介绍这几个问题。
ApplicationIntent关键字
为了支持AlwaysOn可用性组的可读辅助数据库功能，连接SQLServer 2012实例的客户端可以使用新的关键字“ApplicationIntent”来表示客户端发出请求的类型：“读/写”或是“只读”。这个关键字只能被设置为以下两个值中的一个。
ApplicationIntent=ReadOnly
ApplicationIntent=ReadWrite
目前支持该关键字的驱动有：
· SQLNCLI11 ODBC和OLEDB
· .NET Framework 4.5和4.0中System.Data.SqlClient
· Microsoft JDBC Driver for SQL Server 4.0
设置ApplicationIntent关键字的方法取决于你使用的客户端工具。如果是一个自己开发的应用程序，就需要在连接字符串中指定这个关键字，例如：
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
如果是SQLServer Management Studio的话，你可以在连接属性中加入ApplicationIntent关键字。
可用性副本的可读模式设定
你可以为每个可用性副本设置其作为主角色时的连接访问类型和其作为辅助角色时的连接访问类型。
在创建AlwaysOn可用性组的时候，就可以为每个副本设定其作为辅助角色的连接访问类型，在可用性组运行时也能随时对其进行更改。连接访问类型决定该辅助副本上的可用性数据库是否可以接受读操作。
辅助角色的连接访问类型分为3种：
1. NONE：辅助数据库不接受任何类型的数据访问。
2. READ_ONLY：当连接字符串中的Application Intent属性被设置成ReadOnly时，能被访问。
3. ALL。任何连接都可以连接辅助数据库，但是通过这个连接，只有读请求才能够成功执行。任何尝试写数据库的请求都会失败。这个选项主要是用于那些无法使用ApplicationIntent关键字的客户端。
ApplicationIntent并不能保证从该连接上发出的请求都一定是读操作。它只是表示了该连接上“应当”发生的请求类型。因此无论把访问类型设置为ALL或者READ_ONLY，客户端程序都可能通过这个连接发送写请求到辅助数据库上。
主副本上也有两种设置，只能在可用性组创建完毕后，以通过修改可用性副本的属性来完成。主角色的连接访问类型有两种。
1. ALL：主数据库同时允许读写连接和只读连接。这是主角色的默认行为。
2. READ_WRITE：当连接字符串的ApplicationIntent 关键字设置为 ReadWrite 或未设置时，允许此连接。不允许连接字符串ApplicationIntent关键字设置为 ReadOnly 的连接。
当主副本设置为Read_Write时，如果一个客户端连接字符串ApplicationIntent关键字设置为ReadOnly，又要指定连接主副本，那这个连接会被拒绝。这样的设计会保证主副本不被应该由辅助副本完成的应用负载所干扰。
只读路由
你有两种方法来连接可读的辅助数据库。
· 客户端应用可以指定辅助副本的真实实例名，直接连接到该实例上。当辅助副本的连接访问选项设置为ALL时，客户端的连接字符串不用做任何特殊设置。当辅助副本设成READONLY时，客户端需要将ApplicationIntent设置为ReadOnly。由于是直接连接辅助数据库，不会发生任何的连接重定向。
· AlwaysOn有一个叫做的只读路由（Read-Only Routing）的功能。当客户端连接使用Listener的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。客户端应用程序只需要确保连接的服务器名是Listener的名字，而无需去关心背后到底是哪个副本响应这个请求。这个功能可以自动分流一部分主副本的工作负载，使得主副本有更多的资源处理其他读写请求。
如果可用性组有多个副本的话，你无法保证只读路由始终将所有连接全部重定向到相同的只读副本上。副本的运行状态的变化，副本的路由配置发生更改等因素都可能导致客户端连接到不同的只读副本。若要确保所有只读请求都连接到相同的只读副本，请使用指定可读辅助副本的实例名的方式来进行连接，而不要依靠只读路由。
实现只读路由功能需要以下条件：
1. 客户端应用程序使用TCP协议，通过Listener连接到主副本，而非直接通过主副本的实例名。
2. 客户端应用程序的连接字符串中，将ApplicationIntent属性设置为了ReadOnly。
3. 至少有一个辅助副本被配置为可读辅助副本，且其连接访问设置必须是ALL或者READONLY。
4. 已经为可用性副本配置了只读路由。这包括：
（1） 为每个副本设置一个只读路由URL（read-only routing URL）。
（2） 为每个副本设置其作为主副本时的只读路由列表（read-only routing list）。
接下来详细介绍一下只读路由URL和只读路由列表。只读路由URL是一个如下形式的字符串：
'TCP://servername.domain.com:1433'
可以看出这个URL其实就是一个端点的形式。通常这个端点指向的就是副本本身。因此你要保证客户单可以通过URL中的服务器名和端口号来访问到这个副本。这个字符串会由主副本通过“重定向TDS”送回给客户端。
只读路由列表是一个表示可用性副本优先级的列表。在列表中的副本的名字都使用短名字。假设有一个包含3个副本(Node1,Node2和Node3)的可用性组。在Node1上的路由列表可能是这样的：
'Node3','Node2'
这个列表表示只读请求会先被重定向到Node3。当Node3不可用的时候，请求就会被重定向到Node2。而Node2上的列表可能会是这样的：
'Node3', 'Node1'
您必须先设置只读路由URL，然后才能配置只读路由列表。
以下是一段联机丛书上的示例TSQL语句，用来展示如果在两副本的可用性组上配置只读路由URL和只读路由列表。假设这两个副本分别叫Computer01和Computer02。
只读路由使用以下过程来决定将只读请求重定向到哪台辅助副本。
前提条件：客户端在连接字符串中指定ApplicationIntent=ReadOnly，并且用Listener来连接可用性组。（如果不符合这两个条件，只读路由将不会工作。）
1. 连接请求会首先被指向到主副本上。
2. 主副本检查目标数据库，确认该数据库属于某个可用性组。
3. 如果数据库属于可用性组，再检查主副本上是否配置了只读路由列表。如果没有配置只读路由列表，那么只读路由还是不会工作。
4. 如果发现了只读路由列表，主副本就会按照列表的顺序依次检查每个副本，直到发现第一个连接访问设置为READONLY或ALL的可用副本为止。
5. 主副本把发现的那个副本的只读路由URL通过TDS包发还给客户端。
6. 客户端读取URL后即重新将自己定向到那个只读辅助副本。
所以对于每个用Listener名字发出的只读连接，它会先到主副本上转一圈，拿到只读辅助副本的URL以后，再连接到真正的辅助副本上。
辅助数据库上可能的性能问题
一个可读的辅助副本可能会同时受到读操作和写操作。读操作来自于直接连接它的客户端或者通过只读路由被重定向到它的客户端。而写操作只会来自于主数据库和辅助数据库之间的数据库同步。辅助数据库只有在重做日志的时候才会发生数据更改。客户端无法直接在辅助数据库上执行数据修改操作。
像其他所有数据库一样，只读辅助数据库也有可能遇到性能问题。由于其工作方式的特殊性，其性能问题也有所不同：
1. 使用行版本控制来消除阻塞问题
由于存在读写同时发生的可能性，在辅助数据库上可能会发生阻塞问题。为了保障读操作的稳定运行和性能，AlwaysOn使用行版本控制来消除辅助数据库上的阻塞问题。对辅助数据库运行的所有查询都会被自动运行在快照隔离级别之下。即使你显式的为查询设置了其他事务隔离级别，情况也是如此。此外，所有锁定提示（LockHint）都将被忽略。这些都有助于消除了读写操作互相争抢锁定数据所造成的阻塞问题。
虽然由于快照隔离级别的原因，读操作不会在数据上占用共享锁，但是快照隔离级别会导致读操作占用Sch-S锁。Sch-S锁还是会阻塞那些在辅助数据库上重做的DDL语句。因为那些DDL语句需要占用Sch-M锁，而Sch-M锁和Sch-S锁是互斥的。
除了阻塞，读操作的Sch-S锁还可能造成和写操作之间的死锁问题。为了保证数据同步的完整性，AlwaysOn规定来自于数据同步（重做日志）所做的写操作永远不会被选为死锁的牺牲者，无论该写操作的代价是多小。
2. 系统资源的争抢
如果读操作比较复杂，其所带来的CPU和IO的负载也可能会影响辅助数据库上重做操作的性能。因此，如果你有一个需要长时间运行的只读操作，最好还是安排在非业务高峰时间来运行会比较好。
3. 索引
为了优化在可读辅助数据库上所执行的查询语句的性能，你需要在数据库上创建合适的索引。由于你无法在辅助数据库运行创建索引的命令，你需要在主数据上创建所需要的索引，然后让同步操作把索引给同步到辅助数据库上去。
4. 统计信息
统计信息对于查询操作的性能也有非常大的影响。正确的统计信息才能产生优化的执行计划。和索引一样，你只能在主数据上创建和维护统计信息，然后将统计信息的变更同步到辅助数据库上。当主数据上没有统计信息，或者统计信息已经很过时不再用适用于生成优化的只读操作执行计划的时候，你无法在辅助数据库上创建或更新统计信息。但是，辅助副本会在tempdb 中创建和维护辅助数据库的“临时统计信息”，用它们来替代过时的永久统计信息。一旦主数据库上的永久统计信息被更新了，辅助数据库上的永久统计信息也会被更新。这时，辅助数据库就会开始使用更新的永久统计信息，因为该信息比临时统计信息要新。
临时统计信息的名称会带有后缀“_readonly_database_statistic”，用于将其和主数据库上保存的永久统计信息区分开来。后缀_readonly_database_statistic 是保留关键字，在主数据库上手动创建统计信息时不能使用此后缀。只有SQL Server本身才能够创建和更新辅助数据库上的临时统计信息。但是，你可以在辅助副本的tempdb中使用DROPSTATISTICS Transact-SQL 语句删除临时统计信息。你也可以在辅助副本上查询sys.stats和sys.stats_columns 视图，来监视统计信息的状况。sys_stats 包含一个is_temporary 列，用于指示哪些统计信息是永久的，哪些统计信息是临时的。
因为临时统计信息保存在tempdb 中，所以重启SQL Server 服务会导致所有临时统计信息丢失。如果可用性组发生故障转移，所有辅助副本上临时统计信息都会被删除。
可读辅助副本会占用一部分tempdb的空间。临时统计信息，以及快照隔离级别的行版本信息都保存在辅助副本的tempdb中。因此对于辅助副本的tempdb需要进行合理的配置和优化，用以优化辅助副本的性能表现。
SQL Server 2012提供了非常多的信息来方便你监视可用性组的运行状态。
系统视图和动态管理视图
首先，AlwaysOn提供了大量的系统视图和动态管理视图，可以通过视图来监视以下对象的状态：
（1） 可用性组所在的Windows故障转移群集
· sys.dm_hadr_cluster
· sys.dm_hadr_cluster_members
· sys.dm_hadr_cluster_networks
· sys.dm_hadr_instance_node_map
· sys.dm_hadr_name_id_map
（2） 可用性组
· sys.availability_groups
· sys.availability_groups_cluster
· sys.dm_hadr_availability_group_states
（3） 可用性副本
· sys.availability_replicas
· sys.availability_read_only_routing_lists
· sys.dm_hadr_availability_replica_cluster_nodes
· sys.dm_hadr_availability_replica_cluster_states
· sys.dm_hadr_availability_replica_states
· sys.fn_hadr_backup_is_preferred_replica
（4） 可用性数据库
· sys.availability_databases_cluster
· sys.databases (添加了replica_id，group_database_id列来兼容AlwaysOn)
· sys.dm_hadr_auto_page_repair
· sys.dm_hadr_database_replica_states
· sys.dm_hadr_database_replica_cluster_states
（5） 可用性组的Listener
· sys.availability_group_listener_ip_addresses
· sys.availability_group_listeners
· sys.dm_tcp_listener_states
由于篇幅的限制，这里无法对每个视图都详细的介绍。要获取更详细的信息，你可以参考SQLServer的联机丛书。
性能计数器
AlwaysOn引入了两个性能监视器的对象：SQLServer:AvailabilityReplica和SQLServer:Database Replica。每个对象下面都有一些性能计数器用来让你了解当前可用性组运行的健康状况和性能表现。
SQLServer:AvailabilityReplica：当你在性能监视器中选中某个AvailabilityReplica对象的计数器后，计数器实例名会显示为
SQLServer:DatabaseReplica：当在性能监视器中选中某个Database Replica对象的计数器后，每个参数副本的数据库都成为一个计数器实例。假设可用性组ag拥有可用性副本AlwaysOn1，且ag包含3个可用性数据库agdb1,agdb2和agdb3。一旦你选中了SQLServer:DatabaseReplica下的某个技术器后，你就可以看到分别代表agdb1,agdb2和agdb3三个的计数器实例。你可以决定选择某个数据库或者所有数据库进行监视。
Database Replica and Availability Replica 下的计数器所包含的信息，有的是对主副本和辅助副本都有意义的，而有的可能只对某种角色的副本有意义。举例来说，Database Replica:Log Send Queue 计数器是用来标示主副本上还有多少没被送到辅助副本上的日志块的。你只有在辅助副本上观察这个计数器才有意义，因为不同的辅助副本未收到的日志块数量可能是不同的。
下面这个表格列举了每种计数器应当在哪种角色的副本上进行监视。
|
Counter |
Primary |
Secondary |
|
Availability Replica: Sends to Replica / Sec |
X |
X |
|
Availability Replica: Receives from Replica / Sec |
X |
X |
|
Availability Replica: Bytes Sent to Replica / Sec |
X |
X |
|
Availability Replica: Bytes Received from Replica / sec |
X |
X |
|
Availability Replica: Sends to Transport / sec |
X |
X |
|
Availability Replica: Bytes Sent to Transport / sec |
X |
X |
|
Availability Replica: Resent Messages / sec |
X |
X |
|
Availability Replica: Flow Control Time |
X |
|
|
Availability Replica: Flow Control / sec |
X |
|
|
Database Replica: Redo Bytes Remaining |
X |
|
|
Database Replica: Log Bytes Received / sec |
X |
|
|
Database Replica: File Bytes Received / sec |
X |
|
|
Database Replica: Log Remaining to Undo |
X |
|
|
Database Replica: Total Log Requiring Undo |
X |
|
|
Database Replica: Redone Bytes / sec |
X |
|
|
Database Replica: Recovery Queue |
X |
|
|
Database Replica: Log Send Queue |
X |
|
|
Database Replica: Transaction Delay |
X |
|
|
Database Replica: Mirrored Write Transactions / sec |
X |
表3-2不同角色的可用性副本可使用的AlwaysOn性能计数器
DashBoard
一旦你创建了一个可用性组，你就可以使用AlwaysOn的DashBoard。DashBoard用来监视可用性组，副本和数据库的健康状况。DashBoard是一个将各种信息集中在一体的报表，它不但本身包含丰富的信息，而且通过它你还能转向到其他的日志（AlwaysOn_health事件,SQL错误日志,Windows 群集日志以及Windows事件日志等），以获得更进一步的分析信息。
要打开Dashboard，你只需要在SQLServer Management Studio中选中所想要监视的可用性组，然后点击右键选择“ShowDashboard”.
在Dashboard报表中，可用性组的健康状况是基于AlwaysOn的系统策略（SystemPolicy）评估出来的。可用性组、可用性副本和数据库都会显示其各自的健康状态。在下面的图中，可用性组，可用性副本和数据库的状态都是“健康”。
你可以通过SQLServer Management Studio找到所有AlwaysOn的系统策略以及每个策略所对应的系统条件。
Dashboard中其余的信息都来自于AlwaysOn的动态管理视图。你可以对DashBoard进行客制化，在可用性副本和数据库级别添加你想要的其他信息。例如，你可以在Dashboard中的可用性组列表的列名处点击右键，这样你就能看到所有可以加入到该列表中的额外数据列。这些可额外添加的数据列大部分都能直接对应到动态管理视图中相应的列上。
AlwaysOn_health 会话
AlwaysOn_health会话是SQL Server 2012自带的扩展事件对话。当你通过SQL ServerManagement Studio中的向导创建可用性组之后，这个会话会被启动。如果你使用的是T-SQL或者Powershell脚本创建可用行组的话，那么该会话不会启动。
AlwaysOn_Health会话会在SQL Server的LOG目录下生成一系列名为“AlwaysOn_health_<序号>_<创建时间>.xel”的扩展事件日志文件。该事件日志文件会记录一些重要的事件，例如可用性副本/数据库的状态变化，Failover条件的改变，副本间同步状况变化等等。它还会记录AlwaysOn自身发生的错误，以及任何可能会影响可用性组健康状况的操作系统问题或SQLServer数据库引擎问题。
另一个SQLServer 2012自带的扩展事件对话是System_Health。该对话会在SQLServer的LOG目录下生成一系列名为“system_health_<序号>_<创建时间>.xel”的扩展事件日志文件。System_Health扩展事件日志和AlwaysOn无关，它的作用类似于SQL Server的默认Trace。SQL Server一旦启动，该扩展事件日志文件就会开始自动捕获它所关心的信息。该日志收集的数据也能帮助你对数据库引擎的性能问题进行故障排除。自动捕捉的信息包括：
· 发生严重性 >=20 的错误的任何会话的 sql_text 和 session_id。
· 发生与内存有关的错误的任何会话的 sql_text 和 session_id。 这些错误包括17803、701、802、8645、8651、8657 和 8902。
· 任何无法完成的计划程序问题的记录。 （这些问题在 SQL Server 错误日志中显示为错误 17883。）
· 检测到的任何死锁。
· 等待闩锁（或其他相关资源）的时间 > 15 秒的任何会话的 callstack、sql_text 和session_id 。
· 等待锁的时间 > 30 秒的任何会话的 callstack、sql_text 和session_id 。
· 已长时间等待以获得抢先等待的任何会话的 callstack、sql_text 和session_id。 持续时间因等待类型而异。 在抢先等待中，SQL Server 等待的是外部 API 调用。
SQLDIAG扩展事件日志
前面我们已经讲过SQLServer 2012故障转移群集使用sp_server_diagnostics来获取诊断信息，并且会把sp_server_diagnostics返回的信息也会被记录到SQLDIAG扩展事件日志文件中。详细信息参见2.1.6章节。
sp_server_diagnostics也负责AlwaysOn可用性组的健康状况检查。同样的，sp_server_diagnostics返回的信息依旧会被记录到SQLDIAG日志里。我们也可以通过检查SQLDIAG文件中记录的信息来对可用性发生的异常状况进行排查。例如，我们可以通过SQLDIAG中记录的SQLServer实例的资源使用情况来判断是否是由于资源瓶颈导致了可用性发生了故障切换。
SQL Server 2012 Management Studio能够直接打开后缀为.xel的扩展事件日志文件，打开日志之后，你不但能够浏览事件信息，而能对它们进行聚合、分组、过滤等操作。
图3-32在SQLServer Management Studio中打开SQLDIAG扩展事件日志
通过前面的介绍，你可以发现AlwaysOn是一项集合了故障转移群集、数据库镜像和日志传送的优点于一身的、功能强大的“高可用性+灾难恢复”技术。有了它，你不需要通过结合多种技术，就可以获得一个或多个和本地完全同步的远程数据副本，像群集一样，副本之间可以进行自动故障转移，同时还可以对客户端完全透明。通过AlwaysOn来构架方案，能够降低部署的难度以及后期维护的复杂度。如果你对你的SQLServer数据库系统的可用性和灾难恢复能力有很高的要求，相信AlwaysOn一定会成为你的首选。
在本节的最后，让我们再来将AlwaysOn同第二章介绍的各项技术做一个横向的对比。通过比较，你能更加直观的看到AlwaysOn的优势所在。
|
功能 |
故障转移群集 |
日志传送 |
数据库镜像 |
事务复制 |
AlwaysOn |
|
保护级别 |
实例级 |
数据库级 |
数据库级 |
数据库对象级 |
数据库级 |
|
是否有数据损失 |
/ |
可能有少量数据损失 |
无数据损失（同步模式） |
可能有少量数据损失 |
无数据损失（同步提交模式） |
|
自动故障转移 |
是 |
否 |
是（高可用操作模式） |
否 |
是（自动故障转移模式） |
|
故障转移后是否可逆 |
是 |
否 |
是 |
否 |
是 |
|
对客户端是否透明 |
是，自动重连接到相同IP的另一个节点 |
否 |
是，自动重定向（需要驱动程序支持） |
否 |
是 |
|
停机时间 |
约等于SQL Server服务重启的时间+数据库恢复时间 |
较长 |
约等于数据库恢复时间 |
较长 |
约等于数据库恢复时间 |
|
多个备用数据副本 |
否 |
是 |
否 |
是 |
是（最大4个） |
|
备用数据副本可读 |
/ |
是 |
否 |
是 |
是 |
|
能抵御用户误操作 |
否 |
是 |
否 |
否 |
否 |
|
能抵御磁盘故障 |
否 |
是 |
是 |
是 |
是 |
|
是否有特定硬件要求 |
windows群集 |
无 |
要求有较好的磁盘和网络 |
无 |
Windows群集 |
|
对性能的影响 |
低 |
中 |
中 |
高 |
中 |
|
其他功能 |
/ |
自动页面修复 |
/ |
冲突解决，双向数据同步等 |
自动页面修复，只读路由，辅助数据库备份，辅助数据库执行DBCC命令 |
|
版本支持 |
SQL Server 2000及以后 |
SQL Server 2000及以后 |
SQL Server 2005及以后 |
SQL Server 2000及以后 |
SQL Server 2012 |
