为报表创建 SQL Server 数据库的只读副本

Question

当我的 .Net Web 应用程序运行缓慢时，我遇到了一个问题，即使我已经优化了所有查询。事实证明，另一位制作报告的开发人员一直在运行一堆未优化的查询。所以我决定为他创建一个单独的服务器。目前我创建了 Jobs 进行备份，将其复制到另一台服务器并恢复它。但这是临时解决方案，因此为了让第二台服务器拥有最新数据或至少延迟最小，我正在研究创建只读副本的机会。

由于我不是 DBA，因此我阅读了大量有关 SQL Server 复制机制的文章或文章。对我来说最好的选择是当我的 PROD Web 应用程序完全不受复制影响时，我的意思是对同步表进行大量锁定。我不需要像镜像那样实时同步，也不需要任何集群解决方案之王，只需读取我的 PROD 数据库的同步副本。所以我选择了Transactional具有异步分发策略（按计划）的复制机制（不可更新）。

所以我有一些问题：

1. 在 SQL Server 复制机制中，事务复制是否最适合我的问题？

2. 如果我有机会从 SQL Server 2008 迁移到 SQL Server 2012，事务复制会发生一些重大变化吗？我在technet上读过一篇文章，可能会出现错误？

3. SQL Server 2012Always On机制不是更好地解决我的问题吗（我正在考虑将此选项作为最后一个选项，因为我仍在使用 2008 R2，但不久之后计划迁移到 2012）？

Answer 1

在 SQL Server 复制机制中，事务复制是否最适合我的问题？

在所有复制选项中 - 事务性听起来像是在这里对您最有帮助。它提供了最小的延迟，并且不需要（但可以）是双向的。您不会合并更改，也不需要点对点。

也就是说 - 复制不是“免费的” - 您需要对其进行管理和监视，而糟糕的设置可能会使性能问题变得更糟。您应该了解最佳性能选项和最佳性能设置，并牢记这一点并监控您的复制环境。

事务复制比合并复制“更容易”。但这并不意味着您将永远一帆风顺，并且可以在没有具有复制经验的人的帮助下逃脱。

如果我有机会从 SQL Server 2008 迁移到 SQL Server 2012，事务复制会发生一些重大变化吗？我在technet上读过一篇文章，可能会出现错误？

不幸的是，这是一个“视情况而定”类型的问题。理论上，我们可以根据自己的经验为您提供答案，但您需要进行测试。如果您确实遇到问题，它们不一定是您无法解决的不可能的问题，它们将需要测试和调整。

SQL Server 2012 Always On 机制不是更好地解决我的问题吗（我正在考虑将此选项作为最后一个选项，因为我仍在使用 2008 R2，但很快就计划迁移到 2012）？

在 SQL Server 2012 中，AlwaysOn 为您提供了一些可能起作用的东西。可用性组是此处的答案，其中包含用于阅读目的的活动辅助节点的概念。但是存在许可问题 - 您需要在主要和只读/活动辅助上都处于 Enterprise 中。使用复制方法，您仍然需要在两端获得许可，但这无疑是一个不错的选择。它也有相关的开销和一些您应该了解的管理问题 - 但它是一个很好的选择。

Answer 2

我不需要像镜像那样实时同步，也不需要任何集群解决方案之王，只需读取我的 PROD 数据库的同步副本。

正如迈克所说，T-Rep 不是免费的。您必须维护分销商数据库，并且依赖于日志读取器代理。如果发布上发生的更改量很大并且取决于网络延迟，则分发数据库中将累积命令等待日志读取器代理扫描并将它们发送给订阅者。架构更改将需要新的快照 - 这会导致锁定发布数据库，直到快照完成。此外，与数据子集（选定表、SP 等）相反，整个数据库的复制通常会导致与其维护相关的问题。

根据您的情况，我建议使用logshipping。它易于设置且依赖性最小（网络共享 - 应具有适当的权限）。

日志传送的好处是您可以在待机模式下将辅助数据库设为只读。

您可以延迟在辅助上恢复日志备份。

注意：如果您使用带有 STANDBY 选项的日志传送，则辅助数据库不能位于比主数据库更高版本的 sql server 上。