我们有一个运行在 SQL Server 2008 r2 64 位上的新系统。有一个主要的在线事务处理 (OLTP) 数据库，它接受来自全国各地商店的数千个销售点系统的大量更新。为了保护这一重要功能，我决定引入一个专用的报告数据库服务器 - 多个用户将从该服务器运行一些相当复杂的报告。
我意识到有很多选择，但我决定使用事务复制作为将数据从 OLTP 数据库复制到新报告数据库的机制 - 单向复制。
该解决方案在测试中效果很好。现在有人问我需要对备份策略进行哪些更改才能涵盖架构更改。我读过以下页面MSDN：备份和恢复快照和事务复制的策略但我认为这些对于我的解决方案来说有些过度了。事实上，我目前的想法是，我们只需要继续备份 OLTP 数据和日志。如果报告数据库或任何系统复制（例如分发）数据库发生故障，那也没什么大不了的 - 我们可以清除所有内容，然后重新创建复制。我意识到拍摄 OLTP 的完整快照会很耗时（大约 5 小时），但我对此更放松，而不是尝试以正确的顺序恢复各种数据和日志文件的备份。
我的观点是，MSDN 文章中列出的复杂策略只是实现比我所拥有的更复杂的复制解决方案的途径，例如，如果有多个订阅者进行双向复制。
你同意吗？如果你能提供任何建议，我将不胜感激。
非常感谢，
抢。，
答案1
我假设您已经为 OLTP DB 和报告 DB 制定了良好的备份策略，并且这些策略已在生产环境中顺利运行。我真的不认为您对在复制后修改这些内容还有任何其他顾虑。
您可以通过 SSMS 向导简单地生成复制设置脚本。这将允许您在任何未来的开发/测试环境中调整和配置您的复制设置，并为您提供当前配置的备份。
如果由于某种原因复制停止，复制可能会严重消耗您的日志磁盘...但只要您手动或自动警报跟踪磁盘空间和复制状态，您就不必担心。
祝你好运 - 但在我看来，基本事务复制中的备份需求不需要任何额外的策略。
答案2
在我们的环境中，我有一个与您建议的类似的设置。我同意恢复数据库以保持复制一致性的过程有点麻烦，而且如果出现严重问题，我宁愿重新创建复制，但我仍然备份报告数据库。
在生成和传输完整快照所需的时间内（在我们的例子中为 8 小时），我可以在 30 分钟内恢复具有不同名称的报告数据库的静态副本，并将报告应用程序指向该数据库，以避免我的报告用户停机时间过长，这样，用户可以从昨天开始根据数据执行报告，直到复制的数据库启动并运行。