我们目前使用我们编写的一个相当基本的脚本来将我们的数据库日志发送到我们的 DR 站点（然后再返回），但我们希望转向更好的解决方案。我们最初不考虑内置日志传输解决方案，因为我们必须为每个数据库手动设置它（我们有大约 40 个，年底前将有 80 个，大小约为 2-5GB），并且无法按顺序运行它，因此它们同时占用带宽。我们目前的问题是，如果辅助服务器“错过”日志，就会出错，我们必须传输整个数据库。我想我的问题是 - 我们在这里走错了路吗？我们没有大量的现金可以花在解决方案上，只有我们自己的时间和耐心 :-)。我们基本上需要在 30 分钟内往返于我们的 DR 站点，对于测试，我们担心数据丢失（但对于真正的灾难，我们不介意）。我会很感激任何想法或建议。
克里斯
答案1
Red-Gate SQL Backup 可以进行日志传送。我只试用过它，但它的界面和调度可能正是您所需要的。他们还有一个试用版。
答案2
我不明白“...无法按顺序运行，因此它们会同时占用带宽...”。在我看来，这就像您希望管理日志的复制时间，希望尽量减少这里的作业冲突。此外，您没有提到可以容忍的延迟量。我明白，考虑到这么多数据库上的设置，内置日志传送设置可能是不理想的，但它可以让您安排每个传送日志的复制作业的运行时间。这不是您所要求的，但在没有万无一失的自定义脚本或第三方工具的情况下，这是一个选择。
答案3
我们仅使用 sqlserver 2008 内置的日志传送功能就解决了基本日志传送问题。这使我们能够指定每个作业的运行时间，这很棒。
答案4
编写自定义日志传送脚本来解决这个问题并不是什么难事。我在 searchsqlserver.com 上发布了一些您可以使用的脚本。