SQL Server AG - 0. SQLServer AlwaysOn理论基础(2)

• 可读的辅助数据库

From: http://book.2cto.com/201304/19874.html

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

当然，主副本的数据和辅助副本上查询到的数据可能会存在一定程度的滞后。通常情况下，只要AlwaysOn工作正常，这个滞后时间一般都很短。当辅助数据库I/O较慢或者副本之间网络状况不佳的情况下，滞后时间可能会比较长。当辅助副本的数据移动挂起的时候，滞后时间就更长了。如果应用的读操作不能容忍任何程度的数据滞后，操作还是只能放在主副本上运行。

要让只读操作能“透明”地被自动转向辅助副本，必须解决下面三个问题：

客户端要标明自己发来的操作是“只读”操作。这个判定是程序开发员在编写程序的时候，通过ApplicationIntent关键字指定的。而不是SQL Server端来判定的。

辅助数据库要被配成可读模式。

客户端的连接，要能够被重定向到可读辅助副本。AlwaysOn是用“只读路由”机制来实现的。
下面来详细介绍这几个问题。

1．ApplicationIntent关键字

为了支持AlwaysOn可用性组的可读辅助数据库功能，连接SQL Server 2012实例的客户端可以使用新的关键字“ApplicationIntent”来表示客户端发出请求的类型：“读/写”或是“只读”。这个关键字只能被设置为以下两个值中的一个。

ApplicationIntent=ReadOnly

ApplicationIntent=ReadWrite

目前支持该关键字的驱动有：

SQLNCLI11 ODBC和OLEDB

.NET Framework 4.5、4.0和3.5.1中的System.Data.SqlClient

Microsoft JDBC Driver for SQL Server 4.0

设置ApplicationIntent关键字的方法取决于你使用的客户端工具。如果是一个自己开发的应用程序，就需要在连接字符串中指定这个关键字，例如：

Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly;MultiSubnetFailover=True

如果是SQL Server Management Studio，你可以在连接属性中加入ApplicationIntent关键字，如图3-25所示。

 

2．可用性副本的可读模式设定

你可以为每个可用性副本设置其作为主角色时的连接访问类型和其作为辅助角色时的连接访问类型。

在创建AlwaysOn可用性组的时候，就可以为每个副本设定其作为辅助角色的连接访问类型，在可用性组运行时也能随时对其进行更改。连接访问类型决定该辅助副本上的可用性数据库是否可以接受读操作。

辅助角色的连接访问类型分为如下3种。

NONE：辅助数据库不接受任何类型的数据访问。

READ_ONLY：当连接字符串中的Application Intent属性被设置成ReadOnly时，能被访问。

ALL：任何连接都可以连接辅助数据库，但是通过这个连接，只有读请求才能够成功执行。任何尝试写数据库的请求都会失败。这个选项主要是用于那些无法使用ApplicationIntent关键字的客户端。

ApplicationIntent并不能保证从该连接上发出的请求都一定是读操作。它只是表示了该连接上“应当”发生的请求类型。因此无论把访问类型设置为ALL或者READ_ONLY，客户端程序都可能通过这个连接发送写请求到辅助数据库上。由于可读辅助数据库是不允许写操作的，客户端会收到如图3-26所示的错误信息。

 

主副本上也有两种设置，只能在可用性组创建完毕后通过修改可用性副本的属性来完成。主角色的连接访问类型有两种。

ALL：主数据库同时允许读写连接和只读连接。这是主角色的默认行为。

READ_WRITE：当连接字符串的Application Intent 关键字设置为 ReadWrite 或未设置时，允许此连接。不允许连接字符串Application Intent关键字设置为 ReadOnly 的连接。

当主副本设置为Read_Write时，如果一个客户端连接字符串Application Intent关键字设置为 ReadOnly，又要指定连接主副本，那这个连接会被拒绝。这样的设计会保证主副本不被应该由辅助副本完成的应用负载所干扰。

3．只读路由

你有两种方法来连接可读的辅助数据库。

客户端应用可以指定辅助副本的真实实例名，直接连接到该实例上。当辅助副本的连接访问选项设置为ALL时，客户端的连接字符串不用做任何特殊设置。当辅助副本设成READONLY时，客户端需要将ApplicationIntent设置为ReadOnly。由于是直接连接辅助数据库，所以不会发生任何的连接重定向。

AlwaysOn有一个叫作只读路由（Read-Only Routing）的功能。当客户端连接使用Listener的名字来访问SQL Server实例时，只读路由功能可以将来自客户端的只读请求从主副本上自动重定向到可读的辅助副本上去执行。客户端应用程序只需要确保连接的服务器名是Listener的名字，而无须去关心背后到底是哪个副本响应这个请求。这个功能可以自动分流一部分主副本的工作负载，使得主副本有更多的资源处理其他读写请求。

如果可用性组有多个副本，你无法保证只读路由始终将所有连接全部重定向到相同的只读副本上。副本的运行状态的变化，副本的路由配置发生更改等因素都可能导致客户端连接到不同的只读副本。若要确保所有只读请求都连接到相同的只读副本，请使用指定可读辅助副本的实例名的方式来进行连接，而不要依靠只读路由。

实现只读路由功能需要以下条件：

客户端应用程序使用TCP协议，通过Listener连接到主副本，而非直接通过主副本的实例名。

客户端应用程序的连接字符串中，将ApplicationIntent属性设置为ReadOnly。

至少有一个辅助副本被配置为可读辅助副本，且其连接访问设置必须是ALL或者READONLY。

已经为可用性副本配置了只读路由。这包括：

为每个副本设置一个只读路由URL（read-only routing URL）。

为每个副本设置其作为主副本时的只读路由列表（read-only routing list）。

接下来详细介绍一下只读路由URL和只读路由列表。只读路由URL是一个如下形式的字符串：

'TCP://servername.domain.com:1433'

可以看出这个URL其实就是一个端点的形式。这里的端点不同于用作数据同步和发送接收ping的端点，它的作用是使得客户端可以通过URL中的服务器名和端口号来访问到这个副本，因此这个端点所指定的端口号其实就是你在配置管理器中设定的SQL Server监听的TCP端口。这个URL会由主副本通过“重定向TDS”送回给客户端。

只读路由列表是一个表示可用性副本优先级的列表。在列表中的副本的名字都使用短名字。假设有一个包含3个副本（Node1、Node2和Node3）的可用性组。在Node1上的路由列表可能是这样的：

'Node3','Node2'

这个列表表示只读请求会先被重定向到Node3。如果Node1和Node3之间的ping失败的话，Node1就认为Node3此时是不可用，因此只读请求就会按顺序被重定向到列表中的下一个节点，也就是Node2。而Node2上的列表可能会是这样的：

'Node3', 'Node1'

你必须先设置只读路由URL，然后才能配置只读路由列表。

以下是一段联机丛书上的示例TSQL语句，用来展示如果在两副本的可用性组上配置只读路由URL和只读路由列表。假设这两个副本分别叫Computer01和Computer02。

 

只读路由使用以下过程来决定将只读请求重定向到哪台辅助副本。

前提条件：客户端在连接字符串中指定ApplicationIntent=ReadOnly，并且用Listener来连接可用性组。（如果不符合这两个条件，只读路由将不会工作。）

  连接请求会首先被指向到主副本上。

  主副本检查目标数据库，确认该数据库属于某个可用性组。

  如果数据库属于可用性组，再检查主副本上是否配置了只读路由列表。如果没有配置只读路由列表，那么只读路由还是不会工作。

  如果发现了只读路由列表，主副本就会按照列表的顺序依次检查每个副本，直到发现第一个连接访问设置为READONLY或ALL并且可用的副本（彼此之间的ping正常）为止。

  主副本把发现的那个副本的只读路由URL通过TDS包发还给客户端。

  客户端读取URL后即重新将自己定向到那个只读辅助副本。

所以对于每个用Listener名字发出的只读连接，它会先到主副本上转一圈，拿到只读辅助副本的URL以后，再连接到真正的辅助副本上。

4．辅助数据库上可能出现的性能问题

一个可读的辅助副本可能会同时受到读操作和写操作。读操作来自于直接连接它的客户端或者通过只读路由被重定向到它的客户端。而写操作只会来自于主数据库和辅助数据库之间的数据库同步。辅助数据库只有在重做日志的时候才会发生数据更改。客户端无法直接在辅助数据库上执行数据修改操作。

像其他所有数据库一样，只读辅助数据库也有可能遇到性能问题。由于其工作方式的特殊性，其性能问题也有所不同。

（1）使用行版本控制来消除阻塞问题

由于存在读写同时发生的可能性，在辅助数据库上可能会发生阻塞问题。为了保障读操作的稳定运行和性能，AlwaysOn使用行版本控制来消除辅助数据库上的阻塞问题。对辅助数据库运行的所有查询都会被自动运行在快照隔离级别之下。即使你显式的为查询设置了其他事务隔离级别，情况也是如此。此外，所有锁定提示（Lock Hint）都将被忽略。这些都有助于消除了读写操作互相争抢锁定数据所造成的阻塞问题。

虽然由于快照隔离级别的原因，读操作不会在数据上占用共享锁，但是快照隔离级别会导致读操作占用Sch-S锁。Sch-S锁还是会阻塞那些在辅助数据库上重做的DDL语句。因为那些DDL语句需要占用Sch-M锁，而Sch-M锁和Sch-S锁是互斥的。

除了阻塞，读操作的Sch-S锁还可能造成和写操作之间的死锁问题。为了保证数据同步的完整性，AlwaysOn规定来自于数据同步（重做日志）所做的写操作永远不会被选为死锁的牺牲者，无论该写操作的代价是多小。

（2）系统资源的争抢

如果读操作比较复杂，其所带来的CPU和IO的负载也可能会影响辅助数据库上重做操作的性能。因此，如果有一个需要长时间运行的只读操作，最好还是安排在非业务高峰时间来运行会比较好。

（3）索引

为了优化在可读辅助数据库上所执行的查询语句的性能，需要在数据库上创建合适的索引，由于无法在辅助数据库运行创建索引的命令，因此需要在主数据上创建所需要的索引，然后让同步操作把索引给同步到辅助数据库上。

5．统计信息

统计信息对于查询操作的性能也有非常大的影响。正确的统计信息才能产生优化的执行计划。和索引一样，你只能在主数据上创建和维护统计信息，然后将统计信息的变更同步到辅助数据库上。当主数据上没有统计信息，或者统计信息已经很过时不再用适用于生成优化的只读操作执行计划的时候，你无法在辅助数据库上创建或更新统计信息。但是，辅助副本会在 tempdb 中创建和维护辅助数据库的“临时统计信息”，用它们来替代过时的永久统计信息。一旦主数据库上的永久统计信息被更新了，辅助数据库上的永久统计信息也会被更新。这时，辅助数据库就会开始使用更新的永久统计信息，因为该信息比临时统计信息要新。

临时统计信息的名称会带有后缀“_readonly_database_statistic”，用于将其和主数据库上保存的永久统计信息区分开来。后缀_readonly_database_statistic是保留关键字，在主数据库上手动创建统计信息时不能使用此后缀。只有SQL Server本身才能够创建和更新辅助数据库上的临时统计信息。但是，你可以在辅助副本的tempdb中使用DROP STATISTICS Transact-SQL 语句删除临时统计信息。你也可以在辅助副本上查询sys.stats 和 sys.stats_columns 视图，来监视统计信息的状况。 sys_stats 包含一个 is_temporary 列，用于指示哪些统计信息是永久的，哪些统计信息是临时的。

因为临时统计信息保存在 tempdb 中，所以重启 SQL Server 服务会导致所有临时统计信息丢失。如果可用性组发生故障转移，所有辅助副本上临时统计信息都会被删除。

可读辅助副本会占用一部分tempdb的空间。临时统计信息，以及快照隔离级别的行版本信息都保存在辅助副本的tempdb中。因此对于辅助副本的tempdb需要进行合理的配置和优化，用以优化辅助副本的性能表现。

 

• AlwaysOn-Listener

From : http://book.2cto.com/201304/19873.html 

 在Listener选项卡中，你可以选择是否要为可用性组创建一个Listener。创建了Listener后，可用性组就有了一个虚拟网络名。应用程序通过这个虚拟网络名就可以连接到主副本实例。
创建Listener需要提供：

（1）IP地址。你可以选择使用DHCP方式动态分配一个IP地址，也可以手动指定一个静态IP地址，只要确保这个IP地址在网络上是唯一的即可。

（2）网络名（DNS名）。确保该名字在网络上是唯一的。这个名字就是应用程序用来连接主副本的接口，它和任意一个副本的服务器名都不相同。

（3）端口号。你需要指派一个服务器上未被使用的端口。这样副本实例才能成功绑定和监听这个端口。

如果你在这里选择不创建Listener，在可用性组开始运行后你依旧可以随时添加一个Listener，如图3-19所示。

  你可以选择如何在其他的副本上初始化可用性组中的数据库。

（1）Full

你可以选择让向导自动在其他的副本上初始化数据库。这要求你提供一个当前的服务器上的共享目录。向导会对自动数据库做完整备份和日志备份并将备份文件存放到这个目录。其他的副本通过这个共享目录获得数据库的备份并在各自的实例上进行还原。这个和日志传送进行初始化的步骤很像。这里你要确保每个副本实例的服务账户对共享目录和本地目录有合适的读写权限。另外要注意，通过这种方式初始化，你要确保主副本上存放主数据库文件的路径在辅助副本上也存在。

（2）Join only

如果你已经手动在各个辅助副本上还原了数据库，那么你就可以使用这个选项，将各个辅助副本直接加入到可用性组中。这样你可以控制初始化可用性组所花费的时间，而且也可以把数据库文件放置在辅助副本上的任何目录，无须和确保辅助数据库和主数据库具有一样的文件路径。这个初始化方式类似于数据库镜像。

（3）Skip initial data synchronization

完全跳过这个步骤。你需要之后手动的在主副本上对数据库做完整备份和日志备份并还原到所有辅助副本上，然后通过Powershell脚本，或SQL Server Management Studio的向导或者T-SQL语句把数据库加入到可用性组中。

然而无论你选择什么方式，如果有可能最好还是确保主数据库和副本数据库的文件路径一致。在可用性组可以运作后，当你为主数据库添加一个文件时，辅助数据库也会将文件添加在相同的路径。如果主副数据库路径不一致，就可能发生辅助数据库添加文件失败的情况，这会直接导致可用性副本进入NOT SYNCHRONIZING状态，图3-20显示了选择辅助副本上可用性数据库的初始化方式。

 

在创建可用性组之前做一次验证，确保之前的配置都有效且符合要求，如图3-21所示为可用性组验证的结果。

最后终于创建完成，单击“Close”按钮结束整个向导，如图3-22所示。

向导完成后，在SQL Server Management Studio中就可以看到你所创建的可用性组的各种信息，包括有哪些可用性副本、每个副本当前的角色、有哪些数据库、虚拟网络名（Listener的名字）等。在创建完可用性组之后，你可以随时对可用性组中的各种设置进行更改，可以添加或删除可用性组中的数据库，添加或删除可用性副本，更改可用性副本的同步提交设置、自动故障转移设置、可读设置、备份首选项设置等，也可以添加或删除该可用性组的Listener，这些都是可以通过SQL Server Management Studio的UI来完成。图3-23列出了通过Listener连接可用性组查看各个可用组中的对象。

 

如果打开Windows群集管理器，你会看到可用性组对应的资源组，如图3-24所示。在本节的例子中，我们创建了一个有Listener的可用性组，Listener的IP地址是10.10.10.175，名称是testAGvname。于是，在资源组中，你会看到三个资源：虚拟IP地址、虚拟网络名、可用性组。

• 监视AlwaysOn可用性组的运行状态

http://book.2cto.com/201304/19875.html

SQL Server 2012提供了非常多的信息来方便你监视可用性组的运行状态。

1．系统视图和动态管理视图

首先，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

由于篇幅的限制，这里无法对每个视图都详细的介绍。要获取更详细的信息，你可以参考SQL Server的联机丛书。

2．性能计数器

AlwaysOn引入了两个性能监视器的对象：SQLServer:Availability Replica和 SQLServer:Database Replica。每个对象下面都有一些性能计数器用来让你了解当前可用性组运行的健康状况和性能表现。

SQLServer:Availability Replica：当你在性能监视器中选中某个Availability Replica对象的计数器后，计数器实例名会显示为<AG Name:Instance Name of the replica>。假设你要监视的是可用性组ag的可用性副本AlwaysOn1，那么计数器实例就是ag:AlwaysOn1。

SQLServer:Database Replica：当在性能监视器中选中某个Database Replica对象的计数器后，每个参数副本的数据库都成为一个计数器实例。假设可用性组ag拥有可用性副本AlwaysOn1，且ag包含3个可用性数据库agdb1, agdb2和 agdb3。一旦你选中了SQLServer:Database Replica下的某个技术器后，你就可以看到分别代表agdb1, agdb2和 agdb3三个的计数器实例。你可以决定选择某个数据库或者所有数据库进行监视。

Database Replica and Availability Replica 下的计数器所包含的信息，有的是对主副本和辅助副本都有意义的，而有的可能只对某种角色的副本有意义。举例来说，Database Replica:Log Send Queue计数器是用来标示主副本上还有多少没被送到辅助副本上的日志块的。你只有在辅助副本上观察这个计数器才有意义，因为不同的辅助副本未收到的日志块数量可能是不同的。

表3-5列举了每种计数器应当在哪种角色的副本上进行监视。

表3-5  不同角色的可用性副本可使用的AlwaysOn性能计数器

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．Dashboard

一旦你创建了一个可用性组，就可以使用AlwaysOn的Dashboard。Dashboard用来监视可用性组、副本和数据库的健康状况。Dashboard是一个将各种信息集中在一体的报表，它不但本身包含丰富的信息，而且通过它你还能转向到其他的日志（AlwaysOn_health事件、SQL错误日志、Windows群集日志以及Windows事件日志等），以获得更进一步的分析信息。

要打开Dashboard，你只需要在SQL Server Management Studio中选中所想要监视的可用性组，然后右击选择“Show Dashboard”命令，如图3-27所示。

在Dashboard报表中，可用性组的健康状况是基于AlwaysOn的系统策略（System Policy）评估出来的。可用性组、可用性副本和数据库都会显示其各自的健康状态。在图3-28中，可用性组、可用性副本和数据库的状态都是“健康”。

 

你可以通过SQL Server Management Studio找到所有AlwaysOn的系统策略以及每个策略所对应的系统条件，如图3-29所示。

Dashboard中其余的信息都来自于AlwaysOn的动态管理视图。你可以对DashBoard进行定制化，在可用性副本和数据库级别添加你想要的其他信息。例如，你可以在Dashboard中的可用性组列表的列名处右击，这样你就能看到所有可以加入到该列表中的额外数据列。这些可额外添加的数据列大部分都能直接对应到动态管理视图中相应的列上。

图3-30中显示出来的可额外添加的数据列大部分都来自于sys.dm_hadr_database_replica_states视图中。

 

4．AlwaysOn_health会话

AlwaysOn_health会话是SQL Server 2012自带的扩展事件对话，如图3-31所示。当你通过SQL Server Management Studio中的向导创建可用性组之后，这个会话会被启动，如果你使用的是T-SQL或者Powershell脚本创建可用行组，那么该会话不会启动。

 

AlwaysOn_health会话会在SQL Server的LOG目录下生成一系列名为“AlwaysOn_health_<序号>_<创建时间>.xel”的扩展事件日志文件。该事件日志文件会记录一些重要的事件，例如可用性副本/数据库的状态变化，Failover条件的改变，副本间同步状况变化等等。它还会记录AlwaysOn自身发生的错误，以及任何可能会影响可用性组健康状况的操作系统问题或SQL Server数据库引擎问题。

另一个SQL Server 2012自带的扩展事件对话是System_health。该对话会在SQL Server的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 调用。

5．SQLDIAG扩展事件日志

前面我们已经讲过SQL Server 2012故障转移群集使用sp_server_diagnostics来获取诊断信息，并且会把sp_server_ diagnostics返回的信息也会被记录到SQLDIAG扩展事件日志文件中。详细信息参见2.1.6节。

sp_server_diagnostics也负责AlwaysOn可用性组的健康状况检查。同样的，sp_server_diagnostics返回的信息依旧会被记录到SQLDIAG日志中。我们也可以通过检查SQLDIAG文件中记录的信息来对可用性发生的异常状况进行排查。例如，我们可以通过SQLDIAG中记录的SQL Server实例的资源使用情况来判断是否是由于资源瓶颈导致了可用性发生了故障切换。

SQL Server 2012 Management Studio能够直接打开后缀为.xel的扩展事件日志文件，如图3-32所示。打开日志之后，你不但能够浏览事件信息，而能对它们进行聚合、分组、过滤等操作。

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

在本节的最后，让我们再来将AlwaysOn同第2章介绍的各项技术做一个横向的对比。通过比较，你能更加直观地看到AlwaysOn的优势所在。

 

功    能	故障转移群集	日志传送	数据库镜像	事务复制	AlwaysOn
保护级别	实例级	数据库级	数据库级	数据库对象级	数据库级
是否有 数据损失	/	可能有少量 数据损失	无数据损失 （同步模式）	可能有少量 数据损失	无数据损失 （同步提交模式）
自动故障转移	是	否	是（高可用 操作模式）	否	是（自动故障 转移模式）
故障转移后 是否可逆	是	否	是	否	是
对客户端是否透明	是，自动重连接到相同IP的另一个结点	否	是，自动重定向 （需要驱动程序支持）	否	是
停机时间	约等于SQL Server服务重启的时间+数据库恢复时间	较长	约等于数据库 恢复时间	较长	约等于数据库 恢复时间
多个备用数据副本	否	是	否	是	是（最大4个）
备用数据副本可读	/	是	否	是	是
能抵御 用户误操作	否	是	否	否	否
能抵御磁盘故障	否	是	是	是	是
是否有特定 硬件要求	Windows群集	无	要求有较好的 磁盘和网络	无	Windows群集
对性能的影响	低	中	中	高	中
其他功能	/	自动页面修复	/	冲突解决，双向数据同步等	自动页面修复，只读路由，辅助数据库备份，辅助数据库执行DBCC命令
版本支持	SQL Server 2000 及以后	SQL Server 2000 及以后	SQL Server 2005 及以后	SQL Server 2000 及以后	SQL Server 2012

 

转载于:https://blog.51cto.com/57388/1850750