快捷導(dǎo)航

SQL Server誤區(qū)30日談第19天 Truncate表的操作不會(huì)被記錄到日志

更新時(shí)間：2013年01月09日 21:17:32 作者：

這個(gè)誤區(qū)也同樣流傳已久，我想是時(shí)候通過一些Demo進(jìn)行揭穿了

誤區(qū) #19:Truncate表的操作不會(huì)被記錄到日志

錯(cuò)誤

在用戶表中的操作都會(huì)被記錄到日志。在SQL Server中唯一不會(huì)被記錄到日志的操作是TempDB中的行版本控制。

Truncate Table語句會(huì)將整個(gè)表中的所有數(shù)據(jù)刪除。但刪除的方式并不是一行一行的刪除，而是將組成表的數(shù)據(jù)頁釋放，將組成表的相關(guān)頁釋放的操作交給一個(gè)后臺(tái)的線程進(jìn)行隊(duì)列處理的過程被稱為deferred-drop。使用后臺(tái)線程處理deferred-drop的好處是這個(gè)操作不會(huì)使得其所在的事務(wù)需要執(zhí)行很長時(shí)間，因此也就不需要大量的鎖。在SQL Server 2000SP3之前的版本（這個(gè)版本引入了deferred-drop）在Truncate Table的時(shí)候出現(xiàn)過多的鎖耗盡內(nèi)存的事是家常便飯。

下面是測試代碼:

復(fù)制代碼代碼如下:

 
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 

上面的測試數(shù)據(jù)庫恢復(fù)模式是簡單，所以每個(gè)Checkpoint都會(huì)截?cái)嗳罩?僅僅是為了簡單，哈哈)。

一分鐘后讓我們來看看日志中有多少條記錄。

復(fù)制代碼代碼如下:

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

可以看到，現(xiàn)在的日志條目數(shù)字為2。

如果你得到的數(shù)字不是2，那么再做一次Checkpoint直到數(shù)據(jù)是2為止。

現(xiàn)在已有的日志已經(jīng)知道了，那么日志的增長就是由于后面的操作所導(dǎo)致。下面我們執(zhí)行如下代碼:

復(fù)制代碼代碼如下:

 
TRUNCATE TABLE t1; 
GO 

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

可以看到現(xiàn)在已經(jīng)有了541條日志記錄。很明顯Truncate操作是需要記錄到日志中的。但也可以看出Truncate并不會(huì)逐行刪除,因?yàn)檫@541條日志記錄刪除的是1280條數(shù)據(jù)。

執(zhí)行下面語句來查看日志:

復(fù)制代碼代碼如下:

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

下面是結(jié)果: 2012-10-18_135444

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

通過日志可以看出第一條顯式開始Truncate Table事務(wù)，最后一條開始DeferredAlloc。正如你所見，Truncate操作僅僅是釋放了構(gòu)成表的頁和區(qū)。

下面這個(gè)代碼可以查看日志具體所做操作的描述:

復(fù)制代碼代碼如下:

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

結(jié)果如圖2：

圖2.日志操作描述（節(jié)選）

你可以看出為了快速恢復(fù)的目的而加的相關(guān)鎖（你可以在我的博文:Lock logging and fast recovery中了解更多）。

由上面日志看出，這個(gè)操作會(huì)對8個(gè)頁加相關(guān)的鎖，然后整個(gè)區(qū)一次性釋放。釋放過后會(huì)對相關(guān)的區(qū)加IX鎖,也就是不能再被使用,當(dāng)事務(wù)提交后才會(huì)進(jìn)行deferred-drop,因此也就保證了Truncate table操作可以回滾。

另外，如果表上存在非聚集索引.那么操作方式也是類似，都是交給一個(gè)后臺(tái)線程然后釋放表和索引的頁。釋放的最小單位就是每個(gè)分配單元。按照上面步驟你自己嘗試一下就應(yīng)該能明白我的意思了。

PS：還有一個(gè)關(guān)于Truncate Table操作不能回滾的誤區(qū),我在:Search Engine Q&A #10: When are pages from a truncated table reused?這篇文章中進(jìn)行了詳細(xì)的解釋。

您可能感興趣的文章: