SQL Server事务日志截断/收缩

我已经看到一些存储过程包含事务中的所有内容。SQL Server事务日志截断/收缩

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

这是管理事务日志的正确方法吗？我已经尝试了一些存储过程，但它看起来像日志刚刚失控。在运行具有多个更新/插入/更改语句的存储过程时管理事务日志的最佳方式是什么？

任何帮助，非常感谢。

2011-03-07 divided

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

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

交易被存储以允许在失败的情况下恢复。自上次备份以来，您可以逐步完成事务以在该时间点重新创建数据。简单恢复模式不允许这样做，因为事务在成功执行后立即被截断（COMMIT）。

备份后，日志通常会被截断和收缩。您可以创建SQL维护作业来管理它。

2011-03-07 19:36:17

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

此外，如果没有COMMIT或ROLLBACK，您的代码将会出现BEGIN TRANSACTION错误。

2011-03-07 19:35:29 JNK

谢谢，我只注意到我输入'结束'而不是'提交'。 – divided 2011-03-07 19:42:00

你不需要在事务中包装这个。它正在运行一个语句，以便它成功或失败。

如果您正在更新第二个表，并且需要同时保持数据一致，那么您可能需要考虑这种方法。

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

2011-03-07 19:37:41

除了将恢复设置为简单意味着您可能会失败中丢失数据。更适合大多数应用程序开始备份事务日志。我们每15分钟就会做一次，因为我们无法承担损失更多数据的公司。 – HLGEM 2011-03-07 19:44:04

@divided，只是为了说清楚，备份数据库不会备份事务日志，您需要单独的事务日志备份。 – HLGEM 2011-03-07 19:45:20

你当然是对的。我打算继续解释，但感受到打字速度更快的压力。达斯汀的回答可能是最完整的，这就是我投票的原因。然而，并不是所有的开发人员都有DBA管理数据库的豪华 – 2011-03-07 19:48:15

回答