濮阳杆衣贸易有限公司

主頁 > 知識庫 > SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志

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

熱門標簽:浙江穩(wěn)定外呼系統(tǒng)供應商 咸陽電腦外呼系統(tǒng)運營商 美團地圖標注商戶認證注冊 慶陽地圖標注 北京400電話辦理多少錢 榕城市地圖標注 怎么給高德做地圖標注 承德地圖標注公司名需要花錢嗎 電銷外呼系統(tǒng)軟件功能
誤區(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);

下面是結果:    

    圖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 QA #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事務回滾操作方法

標簽:呼和浩特 新鄉(xiāng) 江蘇 重慶 上海 拉薩 昭通 貴州

巨人網(wǎng)絡通訊聲明:本文標題《SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志》,本文關鍵詞  SQL,Server,誤區(qū),30日談,第,;如發(fā)現(xiàn)本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志》相關的同類信息!
  • 本頁收集關于SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志的相關信息資訊供網(wǎng)民參考!
  • 推薦文章
    宁津县| 吉林市| 江西省| 安达市| 甘孜县| 旅游| 拉萨市| 綦江县| 桃源县| 绥滨县| 北碚区| 舟山市| 安龙县| 高尔夫| 即墨市| 陇川县| 喀喇| 华安县| 任丘市| 普陀区| 太湖县| 抚州市| 栾川县| 石屏县| 东方市| 桓台县| 浙江省| 建湖县| 辽中县| 桓仁| 始兴县| 涟水县| 上林县| 保靖县| 博客| 平顶山市| 卢龙县| 永新县| 墨江| 松桃| 绥化市|