SQL Server误区30日谈第19天 Truncate表的操作不会被记录到日志(sql server错误和使用情况报告)

编辑：rootadmin

误区 #:Truncate表的操作不会被记录到日志错误在用户表中的操作都会被记录到日志。在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制。 Truncate Table语句会将整个表中的所有数据删除。但删除的方式并不是一行一行的删除，而是将组成表的数据页释放，将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop。使用后台线程处理deferred-drop的好处是这个操作不会使得其所在的事务需要执行很长时间，因此也就不需要大量的锁。在SQL Server SP3之前的版本（这个版本引入了deferred-drop）在Truncate Table的时候出现过多的锁耗尽内存的事是家常便饭。下面是测试代码: 上面的测试数据库恢复模式是简单，所以每个Checkpoint都会截断日志(仅仅是为了简单，哈哈)。一分钟后让我们来看看日志中有多少条记录。可以看到，现在的日志条目数字为2。如果你得到的数字不是2，那么再做一次Checkpoint直到数据是2为止。现在已有的日志已经知道了，那么日志的增长就是由于后面的操作所导致。下面我们执行如下代码: 可以看到现在已经有了条日志记录。很明显Truncate操作是需要记录到日志中的。但也可以看出Truncate并不会逐行删除,因为这条日志记录删除的是条数据。执行下面语句来查看日志: 下面是结果:

图1.查看Truncate后的日志(部分)通过日志可以看出第一条显式开始Truncate Table事务，最后一条开始DeferredAlloc。正如你所见，Truncate操作仅仅是释放了构成表的页和区。下面这个代码可以查看日志具体所做操作的描述: 结果如图2：

图2.日志操作描述（节选）

你可以看出为了快速恢复的目的而加的相关锁（你可以在我的博文:Lock logging and fast recovery中了解更多）。

由上面日志看出，这个操作会对8个页加相关的锁，然后整个区一次性释放。释放过后会对相关的区加IX锁,也就是不能再被使用,当事务提交后才会进行deferred-drop,因此也就保证了Truncate table操作可以回滚。

另外，如果表上存在非聚集索引.那么操作方式也是类似，都是交给一个后台线程然后释放表和索引的页。释放的最小单位就是每个分配单元。按照上面步骤你自己尝试一下就应该能明白我的意思了。

PS：还有一个关于Truncate Table操作不能回滚的误区,我在:Search Engine Q&A #: When are pages from a truncated table reused?这篇文章中进行了详细的解释。

推荐整理分享SQL Server误区30日谈第19天 Truncate表的操作不会被记录到日志(sql server错误和使用情况报告)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:sql server报错,sql server 3417错误,sqlserver1053怎么解决,sql server错误和使用情况报告,sqlserver1053怎么解决,sql server233错误,sql server233错误,sql server 错误,内容如对您有帮助，希望把文章链接给更多的朋友！

SQL Server误区日谈第天破坏日志备份链之后，需要一个完整备份来重新开始日志链误区#:在破坏日志备份链之后，需要一个完整备份来重新开始日志链错误事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有

SQL Server误区日谈第天数据损坏可以通过重启SQL Server来修复误区#:数据库损坏可以通过重启SQLServer或是Windows,或是附加和分离数据库解决错误SQLServer中没有任何一项操作可以修复数据损坏。损坏的页当然需要通

SQL Server误区日谈第天资源调控器可以调控IO 误区#:资源调控器可以调控IO错误资源调控器无法调控IO，希望下一个版本的SQLServer支持调控IO，调控IO对于对于减少对于大表的scan操作带来的性能影响

SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志(sql server错误和使用情况报告)

SQL Server误区30日谈第19天 Truncate表的操作不会被记录到日志(sql server错误和使用情况报告)