Sql Server 中的大事务，有什么问题吗？答案

【问题标题】：Huge transaction in Sql Server, are there any problems?Sql Server 中的大事务，有什么问题吗？
【发布时间】：2011-09-10 14:55:25
【问题描述】：

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

有什么问题可以预料吗？

还有其他理由将事务拆分成更小的步骤吗？

【问题讨论】：

【解决方案1】：

总之，

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

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

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

在您用完磁盘空间之前，这并不是真正的问题，但您会发现回滚需要很长时间。我当然不是说要为失败做准备。

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

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

真的需要原子地做所有事情吗？

【讨论】：

不，不需要以原子方式进行，但到目前为止它一直是最简单的。我不需要关心回滚和重新启动整个事情。我不能那么容易地分离 DDL，因为我在很多地方添加新列或表并从现有表中迁移数据，然后删除旧列或表。

【解决方案4】：

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

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

【讨论】：