我们有一个在SQL Server 2008 r2 64位上运行的新系统。 有一个主要的在线交易处理（OLTP）数据库，可接受来自全国各地商店的数千个销售点系统的大量更新。 为了保护这个至关重要的function，我决定引入一个专用的报表数据库服务器 – 多个用户可以从中运行一些相当复杂的报表。
我意识到有很多select，但我决定使用事务复制作为将数据从OLTP数据库复制到新报告数据库的机制 – 单向复制。
该解决scheme在testing中运行良好。 现在我被问到需要对备份策略进行哪些更改以涵盖体系结构更改。 我已经阅读了诸如MSDN：备份和恢复快照和事务复制的策略，但我认为这些对于我的解决scheme来说是过分的。 实际上，我目前的想法是，我们只需要继续备份OLTP数据和日志。 如果报告数据库或任何系统复制（例如发行）数据库失败，那么没有什么大不了的 – 我们可以清除所有数据，然后重新创build复制。 我意识到拍摄完整的OLTP快照将会非常耗时（大约5小时），但是我会更放松一些，试图按照正确的顺序恢复各种数据和日志文件的备份。
我的看法是，MSDN文章中提出的复杂策略只能是比我更复杂的复制解决scheme，例如，如果有多个订阅者进行双向复制。
你同意吗？ 我会很感激任何意见。
非常感谢，
抢。，
我假设你已经有适合你的OLTP DB和你的报表数据库的好备份策略，这些数据库已经在生产环境中运行了。 我真的没有看到你有任何额外的关于修改这些后复制的问题。
您可以简单地通过SSMS向导生成复制设置脚本。这将允许您在以后的任何开发/testing环境中调整和configuration复制设置，并为您的当前configuration提供备份。
如果出于某种原因，复制可以通过您的日志磁盘exception复制暂停..但提供您手动或自动警报跟踪磁盘空间和复制状态，你不应该有任何顾虑。
祝好运 – 但在我看来，基本事务复制中的备份需要不需要任何额外的策略。
在我们的环境中，我有一个类似于你所提议的设置。 我同意恢复数据库以保持复制一致的过程有点麻烦，如果存在严重的问题，我也宁愿重新创build复制，但我仍然备份报告数据库。
在生成和传输完整快照所需的时间（在我们的案例中为8小时）期间，我可以在30分钟内恢复具有不同名称的报告数据库的静态副本，并将报告应用程序指向该数据库以避免太多停机时间对于我的报告用户来说，这样用户可以从昨天的数据上执行他们的报告，直到复制的数据库启动并运行。