Question

我最近不得不在12年前的基于SQL的应用程序中找出间歇性ODBC错误的原因。罪魁祸首在其中一个存储过程结束时证明是这句话：

DUMP TRAN NotTheRealDBName WITH NO_LOG

我不熟悉这个命令，所以我做了一些研究，发现它备份了事务日志。我相信这只会在某些时候恢复事务日志时才有用，而这似乎并没有发生。有问题的存储过程是在各种表上插入，更新，选择和删除的简单序列。

我试图想象为什么人们会想要在业务逻辑中备份和恢复事务日志，但我无法理解它。任何人都可以给我一个有效使用DUMP TRAN的例子吗？

Answer 1

它们的关键部分是该程序还添加了WITH NO_LOG子句。所以基本上它会截断日志。可能12年前，作者遇到了日志增长问题，“彻底”研究了这个问题并得出结论，最好的方法是在他做一些冗长的更新时截断日志。没关系，在这个过程中他打破了任何维护计划的备份链......

Answer 2

当您想缩小数据库时使用此命令;我从未在业务逻辑中看到过这种情况，而且我认为在使用这种方式时它实际上是危险的。

Answer 3

DUMP现在是BACKUP，我非常确定NO_LOG选项已在SQL Server 2008中停止使用（且有充分理由）。

基本上，如果您不正确地配置了数据库 - 如果您使用了“完整”恢复模型但实际上没有进行适当的备份 - 那么这是缩小日志的一种方法。

我可以想到很少好的原因，你为什么要在没有备份的情况下截断日志，我也想不出你想要备份的很多原因日志位于业务逻辑中间，但是有一个很好的理由来备份事务日志，这是为了满足RPO目标。

通常，您每天只会进行一次数据库备份，但如果您的业务需求能够恢复半天的交易，如果服务器爆炸或某些流氓DBA设法管理您的生产数据库和所有镜像，然后您可能会每小时（或更频繁）进行事务日志备份。这样，您可以从昨天晚上恢复备份并使用事务日志备份在一小时前恢复（或者RPO无论如何）。