可用性组可以代替事务复制吗？

我一直在研究SQL Server 2012的新功能，以及它如何帮助解决当前的问题。

当前，我们使用SQL Server 2008 R2，并通过事务复制将两个OLTP服务器的数据库复制到单个报告服务器。然后，我们使用这些复制的DB进行报告。

我对SQL Server 2012和可用性组是否可以替代它感兴趣-因此，我将使用新的可用性组并将这两个OLTP服务器的数据库镜像到报告服务器，而不是事务复制，在该服务器上，报告将能够执行访问只读副本。

我不确定这是否会奏效，甚至根本不会奏效。

我想摆脱复制，因为它会导致我的部署策略出现问题（使用VSDBCMD.exe）。我还想摆脱大型数据库上复制重新初始化的延迟。

有人对此有任何好的例子或经验吗？是否可以按照较低版本中的常规镜像将可读副本从多个服务器镜像到单个服务器？

最初是在这里问到的：https : //stackoverflow.com/questions/10415225/mirroring-and-availability-groups-in-sql2012对不起，我认为我还不能迁移问题。

从我在StackOverflow上的答案中滑过，只是为了防止其他人将精力花在相同类型的答案上。

我个人认为这比事务复制要好得多，尽管我没有在真正的迁移方案中对两者进行任何正式的比较。我知道，与标准镜像（这是对它的升级）相比，与事务复制有关的麻烦很多，您肯定会遇到较少的问题。

最大的好处是，辅助服务器可以标记为只读-因此您可以根据需要运行所有报告，并且完全不会影响镜像。您只需要更强大的tempdb（因为它本质上使用rcsi来做到这一点）。

当然，您确实需要知道，AG的两面都需要获得完全许可才能将副本用于只读操作。而且双方都需要在特定版本的Windows上运行（企业版或更高版本，在2008 R2和更低版本；标准版或更高版本，在2012和更高版本），因为它们都需要故障转移群集-AG中的SQL实例不需要群集，但是他们需要坐在操作系统中的基础架构之上。

与可用性组相比，事务复制在报告工作负载方面的优势

作为上述答案的反驳，以下是一些原因，为什么事务复制比报告工作负荷的可用性组更好的解决方案。

• 您可以在数据库中复制表的子集。可用性组副本始终是整个数据库。如果某些表包含敏感信息，则如果所有报告均针对不包含该信息的数据库完成，则审核访问会更容易。
• 您可以过滤要复制的行，以提供更高的粒度。例如，您可以将部门特定的信息复制到多个部门报告服务器，每个服务器只能访问其信息。
• 您可以在发布者和订阅者之间使用完全不同的索引策略。使用可用性组，索引是相同的，即使统计信息将在副本数据库上创建并存储在tempdb中，但您无法调整复制为您提供的功能。
• 安全问题。通常，报表用户使用SSMS，access或excel直接连接到数据库，而您只想限制其对报表数据库的访问。

如果这些都不是大问题，那么可用性组可能是更好的选择。