錯誤 在用戶表中的操作都會被記錄到日志。在SQL Server中唯一不會被記錄到日志的操作是TempDB中的行版本控制。 Truncate Table語句會將整個表中的所有數(shù)據(jù)刪除。但刪除的方式并不是一行一行的刪除，而是將組成表的數(shù)據(jù)頁釋放，將組成表的相關頁釋放的操作交給一個后臺的線程進行隊列處理的過程被稱為deferred-drop。使用后臺線程處理deferred-drop的好處是這個操作不會使得其所在的事務需要執(zhí)行很長時間，因此也就不需要大量的鎖。在SQL Server 2000SP3之前的版本（這個版本引入了deferred-drop）在Truncate Table的時候出現(xiàn)過多的鎖耗盡內(nèi)存的事是家常便飯。 下面是測試代碼:
上面的測試數(shù)據(jù)庫恢復模式是簡單，所以每個Checkpoint都會截斷日志(僅僅是為了簡單，哈哈)。 一分鐘后讓我們來看看日志中有多少條記錄。
可以看到，現(xiàn)在的日志條目數(shù)字為2。 如果你得到的數(shù)字不是2，那么再做一次Checkpoint直到數(shù)據(jù)是2為止。 現(xiàn)在已有的日志已經(jīng)知道了，那么日志的增長就是由于后面的操作所導致。下面我們執(zhí)行如下代碼:
可以看到現(xiàn)在已經(jīng)有了541條日志記錄。很明顯Truncate操作是需要記錄到日志中的。但也可以看出Truncate并不會逐行刪除,因為這541條日志記錄刪除的是1280條數(shù)據(jù)。 執(zhí)行下面語句來查看日志:

下面是結(jié)果:

圖1.查看Truncate后的日志(部分) 通過日志可以看出第一條顯式開始Truncate Table事務，最后一條開始DeferredAlloc。正如你所見，Truncate操作僅僅是釋放了構(gòu)成表的頁和區(qū)。 下面這個代碼可以查看日志具體所做操作的描述:

結(jié)果如圖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?這篇文章中進行了詳細的解釋。

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。