事务日志传送是否受到长时间运行的 redgate 脚本的影响答案

【问题标题】：Is transaction log shipping affected by long running redgate script事务日志传送是否受到长时间运行的 redgate 脚本的影响
【发布时间】：2011-04-09 13:17:16
【问题描述】：

我有一个长时间运行的 redgate 脚本，它正在将一堆模式类型更改应用于数据库。运行需要 3 个小时。此脚本将在具有镜像和事务日志传送的生产数据库上运行。

我的具体问题是事务日志传送将如何受到一个巨大的 redgate 生成脚本的影响？其配置：每 15 分钟备份一次备份到本地驱动器运送到 dr 服务器驱动器每30分钟应用一次保持60分钟

它是否仍会逐步交付更改，或者如果有一个 redgate 交易在完成之前不会交付？

担心的是 1. 长时间运行的脚本不会受到此事务日志传送的影响（考虑到它会跨越多个备份） 2. 更改是增量发送还是作为一个大转储发送 - 正如我认为 redgate 通常使用一个事务所以如果它失败它会回滚所有内容？我知道日志文件总共增加了大约 80 gig，所以我试图确保有足够的空间让事务日志传送来存储它需要存储的任何内容。

谢谢！

【问题讨论】：

标签： sql-server-2005 transaction-log

【解决方案1】：

您应该能够通过检查 RedGate 脚本来判断这是否都是一笔大交易。只需对“开始事务”的 sql 文件进行 grep 即可了解。

如果是，那么在事务完成并提交之前，您的事务日志传送不会传送它，因此它跨越同步并不重要。我很确定情况就是这样 - 我是根据这篇文章 http://msdn.microsoft.com/en-us/library/ms151706.aspx 写的：

分发数据库 [是] 存储转发队列，从中将更改发送到订阅者 ..

“只有提交的事务被发送到分发数据库。”

【讨论】：

谢谢！做一个 grepwin 给了我很多开始事务的实例 - 但结果存储的 proc 文本包含事务，所以这有点误导:) 看起来最后有一个开始事务和最后一个提交事务 - 但在整个脚本中是这样的：IF @@TRANCOUNT=0 BEGIN INSERT INTO #tmpErrors (Error) SELECT 1 BEGIN TRANSACTION END
我认为 SQL Compare 8 允许您指定事务的大小，但我们使用的是 5 :( 试图向 dba 强调我认为会有大量日志文件要发送，但他不同意。传输90 场演出会很有趣 ;)
你的意思是开始交易吗？（你说结束）。带有嵌套 BEGIN TRANSACTION 的 BEGIN .. END 语句似乎正在加速事务的开始，以防发生错误或其他情况。有关它可能在做什么的更多信息，我建议您查看以下 3 篇文章：msdn.microsoft.com/en-us/library/ms188929.aspx msdn.microsoft.com/en-us/library/ms190487.aspx msdn.microsoft.com/en-us/library/ms187967.aspx
我还会搜索“回滚事务”的出现以更好地理解 redgate 代码。但是，是的，这听起来像是一笔 80GB 的交易——如果您的两台服务器不在同一地点，您可能需要在如何进行日志传送方面发挥创意！

【解决方案2】：

好的，所以我完成了升级（耶！），发现它并没有将整个东西作为一大块运送。我从他们的 dba 那里得到了这些信息：

它不会把它当作一大块......随着你的前进，你只会有更大的 TRN 文件。您越频繁地进行 TRN 备份并发送和应用它们，您可以保留的越小。但是，备份显然需要 cpu + i/o... 所以你不想连续运行它。

所以虽然我认为日志文件会增长到 90g.. 然后尝试通过它发送某种 90g 文件但没有。它只是逐渐填满了事务日志传送文件夹，它所拥有的 60g 足以升级 :)

【讨论】：