SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志
更新時間：2013年01月09日 21:17:32 作者：
這個誤區(qū)也同樣流傳已久，我想是時候通過一些Demo進行揭穿了
誤區(qū) #19:Truncate表的操作不會被記錄到日志
錯誤
在用戶表中的操作都會被記錄到日志。在SQL Server中唯一不會被記錄到日志的操作是TempDB中的行版本控制。
Truncate Table語句會將整個表中的所有數(shù)據(jù)刪除。但刪除的方式并不是一行一行的刪除，而是將組成表的數(shù)據(jù)頁釋放，將組成表的相關頁釋放的操作交給一個后臺的線程進行隊列處理的過程被稱為deferred-drop。使用后臺線程處理deferred-drop的好處是這個操作不會使得其所在的事務需要執(zhí)行很長時間，因此也就不需要大量的鎖。在SQL Server 2000SP3之前的版本（這個版本引入了deferred-drop）在Truncate Table的時候出現(xiàn)過多的鎖耗盡內存的事是家常便飯。
下面是測試代碼:
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ù)庫恢復模式是簡單，所以每個Checkpoint都會截斷日志(僅僅是為了簡單，哈哈)。
一分鐘后讓我們來看看日志中有多少條記錄。
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到，現(xiàn)在的日志條目數(shù)字為2。
如果你得到的數(shù)字不是2，那么再做一次Checkpoint直到數(shù)據(jù)是2為止。
現(xiàn)在已有的日志已經(jīng)知道了，那么日志的增長就是由于后面的操作所導致。下面我們執(zhí)行如下代碼:
TRUNCATE TABLE t1;
GO
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到現(xiàn)在已經(jīng)有了541條日志記錄。很明顯Truncate操作是需要記錄到日志中的。但也可以看出Truncate并不會逐行刪除,因為這541條日志記錄刪除的是1280條數(shù)據(jù)。
執(zhí)行下面語句來查看日志:
SELECT
[Current LSN], [Operation], [Context],
[Transaction ID], [AllocUnitName], [Transaction Name]
FROM fn_dblog (NULL, NULL);
下面是結果:
SELECT
[Current LSN], [Operation], [Lock Information], [Description]
FROM fn_dblog (NULL, NULL);
GO
結果如圖2：
錯誤
在用戶表中的操作都會被記錄到日志。在SQL Server中唯一不會被記錄到日志的操作是TempDB中的行版本控制。
Truncate Table語句會將整個表中的所有數(shù)據(jù)刪除。但刪除的方式并不是一行一行的刪除，而是將組成表的數(shù)據(jù)頁釋放，將組成表的相關頁釋放的操作交給一個后臺的線程進行隊列處理的過程被稱為deferred-drop。使用后臺線程處理deferred-drop的好處是這個操作不會使得其所在的事務需要執(zhí)行很長時間，因此也就不需要大量的鎖。在SQL Server 2000SP3之前的版本（這個版本引入了deferred-drop）在Truncate Table的時候出現(xiàn)過多的鎖耗盡內存的事是家常便飯。
下面是測試代碼:
復制代碼 代碼如下:
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ù)庫恢復模式是簡單，所以每個Checkpoint都會截斷日志(僅僅是為了簡單，哈哈)。
一分鐘后讓我們來看看日志中有多少條記錄。
復制代碼 代碼如下:
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到，現(xiàn)在的日志條目數(shù)字為2。
如果你得到的數(shù)字不是2，那么再做一次Checkpoint直到數(shù)據(jù)是2為止。
現(xiàn)在已有的日志已經(jīng)知道了，那么日志的增長就是由于后面的操作所導致。下面我們執(zhí)行如下代碼:
復制代碼 代碼如下:
TRUNCATE TABLE t1;
GO
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到現(xiàn)在已經(jīng)有了541條日志記錄。很明顯Truncate操作是需要記錄到日志中的。但也可以看出Truncate并不會逐行刪除,因為這541條日志記錄刪除的是1280條數(shù)據(jù)。
執(zhí)行下面語句來查看日志:
復制代碼 代碼如下:
SELECT
[Current LSN], [Operation], [Context],
[Transaction ID], [AllocUnitName], [Transaction Name]
FROM fn_dblog (NULL, NULL);
下面是結果:
圖1.查看Truncate后的日志(部分)
通過日志可以看出第一條顯式開始Truncate Table事務，最后一條開始DeferredAlloc。正如你所見，Truncate操作僅僅是釋放了構成表的頁和區(qū)。
下面這個代碼可以查看日志具體所做操作的描述:
復制代碼 代碼如下:
SELECT
[Current LSN], [Operation], [Lock Information], [Description]
FROM fn_dblog (NULL, NULL);
GO
結果如圖2：
圖2.日志操作描述（節(jié)選）
你可以看出為了快速恢復的目的而加的相關鎖（你可以在我的博文:Lock logging and fast recovery中了解更多）。
由上面日志看出，這個操作會對8個頁加相關的鎖，然后整個區(qū)一次性釋放。釋放過后會對相關的區(qū)加IX鎖,也就是不能再被使用,當事務提交后才會進行deferred-drop,因此也就保證了Truncate table操作可以回滾。
另外，如果表上存在非聚集索引.那么操作方式也是類似，都是交給一個后臺線程然后釋放表和索引的頁。釋放的最小單位就是每個分配單元。按照上面步驟你自己嘗試一下就應該能明白我的意思了。
PS：還有一個關于Truncate Table操作不能回滾的誤區(qū),我在:Search Engine Q&A #10: When are pages from a truncated table reused?這篇文章中進行了詳細的解釋。
您可能感興趣的文章:
- 詳解MySQL中DROP,TRUNCATE 和DELETE的區(qū)別實現(xiàn)mysql從零開始
- sqlserver 日志恢復方法(搞定drop和truncate)
- MySQL刪除數(shù)據(jù)Delete與Truncate語句使用比較
- t-sql清空表數(shù)據(jù)的兩種方式示例(truncate and delete)
- sqlserver中drop、truncate和delete語句的用法
- mysql 刪除操作(delete+TRUNCATE)
- MySQL中truncate誤操作后的數(shù)據(jù)恢復案例
- 詳解SQL中drop、delete和truncate的異同
- 實例理解SQL中truncate和delete的區(qū)別
- SQL Server中TRUNCATE事務回滾操作方法
相關文章
本文主要介紹了 詳解SQL創(chuàng)建表的幾種方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2025-04-04
MS SQL Server數(shù)據(jù)庫清理錯誤日志的方法
SQL服務器磁盤空間爆滿導致數(shù)據(jù)庫無法訪問。遠程到服務器上，發(fā)現(xiàn)原來是SQL錯誤日志文件惹的禍，數(shù)據(jù)庫在1秒內產(chǎn)生上100M大小的日志，沒多長時間就將磁盤空間堵滿了，下面說說解決方案2013-11-11
一條sql語句就實現(xiàn)了分頁效果，但效率不是很高，建議學習，不建議使用，最好用存儲過程2008-12-12
最近在運行系統(tǒng)時需要對所有服務器上數(shù)據(jù)結構進行批量修改某個字段的自增屬性改成非自增2012-05-05
由于有部分語句別名不能調用原來是由于別名機制不同引起的，為了避免下次發(fā)生就整理了一下sql和mysql執(zhí)行順序發(fā)現(xiàn)內部機制是一樣的，最大區(qū)別是在別名的引用上2013-11-11
sqlserver對字段的添加修改刪除、以及字段的說明，需要的朋友可以參考下。2011-12-12
我現(xiàn)在想把S_USER表中的ACCOUNT批量修改成S_PERSON的ACCOUNT，那么就可以參考下面的語句，要找到對應的字段2019-11-11
用SQL語句查詢數(shù)據(jù)庫中某一字段下相同值的記錄方法
本文要處理的事情實際上就是查詢數(shù)據(jù)庫表中某一字段值重復的記錄的方法2014-05-05
mssql 數(shù)據(jù)庫表行轉列，列轉行終極方案
mssql 數(shù)據(jù)庫表行轉列，列轉行終極方案,需要的朋友可以參考下。2010-04-04
本文主要介紹了SQL實現(xiàn)模糊查詢的四種方法總結，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2023-07-07