SQL 2005：我应该滚动自己的日志传送吗？

Question

我正在考虑使用日志传送来进行灾难恢复，而且我收到有关是否使用内置内容或自行滚动的混合消息。你推荐哪一个，如果你喜欢滚动你自己内置的东西有什么问题？如果我要重新发明轮子，我不想犯同样的错误！ （我们有工作组版。）提前致谢。

Answer 1

您的问题实际上有两个部分：

1. 本机日志传送是否足够好？

2. 如果没有，我应该使用谁的日志传送？

这是我的两分钱，但就像你已经发现的那样，很多都是基于意见。

关于第一个问题 - 本地日志传送适用于小型实施 - 例如，1-2台服务器，少数数据库和全职DBA。在这样的环境中，本机日志传送缺乏监视，警报和管理不是问题。如果它破裂，你不会出汗，因为它相对容易修复。什么时候会破裂？例如，如果有人在灾难恢复服务器上恢复之前意外删除了事务日志备份文件。 （通过自动化流程始终发生。）

当您超越几台服务器时，缺乏管理自动化开始成为一个问题。您需要更好的自动电子邮件警报，当日志传送超过X分钟/小时时发出警报，文件复制花费时间过长时发出警报，更轻松地处理多个辅助服务器等等。当人们转向备用解决方案时。

关于第二个问题 - 我会这样说的。我为Quest Software工作，这是LiteSpeed的制造商，一个SQL Server备份和放大器。恢复产品。我经常与使用我们的产品和其他产品（如Idera SQLSafe和Red Gate SQL Backup）的数据库管理员交谈，以简化其备份管理。我们构建GUI工具来自动化日志传送过程，为您提供一个漂亮的图形仪表板，准确显示您的瓶颈所在，并帮助确保在主数据中心出现故障时覆盖您的对接。我们出售了很多许可证。 ： - ）

如果您自己编写脚本 - 当然可以 - 当数据中心出现故障时，您将完全独立。您将无法获得支持热线，您将无法使用工具来帮助您，而且您无法告诉您的同事“打开此GUI并单击此处进行故障转移”。您将尝试在灾难中使用T-SQL脚本。拥有大量时间的专家DBA有时更喜欢编写自己的脚本，它确实给你很多控制权，但是你必须确保你有足够的时间来构建它们并在你存入你的就此工作。

Answer 2

您是否考虑过镜像？这里有一些documentation来确定你是否可以这样做

Answer 3

如果您决定推出自己的here's a nice guide。

我假设你正在走这条路，因为企业版是如此昂贵？

如果您不需要“实时备份”，但实际上只是想要经常更新备份，我认为这种方法很有意义。

---

还有一件事：

确保定期验证您的备份策略是否有效。

Answer 4

我很确定它可以在Standard中使用，因为我们正在进行一些运输，但我不确定Workgroup版本 - 它已经相当简单了。

我总是支持软件包解决方案，但主要是因为我相信整个MSFT开发团队比我更信任我自己，但这肯定是有代价的。我是第二个你自己推出的任何解决方案都必须附带延迟通知文件，这样你就能立即知道它是否工作 - 我们只发现了多少次备份有人需要备份时解决方案无效吗？另外，请诚实地考虑设计和推出自己的解决方案需要多长时间，包括错误修复和维护 - 你真的可以更便宜地做到吗？也许你可以，但也许不是。

此外，我们遇到的一个问题是Workgroup版本一次只支持5个连接，如果你的用户数量多于此，它似乎开始丢弃连接，所以我们不得不升级到Standard。我们得到了ASP.NET错误，如果我们将它们无人看管甚至几秒钟就会关闭我们的连接，这会给我们带来各种各样的问题。

Answer 5

我希望这会接近你想要节省几美元的最后一个地方，特别是考虑到如果你搞砸了可能的后果。你宁愿让你的工作上线吗？如果我觉得我有机会得到这个，我甚至都不认为我会承认这一点？

你的个人好处是什么？

Answer 6

我尝试了内置的日志传送，发现了一些真正的问题，所以我开发了自己的。我在博客上发表了here。

PS：只是为了记录，你肯定会在Workgoup版本中获得日志传送。我不知道这个企业专用的东西在哪里开始。