备份SQL数据库以进行报告

Question

我正在寻求帮助/建议，将两个大型数据库备份到专用于报告的服务器上。情况如下：

我们公司有两个内部网站的数据库。一个是英国的，一个是欧洲的。两者都进行了灾难恢复镜像。

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

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

然而，这意味着我们正在通过备份整个数据库来对我们的网络造成压力，并且数据仅在昨天午夜之前更新。

我们的目标是使数据至少在15分钟内保持最新状态，有人建议查看日志传送，所以我想知道是否有人有设置此项经验，其优缺点以及是否有更好的替代方案？

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

- Phil

---

这个问题应该发布在serverfault.com上。 - Andomar

Answer 1

日志传送是解决这个问题的好方法。我们在SQLServerPedia的日志传送部分有相关文章，我也有一个视频教程，可以向您介绍不同的选项。需要注意的一点是，在恢复过程中，用户将被踢出报告数据库。

复制没有这个问题，但是复制远没有“设置并忘记”那么简单 - 它需要耗费大量时间来管理，并且可靠性不够高。此外，您可能需要进行模式修改才能使用复制。日志传送更加自动化和稳定，但代价是在恢复时会使用户退出。

您可以通过拥有两个日志传送计划来最小化这种情况 - 一个用于白天工作时间，另一个用于其他时间。在工作时间内，您只需每小时（或更少）恢复一次数据，其余时间则每15分钟执行一次。

- Brent Ozar

---

谢谢Brent，这真的很有帮助。当你说踢出用户时，这是否意味着他们每小时只是失去对数据库的访问权限？还是实际上会将他们从报告服务器的终端服务会话中踢出？如果这是一个愚蠢的问题，我很抱歉，因为我是SQL Server的新手：） - Phil

这并不是一个愚蠢的问题！他们将失去对数据库的访问 - 数据库将终止连接并等待事务日志恢复。 - Brent Ozar

抱歉回复晚了...我已经在两个2005 SQL服务器之间的测试数据库上设置了日志传送，并且它运行得非常好！然而（这是我的错，因为我没有在最初的问题中提到它！）我不被允许从SQL 2005日志传送到运行我们报告的2008服务器。直到我开始设置事务日志，我才意识到两者之间会有兼容性问题。我以为2008年会兼容。你知道是否有解决办法吗？谢谢 - Phil

你可以编写自己的T-SQL脚本或使用第三方产品来设置SQL 2005和2008之间的手动日志传送。但这通常不是一个好主意，因为你不能真正将SQL 2008盒子用作故障转移方法 - 一旦你切换到2008，就无法返回。简而言之，是的，你可以做到，但并不容易也不是一个好主意。 - Brent Ozar

谢谢Brent。我尝试自动从2005年到2008年进行日志传送，遇到的问题是当文件被传送时，必须将其转换为2008年格式，这意味着在2008服务器上接收文件的数据库始终处于恢复状态，无法用于报告目的。我唯一能访问的方法是禁用日志传送任务。 - Phil

Answer 2

我们开发了一个类似的环境。我们使用镜像功能将数据传送到我们的报告服务器，并创建了自动例程来每15分钟创建数据库快照。在我们的环境中，这些快照只需要1到2秒钟就可以创建，并为我们提供了数据库的只读副本。如果您想深入了解，请告诉我。请注意，我们的两个服务器都运行企业版。

- jgardner04

---

设置和维护有多难？我们的服务器上还运行着企业版。 - Phil

这对任何人来说都不是很困难。一旦镜像设置好了，我创建了一个例程，每15分钟转储快照并重新创建它。一切都是自动化的，所以我设置好了，几个月没有再去管它了。 - jgardner04

我已经在我们的英国和欧洲镜像上都设置好了这个，它运行得非常好，快照可以在几秒钟内创建完成，我们能够访问最近15分钟内的数据，这是一个非常好的解决方案，谢谢Jonathon！ - Phil

这是一个适用于简单数据库平台的绝佳解决方案。然而需要注意的是，在非常大的数据库（VLDB）上，这可能无法为报告平台提供足够的性能。在这种情况下，复制就发挥了作用，因为您可以调整复制的数据库，即添加索引以专门服务报告查询，而不必在发布者处进行相同的修改（从而减轻对 OLTP 平台的不利影响）。 - John Sansom

John 对于 VLDBs 的观点非常正确。谢谢你加入这个观点，John。 - jgardner04

Answer 3

在编程中，备份的替代方案是复制。

- Johnno Nolan

Answer 4

我建议您研究使用事务复制。

看起来你想要实现一个类似我们当前正在实施的情况。

我们使用事务复制（尽管是实时的，您最有可能希望以较不频繁的时间表同步您的环境）将我们的生产数据库的副本卸载到另一台服务器上，用于报告目的。

卸载报告数据是常见的复制方案，在Microsoft复制文档中有描述。

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

Brent 的观点是正确的，使用复制确实需要一定的配置，并且需要考虑安全性问题。但在我看来，使用复制有许多关键优势，包括：

• 与日志传送相比，延迟更低。
• 只发布需要用于报告的文章（表）的能力。
• 减少存储要求。
• 发布的数据越少，意味着网络流量越少。
• 随时访问您的报告数据/数据库。

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

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

- John Sansom

---

谢谢John，讲得非常清晰，非常有帮助！我需要从你们这里阅读大量的内容，并测试这些方法，然后告诉你我的进展。 - Phil

不用谢。请务必让我们知道您的进展情况，或是如果需要任何进一步的协助，请告诉我们。 - John Sansom

嗨John，我已经研究了这种方法，虽然它在大多数情况下都可以使用（而且这也是微软的首选建议），但对我们来说还不太合适，因为这意味着我们需要更改数据库架构。但这是我们将来改进结构时会考虑的事情。 - Phil

不用客气。需要注意的是，只有合并复制需要将模式更改应用于您的数据库。事务复制不会进行任何模式更改。 - John Sansom