在Sql Server中的巨大事务，有什么问题吗？

Question

我有一个程序可以在一个事务中对SQL Server 2005或2008数据库执行许多批量操作（删除并创建索引，创建列，完整表更新等）。

是否有任何问题需要预料？

• 我知道即使在简单恢复模式下，事务日志也会扩展。
• 在程序正常运行期间不执行此程序，因此锁定和并发不是问题。

还有其他原因可以将交易分成更小的步骤吗？

Answer 1

简而言之，

• 使用较小的事务可以提供更强大的故障恢复。
• 长事务也可能在不久的时间内对对象进行锁定，而其他进程可能需要访问即阻塞。

考虑到，如果在事务开始和结束之间的任何时刻，您的服务器都会遇到故障，为了使数据库联机，SQL Server必须执行崩溃恢复过程，这将涉及回滚所有未提交的事务来自日志。

假设您开发了一种智能化的数据处理解决方案，可以从中断的地方继续。通过使用单个事务，这不是一个可用的选项，因为您需要再次从乞讨开始该过程。

Answer 2

在磁盘空间不足之前，这确实不是问题，但您会发现回滚需要很长时间。我当然不是说计划失败。

但是，请考虑该过程而不是事务日志。我考虑分开：

• DDL进入单独的交易
• 使用事务批量装入登台表
• 在另一个交易中将数据从登台刷新到最终表格

如果出现问题，我希望你有回滚脚本和/或备份。

是否确实需要以原子方式完成所有事情？

Answer 3

如果事务导致过多的数据库日志条目（更新），则日志可能会出现所谓的“高水位线”。这是日志达到（约）其绝对最大大小的一半时的点，然后它必须开始回滚所有更新（这将消耗与更新所用的磁盘数量相同的磁盘。

此时不回滚意味着最终会达到最大日志大小的风险，仍然没有完成事务或执行回滚命令，此时数据库被搞砸了，因为没有足够的日志空间来回滚。

Answer 4

根据更新语句的复杂程度，我建议仅在比较几百行的小表上执行此操作。特别是如果你只有少量的主内存可用。否则，例如，大表的更新可能需要很长时间甚至看起来挂起。然后很难弄清楚进程（spid）正在做什么以及可能需要多长时间。

我不确定“Drop index”是否是事务记录操作。请参阅stackoverflow.com上的this question。