Question

我已经看到一些存储过程将事务中的所有内容包装起来。

begin transaction
    update
        table
    set
        column c = (column a * column b)
commit

这是管理交易日志的正确方法吗？我已经尝试了一些存储过程，但它看起来像日志失控。在运行包含多个update / insert / alter语句的存储过程时，管理事务日志的最佳方法是什么？

非常感谢任何帮助。

Answer 1

无论查询是隐式包装在事务语句还是恢复模型中，都会记录SQL事务。根据恢复模型，事务将保留在日志中（完全恢复模式）或被截断（简单恢复模式）。无论截断模式如何，日志都不会缩小文件大小。

管理日志不是通常在应用程序中的SQL查询中处理的内容，而是DBA任务。

存储事务以允许在发生故障时进行恢复。您可以在上次备份后单步执行事务处理，以便在该时间点重新创建数据。简单恢复模式不允许这样做，因为事务在成功执行后立即被截断（COMMIT）。

日志通常在备份时被截断并缩小。您可以创建SQL维护作业来管理它。

Answer 2

日志与查询中显式TRANSACTION的数量没有直接关系。 It's related to your recovery model.显式TRANSACTION语句只是根据请求使用日志回滚或提交。

另外，由于您的BEGIN TRANSACTION没有COMMIT或ROLLBACK，您的代码会引发错误。

Answer 3

您不需要在事务中包装它。它正在运行一个语句，因此它将成功或失败。

如果您要更新第二个表并且两者都需要成功保持数据一致，那么您可能需要考虑这种方法。

但是..事务日志文件的大小将增加，直到备份为止。如果数据库很小，您可能希望将数据库恢复选项设置为简单，并且每晚只备份整个数据库，这也会截断事务日志文件。