一区二区三区在线-一区二区三区亚洲视频-一区二区三区亚洲-一区二区三区午夜-一区二区三区四区在线视频-一区二区三区四区在线免费观看

服務(wù)器之家:專注于服務(wù)器技術(shù)及軟件下載分享
分類導(dǎo)航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|數(shù)據(jù)庫技術(shù)|

服務(wù)器之家 - 數(shù)據(jù)庫 - Sql Server - SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會被記錄到日志

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

2019-12-28 15:38MSSQL教程網(wǎng) Sql Server

這個誤區(qū)也同樣流傳已久,我想是時候通過一些Demo進行揭穿了

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

錯誤 



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

Truncate Table語句會將整個表中的所有數(shù)據(jù)刪除。但刪除的方式并不是一行一行的刪除,而是將組成表的數(shù)據(jù)頁釋放,將組成表的相關(guān)頁釋放的操作交給一個后臺的線程進行隊列處理的過程被稱為deferred-drop。使用后臺線程處理deferred-drop的好處是這個操作不會使得其所在的事務(wù)需要執(zhí)行很長時間,因此也就不需要大量的鎖。在SQL Server 2000SP3之前的版本(這個版本引入了deferred-drop)在Truncate Table的時候出現(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ù)模式是簡單,所以每個Checkpoint都會截斷日志(僅僅是為了簡單,哈哈)。 

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

復(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并不會逐行刪除,因為這541條日志記錄刪除的是1280條數(shù)據(jù)。 

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

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


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


下面是結(jié)果: 

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

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

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

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

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


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



結(jié)果如圖2: 

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

 

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

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

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

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

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

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板: a男人天堂 | 国产拍拍拍免费专区在线观看 | 乌克兰一级毛片 | 国产精品亚洲午夜一区二区三区 | 国产成人精品日本亚洲网址 | 日本免费一区二区三区四区五六区 | 蜜桃视频一区二区 | 精品无码人妻一区二区免费AV | 天堂va在线| 亚洲邪恶天堂影院在线观看 | 亚洲AV无码专区国产精品麻豆 | 精品视频一区二区三区免费 | 我年轻漂亮的继坶2中字在线播放 | 青草国产 | 亚洲免费在线看 | www.9p234.com| 男人晚上适合偷偷看的污污 | 国产欧美精品专区一区二区 | 国产成+人+综合+亚洲不卡 | 午夜影院免费看 | 视频大全在线观看免费 | 涩涩屋在线观看 | 波多野结衣178部中文字幕 | 午夜电影三级还珠格格 | 99视频福利| 2021精品国夜夜天天拍拍 | 视频大全在线观看网址 | 喷出奶汁了h| 久久久久青草大香线综合精品 | 毛片免费在线视频 | 精品一区heyzo在线播放 | 欧美黑人成人免费全部 | 美味情缘韩国在线观看视频 | 女海盗斯蒂内塔的复仇2免费观看 | 免费一级生活片 | 青草欧美 | 午夜国产视频 | 高h舔穴| 国模李丽莎大尺度啪啪 | 大胆国模一区二区三区伊人 | 91在线精品视频 |