主页 > 知识库 > SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

热门标签:浙江稳定外呼系统供应商 咸阳电脑外呼系统运营商 美团地图标注商户认证注册 庆阳地图标注 北京400电话办理多少钱 榕城市地图标注 怎么给高德做地图标注 承德地图标注公司名需要花钱吗 电销外呼系统软件功能
误区 #19:Truncate表的操作不会被记录到日志

错误



在用户表中的操作都会被记录到日志。在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制。

Truncate Table语句会将整个表中的所有数据删除。但删除的方式并不是一行一行的删除,而是将组成表的数据页释放,将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop。使用后台线程处理deferred-drop的好处是这个操作不会使得其所在的事务需要执行很长时间,因此也就不需要大量的锁。在SQL Server 2000SP3之前的版本(这个版本引入了deferred-drop)在Truncate Table的时候出现过多的锁耗尽内存的事是家常便饭。

下面是测试代码:
复制代码 代码如下:

CREATE DATABASE TruncateTest;
GO
USE TruncateTest;
GO
ALTER DATABASE TruncateTest SET RECOVERY SIMPLE;
GO
CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (8000) DEFAULT 'a');
CREATE CLUSTERED INDEX t1c1 on t1 (c1);
GO

SET NOCOUNT ON;
GO

INSERT INTO t1 DEFAULT VALUES;
GO 1280

CHECKPOINT;
GO


上面的测试数据库恢复模式是简单,所以每个Checkpoint都会截断日志(仅仅是为了简单,哈哈)。

一分钟后让我们来看看日志中有多少条记录。

复制代码 代码如下:

SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO



可以看到,现在的日志条目数字为2。

如果你得到的数字不是2,那么再做一次Checkpoint直到数据是2为止。

现在已有的日志已经知道了,那么日志的增长就是由于后面的操作所导致。下面我们执行如下代码:
复制代码 代码如下:

TRUNCATE TABLE t1;
GO

SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO


可以看到现在已经有了541条日志记录。很明显Truncate操作是需要记录到日志中的。但也可以看出Truncate并不会逐行删除,因为这541条日志记录删除的是1280条数据。

执行下面语句来查看日志:
复制代码 代码如下:

SELECT
[Current LSN], [Operation], [Context],
[Transaction ID], [AllocUnitName], [Transaction Name]
FROM fn_dblog (NULL, NULL);

下面是结果:    

    图1.查看Truncate后的日志(部分)

通过日志可以看出第一条显式开始Truncate Table事务,最后一条开始DeferredAlloc。正如你所见,Truncate操作仅仅是释放了构成表的页和区。

下面这个代码可以查看日志具体所做操作的描述:

复制代码 代码如下:

SELECT
[Current LSN], [Operation], [Lock Information], [Description]
FROM fn_dblog (NULL, NULL);
GO


结果如图2:

    图2.日志操作描述(节选)

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

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

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

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

您可能感兴趣的文章:
  • 详解MySQL中DROP,TRUNCATE 和DELETE的区别实现mysql从零开始
  • sqlserver 日志恢复方法(搞定drop和truncate)
  • MySQL删除数据Delete与Truncate语句使用比较
  • t-sql清空表数据的两种方式示例(truncate and delete)
  • sqlserver中drop、truncate和delete语句的用法
  • mysql 删除操作(delete+TRUNCATE)
  • MySQL中truncate误操作后的数据恢复案例
  • 详解SQL中drop、delete和truncate的异同
  • 实例理解SQL中truncate和delete的区别
  • SQL Server中TRUNCATE事务回滚操作方法

标签:呼和浩特 新乡 江苏 重庆 上海 拉萨 昭通 贵州

巨人网络通讯声明:本文标题《SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志》,本文关键词  SQL,Server,误区,30日谈,第,;如发现本文内容存在版权问题,烦请提供相关信息告之我们,我们将及时沟通与处理。本站内容系统采集于网络,涉及言论、版权与本站无关。
  • 相关文章
  • 下面列出与本文章《SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志》相关的同类信息!
  • 本页收集关于SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志的相关信息资讯供网民参考!
  • 推荐文章