为报告备份 SQL 数据库答案

【问题标题】：Backing up SQL Database for Reports为报告备份 SQL 数据库
【发布时间】：2010-10-27 01:04:39
【问题描述】：

我正在寻找一些帮助/建议，以便将两个大型数据库备份到一台专用于报告的服务器。情况是；

我公司的内部网站有两个数据库。一个用于英国，一个用于欧洲。两者都为 DR 镜像。

我在欧洲有一台服务器，专门用于 Microsoft Reporting Services，我们根据这两个数据库中收集的数据运行报告。

出于性能/安全原因，我们不想将报告服务指向实时数据库，因此我们目前每天备份这两个数据库并将它们恢复到我们的 Reporting Services 服务器。

然而，这意味着我们通过备份整个数据库给我们的网络带来了压力，而且数据仅在昨天午夜之前是最新的。

我们的目标是让数据至少更新 15 分钟，有人建议查看 Log Shipping，所以我想知道是否有人有任何设置这方面的经验，优缺点是什么，是否有有更好的选择吗？

任何帮助将不胜感激，谢谢

【问题讨论】：

这属于 serverfault.com

标签： sql-server backup replication log-shipping sql-server-administration

【解决方案1】：

我建议您考虑使用事务复制。

听起来您正在寻找与我们目前正在实施的方案类似的方案。

我们使用事务复制（尽管是实时的，您很可能希望以较低频率同步您的环境）将我们的实时生产数据库的副本卸载到另一台服务器以进行报告。

卸载报告数据是一种常见的复制方案，并在 Microsoft 复制文档中进行了描述。

http://msdn.microsoft.com/en-us/library/ms151784.aspx

Brent 是对的，因为复制确实需要配置元素，以及需要解决的安全问题，但是在我看来，使用复制有许多关键优势，包括：

与日志相比减少了延迟运费。
仅发布需要的文章（表格）用于报告。
降低存储要求。
发布的数据越少，意味着越少网络流量。
访问您的报告数据/数据库。

例如，在我们的环境中，我们决定仅从生产数据库中复制我们实际需要用于报告的特定表格（文章）。

我希望我所描述的内容清晰且有意义，但如果您有任何疑问，请随时与我联系。

【讨论】：

感谢约翰，他非常清楚，非常有帮助！我要向你们阅读大量内容，并将测试这些方法并让您知道我的进展情况。
不客气。如果您需要任何进一步的帮助，请务必告诉我们您的进展情况。
嗨约翰，我已经研究过这种方法，虽然它在大多数情况下都可以工作（这也是微软的首选推荐），但它还不适合我们，只是因为它会意味着改变我们的数据库模式。但这是我们未来在明确改进我们的结构时会考虑的事情
不客气。需要注意的一点是，只有合并复制需要将架构更改应用于您的数据库。事务复制不进行任何架构更改。

【解决方案2】：

我们开发了一个类似的环境。我们使用镜像将数据传输到我们的报告服务器，并创建了一个自动化例程，每 15 分钟创建一次数据库快照。这些快照只需要 1 到 2 秒就可以在我们的环境中创建，并为我们提供数据库的只读副本。如果您希望我更详细地介绍，请告诉我。

注意我们在两台服务器上都运行 Enterprise。

【讨论】：

设置和维护有多难？我们还在我们的服务器上运行企业版。
两者都不是很难。镜像设置完成后，我创建了一个例程转储快照并每 15 分钟重新创建一次。一切都是自动化的，所以我已经设置好了，几个月后就不用搞砸了。
我已经在我们的英国和欧洲镜像上设置了这个，它运行得非常好，快照在几秒钟内创建，我们能够在过去 15 分钟内访问数据，这是一个非常好的解决方案，感谢 Jonathon！
这是简单数据库平台的绝佳解决方案。然而值得注意的是，在超大型数据库 (VLDB) 上，这可能无法为报告平台提供足够的性能。在这种情况下，复制是自己的，因为您可以调整复制的数据库，即为专门的服务报告查询添加索引，而无需在 Publisher 上进行相同的修改（从而减轻对 OLTP 平台的不利影响）。
John 对 VLDB 的看法非常正确。感谢您添加这一点，约翰

【解决方案3】：

日志传送是一个很好的解决方案。我们在SQLServerPedia's Log Shipping section 上有关于它的文章，我有一个视频教程，通过你的不同选项告诉你。关于日志传送要记住的一件事是，当恢复发生时，您的用户将被踢出报告数据库。

复制没有这个问题，但复制远不及“一劳永逸”——管理起来很费时间，而且不像您希望的那样可靠.此外，您可能必须进行架构修改才能使用复制。日志传送更加自动化和稳定，但代价是在恢复时将用户踢出。

您可以通过设置两个日志传送计划来最大程度地减少这种情况 - 一个用于工作时间的白天，一个用于其余时间。在工作时间内，您每小时（或更少）只恢复一次数据，其余时间每 15 分钟恢复一次。

【讨论】：

感谢布伦特，这真的很有帮助，当您说将用户踢出时，这是否意味着他们每小时都会在一段时间内失去对数据库的访问权限？还是实际上会将它们从我们的报表服务器上的终端服务会话中踢出？抱歉，如果这是一个愚蠢的问题，我是 SQL Server 的新手 :)
根本不是一个愚蠢的问题！他们将失去对数据库的访问权限 - 数据库将终止连接并等待事务日志恢复。
对迟到的回复表示歉意...我已经在两个 2005 sql 服务器之间的测试数据库上设置了日志传送，并且它工作得非常好！但是（这是我在最初的问题中没有提及它的错！）我不允许将 SQL 2005 的日志传送到运行我们报告的 2008 服务器。在我开始设置事务日志之前，我没有意识到两者之间会有兼容性问题。我认为2008会兼容。你知道有没有办法解决这个问题？谢谢
您可以通过编写自己的 T-SQL 脚本来设置 SQL 2005 和 2008 之间的手动日志传送，或者使用第三方产品来完成。这通常不是一个好主意，因为您不能真正使用 SQL 2008 框作为故障转移方法 - 一旦故障转移到 2008，就无法返回。长话短说，是的，你可以做到，但不，这并不容易，也不是个好主意。
谢谢布伦特。我尝试从 2005 年到 2008 年进行自动日志传送，我遇到的问题是，当文件传送时，它必须转换为 2008，这意味着接收 2008 服务器上文件的数据库始终处于恢复状态，并且无法访问以进行报告。我可以访问的唯一方法是禁用日志传送任务。

【解决方案4】：

您应该将 replication 视为备份的替代方案。

【讨论】：

谢谢约翰，我会调查的！