誤區(qū) #26: SQL Server中存在真正的“事務(wù)嵌套”
錯(cuò)誤
嵌套事務(wù)可不會(huì)像其語(yǔ)法表現(xiàn)的那樣看起來(lái)允許事務(wù)嵌套。我真不知道為什么有人會(huì)這樣寫(xiě)代碼，我唯一能夠想到的就是某個(gè)哥們對(duì)SQL Server社區(qū)嗤之以鼻然后寫(xiě)了這樣的代碼說(shuō)：“玩玩你們”。
讓我更詳細(xì)的解釋一下，SQL Server允許你在一個(gè)事務(wù)中開(kāi)啟嵌套另一個(gè)事務(wù),SQL Server允許你提交這個(gè)嵌套事務(wù)，也允許你回滾這個(gè)事務(wù)。
但是，嵌套事務(wù)并不是真正的“嵌套”，對(duì)于嵌套事務(wù)來(lái)說(shuō)SQL Server僅僅能夠識(shí)別外層的事務(wù)。嵌套事務(wù)是日志不正常增長(zhǎng)的罪魁禍?zhǔn)字灰驗(yàn)殚_(kāi)發(fā)人員以為回滾了內(nèi)層事務(wù)，僅僅是回滾內(nèi)層事務(wù)。
但實(shí)際上當(dāng)回滾內(nèi)層事務(wù)時(shí)，會(huì)回滾整個(gè)事務(wù)，而不是僅僅是內(nèi)層。這也是為什么我說(shuō)嵌套事務(wù)并不存在。
所以作為開(kāi)發(fā)人員來(lái)講，永遠(yuǎn)不要對(duì)事務(wù)進(jìn)行嵌套。事務(wù)嵌套是邪惡的。
如果你不相信我說(shuō)的，那么通過(guò)下面的例子就就會(huì)相信。創(chuàng)建完數(shù)據(jù)庫(kù)和表之后，每一條記錄都會(huì)導(dǎo)致日志增加8K。
復(fù)制代碼 代碼如下:
CREATE DATABASE NestedXactsAreNotReal;
GO
USE NestedXactsAreNotReal;
GO
ALTER DATABASE NestedXactsAreNotReal 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
測(cè)試 #1：回滾內(nèi)部事務(wù)時(shí)僅僅回滾內(nèi)部事務(wù)?
復(fù)制代碼 代碼如下:
BEGIN TRAN OuterTran;
GO
INSERT INTO t1 DEFAULT Values;
GO 1000
BEGIN TRAN InnerTran;
GO
INSERT INTO t1 DEFAULT Values;
GO 1000
SELECT @@TRANCOUNT, COUNT (*) FROM t1;
GO
你可以看到得出的結(jié)果是2和2000，下面我來(lái)回滾內(nèi)部的事務(wù)，按照我們的猜想應(yīng)該只回滾1000條吧，但事實(shí)上你會(huì)得到如下結(jié)果:
復(fù)制代碼 代碼如下:
ROLLBACK TRAN InnerTran;
GO
復(fù)制代碼 代碼如下:
消息 6401，級(jí)別 16，狀態(tài) 1，第 2 行
無(wú)法回滾 InnerTran。找不到該名稱的事務(wù)或保存點(diǎn)。
好吧，由Books Online來(lái)看,我只能使用外部事務(wù)的名稱或是將事務(wù)名稱留空來(lái)進(jìn)行回滾，代碼如下:
復(fù)制代碼 代碼如下:
ROLLBACK TRAN;
GO
SELECT @@TRANCOUNT, COUNT (*) FROM t1;
GO
現(xiàn)在我得到結(jié)果是0和0。正如Books Online所言,這個(gè)回滾操作將外部事務(wù)進(jìn)行了回滾并將全局變量@@TRANCOUNT設(shè)置為0。事務(wù)中所有的修改都被回滾，如果想部分回滾的話只能使用SAVE TRAN 和ROLLBACK TRAN。
測(cè)試 #2：嵌套事務(wù)中內(nèi)部事務(wù)提交后會(huì)保存內(nèi)部事務(wù)的修改嗎？
復(fù)制代碼 代碼如下:
BEGIN TRAN OuterTran;
GO
BEGIN TRAN InnerTran;
GO
INSERT INTO t1 DEFAULT Values;
GO 1000
COMMIT TRAN InnerTran;
GO
SELECT COUNT (*) FROM t1;
GO
正如我所期待，得到的結(jié)果是1000。這說(shuō)明內(nèi)部事務(wù)提交是會(huì)修改到磁盤(pán)的。但是如果這時(shí)外部事務(wù)回滾的話，那么不應(yīng)該回滾內(nèi)部事務(wù)…
復(fù)制代碼 代碼如下:
ROLLBACK TRAN OuterTran;
GO
SELECT COUNT (*) FROM t1;
GO
但運(yùn)行上面查詢后結(jié)果是0，這說(shuō)明外部事務(wù)的回滾會(huì)影響內(nèi)部事務(wù)。
測(cè)試 #3：提交嵌套的事務(wù)的內(nèi)部事務(wù)至少可以讓我清除日志吧。
在開(kāi)始這個(gè)測(cè)試之前我首先清除了日志，然后運(yùn)行如下代碼：
復(fù)制代碼 代碼如下:
BEGIN TRAN OuterTran;
GO
BEGIN TRAN InnerTran;
GO
INSERT INTO t1 DEFAULT Values;
GO 1000
DBCC SQLPERF ('LOGSPACE');
GO
得到結(jié)果:
下面我將事務(wù)提交后運(yùn)行CheckPoint(對(duì)于簡(jiǎn)單恢復(fù)模式的數(shù)據(jù)庫(kù)將會(huì)截?cái)嗳罩?,得到的結(jié)果:
復(fù)制代碼 代碼如下:
COMMIT TRAN InnerTran;
GO
CHECKPOINT;
GO
DBCC SQLPERF ('LOGSPACE');
GO
我們發(fā)現(xiàn)日志的使用不減反贈(zèng)，這是由于日志寫(xiě)入了CheckPoint記錄（詳情請(qǐng)看:How do checkpoints work and what gets logged）。提交內(nèi)部事務(wù)不會(huì)導(dǎo)致日志被清除，這是由于外部事務(wù)回滾時(shí)也會(huì)連同內(nèi)部事務(wù)一起回滾（譯者注：所以這部分VLF在外部事務(wù)提交之前永遠(yuǎn)不會(huì)被標(biāo)記位reusable）。所以這部分日志在外部事務(wù)提交之前永遠(yuǎn)不會(huì)被截?cái)唷榱俗C明這一點(diǎn)，我提交外部事務(wù)，然后再來(lái)看日志：
復(fù)制代碼 代碼如下:
COMMIT TRAN OuterTran;
GO
CHECKPOINT;
GO
DBCC SQLPERF ('LOGSPACE');
GO
么樣，日志使用百分比大幅下降了吧。
對(duì)于嵌套事務(wù)來(lái)說(shuō)---Just Say no。(這句話你可以當(dāng)作來(lái)自SQLSkill.com的一個(gè)熱心的家伙給的福利:-)
您可能感興趣的文章:- SQL Server誤區(qū)30日談 第29天 有關(guān)堆碎片的誤區(qū)
- SQL Server誤區(qū)30日談 第28天 有關(guān)大容量事務(wù)日志恢復(fù)模式的誤區(qū)
- SQL Server誤區(qū)30日談 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
- SQL Server誤區(qū)30日談 第25天 有關(guān)填充因子的誤區(qū)
- SQL Server誤區(qū)30日談 第24天 26個(gè)有關(guān)還原(Restore)的誤區(qū)
- SQL Server誤區(qū)30日談 第23天 有關(guān)鎖升級(jí)的誤區(qū)
- SQL Server誤區(qū)30日談 第22天 資源調(diào)控器可以調(diào)控IO
- SQL Server誤區(qū)30日談 第21天 數(shù)據(jù)損壞可以通過(guò)重啟SQL Server來(lái)修復(fù)
- SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后，需要一個(gè)完整備份來(lái)重新開(kāi)始日志鏈
- SQL Server誤區(qū)30日談 第19天 Truncate表的操作不會(huì)被記錄到日志
- SQL Server誤區(qū)30日談 第18天 有關(guān)FileStream的存儲(chǔ)，垃圾回收以及其它
- SQL Server誤區(qū)30日談 第17天 有關(guān)頁(yè)校驗(yàn)和的誤區(qū)
- SQL Server誤區(qū)30日談 第16天 數(shù)據(jù)的損壞和修復(fù)
- SQL Server誤區(qū)30日談 第15天 CheckPoint只會(huì)將已提交的事務(wù)寫(xiě)入磁盤(pán)
- SQL Server誤區(qū)30日談 第14天 清除日志后會(huì)將相關(guān)的LSN填零初始化
- SQL Server誤區(qū)30日談 第13天 在SQL Server 2000兼容模式下不能使用DMV
- SQL Server誤區(qū)30日談 第12天 TempDB的文件數(shù)和需要和CPU數(shù)目保持一致
- SQL Server誤區(qū)30日談 第11天 鏡像在檢測(cè)到故障后瞬間就能故障轉(zhuǎn)移
- SQL Server誤區(qū)30日談 第10天 數(shù)據(jù)庫(kù)鏡像在故障發(fā)生后 馬上就能發(fā)現(xiàn)
- SQL Server誤區(qū)30日談 第9天 數(shù)據(jù)庫(kù)文件收縮不會(huì)影響性能
- SQL Server誤區(qū)30日談 第8天 有關(guān)對(duì)索引進(jìn)行在線操作的誤區(qū)
- SQL Server誤區(qū)30日談 第7天 一個(gè)實(shí)例多個(gè)鏡像和日志傳送延遲
- SQL Server誤區(qū)30日談 第6天 有關(guān)NULL位圖的三個(gè)誤區(qū)
- SQL Server誤區(qū)30日談 第5天 AWE在64位SQL SERVER中必須開(kāi)啟
- SQL Server誤區(qū)30日談 第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
- SQL Server誤區(qū)30日談 第3天 即時(shí)文件初始化特性可以在SQL Server中開(kāi)啟和關(guān)閉
- SQL Server誤區(qū)30日談 第2天 DBCC CHECKDB會(huì)導(dǎo)致阻塞
- SQL Server誤區(qū)30日談 第1天 正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
- SQL Server誤區(qū)30日談 第30天 有關(guān)備份的30個(gè)誤區(qū)
