SQL Server誤區30日談 第19天 Truncate表的操作不會被記錄到日誌

誤區 #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 Q&A #10: When are pages from a truncated table reused?這篇文章中進行了詳細的解釋。