建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
在這篇文章里，我想詳細(xì)談下為什么你要避免事務(wù)日志（Transaction Log）上的自動(dòng)增長(zhǎng)操作（Auto Growth operations）。很多運(yùn)行的數(shù)據(jù)庫(kù)服務(wù)器，對(duì)于事務(wù)日志，用的都是默認(rèn)的日志文件大小和自動(dòng)增長(zhǎng)設(shè)置。人們有時(shí)會(huì)很依賴(lài)自動(dòng)增長(zhǎng)機(jī)制，因?yàn)樗鼈儎?好能正常工作。當(dāng)然，如果它正常工作的話，你不必太關(guān)注它，但很快你會(huì)發(fā)現(xiàn)會(huì)有問(wèn)題出現(xiàn)。
成都創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的三河網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
只依賴(lài)于事務(wù)日志的自動(dòng)增長(zhǎng)機(jī)制總不是個(gè)好主意。首先它會(huì)導(dǎo)致嚴(yán)重的日志碎片（Log Fragmentation），在SQL Server啟動(dòng)期間，在你數(shù)據(jù)庫(kù)上執(zhí)行崩潰恢復(fù)（Crash Recovery）時(shí)會(huì)有很大的負(fù)面影響。另外，在你數(shù)據(jù)庫(kù)里寫(xiě)入事務(wù)需要等待，只要事務(wù)日志觸發(fā)了自動(dòng)增長(zhǎng)機(jī)制。
當(dāng)事務(wù)日志的自動(dòng)增長(zhǎng)機(jī)制發(fā)生時(shí)，SQL Server總要零初始化新塊，這個(gè)會(huì)在文件末尾加上。這和你的SQL Server實(shí)例是否用即時(shí)文件初始化（Instant File Initialization）特權(quán)——事務(wù)日志總會(huì)零初始化。這上面的原因非常明顯：當(dāng)SQL Server在過(guò)去已經(jīng)完成事務(wù)日志的環(huán)繞式處理（wrap-around ），崩潰恢復(fù)（Crash Recovery）需要知道在哪里停。
零初始化的問(wèn)題是會(huì)占用更多的時(shí)間（取決與你的自動(dòng)增長(zhǎng)率，還有你的存儲(chǔ)速度）。在此期間沒(méi)有別的事務(wù)可以寫(xiě)事務(wù)日志記錄到事務(wù)日志。在事務(wù)日志管 理器上會(huì)有閂鎖造成的阻塞。因此你的寫(xiě)入事務(wù)會(huì)進(jìn)入掛起狀態(tài)（直到它們獲得需要的閂鎖），它們就等啊，等啊，等啊，直到你的事務(wù)日志自動(dòng)增長(zhǎng)完成。讓我們 用一個(gè)簡(jiǎn)單的例子演示下。
首先我為這個(gè)演示創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù)。對(duì)于這個(gè)數(shù)據(jù)庫(kù)，這里我不用默認(rèn)的設(shè)置，對(duì)于事務(wù)日志，我指定了10GB的自動(dòng)增長(zhǎng)系數(shù)。這個(gè)的確是個(gè)不好的做法，但我只是用它來(lái)展示這個(gè)設(shè)置的副作用。請(qǐng)不要在你的生產(chǎn)數(shù)據(jù)庫(kù)里使用這個(gè)錯(cuò)誤配置?。?！
- -- Create a new database with 10 GB Auto Growth for the Transaction Log
- CREATE DATABASE AutoGrowthTransactionLog ON PRIMARY
- (
- NAME = N'AutoGrowthTransactionLog',
- FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\AutoGrowthTransactionLog.mdf',
- SIZE = 5120KB,
- FILEGROWTH = 1024KB
- )
- LOG ON
- (
- NAME = N'AutoGrowthTransactionLog_log',
- FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\AutoGrowthTransactionLog_log.ldf',
- SIZE = 1024KB,
- FILEGROWTH = 10240000KB -- 10 GB Auto Growth!
- )
- GO
下一步里我在數(shù)據(jù)庫(kù)里創(chuàng)建2個(gè)表。第1個(gè)表我通過(guò)插入一些日志來(lái)快速填充我的事務(wù)日志。在事務(wù)日志自動(dòng)增長(zhǎng)階段，我們?cè)诘?個(gè)表里插入新的記錄來(lái)證明這個(gè)事務(wù)會(huì)被自動(dòng)增長(zhǎng)機(jī)制阻塞。
- -- Create a new table, every records needs a page of 8kb
- CREATE TABLE Chunk
- (
- Col1 INT IDENTITY PRIMARY KEY,
- Col2 CHAR(8000)
- )
- GO
- -- Another simple table
- CREATE TABLE Foo
- (
- Bar INT NOT NULL
- )
- GO
現(xiàn)在我們已經(jīng)創(chuàng)建了必須的數(shù)據(jù)庫(kù)對(duì)象，因次我可以通過(guò)新的沒(méi)有立即提交的事務(wù)來(lái)填充事務(wù)日志：
- -- Begin a new transaction, that blocks the 1st VLF in the Transaction Log
- BEGIN TRANSACTION
- INSERT INTO Chunk VALUES (REPLICATE('x', 8000))
- GO
因?yàn)槲覀儸F(xiàn)在有了進(jìn)行中，沒(méi)提交的事務(wù)，SQL Server不能重用那部分事務(wù)日志，即這個(gè)事務(wù)存儲(chǔ)的事務(wù)日志。它們有需要回滾的可能。因此現(xiàn)在我通過(guò)不同的會(huì)話插入66條其他記錄來(lái)填充事務(wù)日志：
INSERT INTO AutoGrowthTransactionLog.dbo.Chunk VALUES (REPLICATE('x', 8000))
GO 66
***在***個(gè)會(huì)話里提交我們的事務(wù)：
COMMIT
這意味著在我們面前有一個(gè)幾乎滿的的事務(wù)日志，我們可以通過(guò)DBCC LOGINFO來(lái)驗(yàn)證：
DBCC LOGINFO
現(xiàn)在當(dāng)我們往表里插入兮的記錄時(shí)，事務(wù)日志已經(jīng)沒(méi)有可用空間了，SQL Server進(jìn)入事務(wù)日志的自動(dòng)增長(zhǎng)。
- -- This statement will trigger the Auto Growth mechanism!
- INSERT INTO Chunk VALUES (REPLICATE('x', 8000))
- GO
在自動(dòng)增長(zhǎng)期間的同時(shí)，為了監(jiān)控發(fā)生了什么，我們可以在SSMS里打開(kāi)新的一個(gè)會(huì)話窗口，嘗試在第2個(gè)表插入另外的記錄——表Foo：
-- This statement is now blocked by the Auto Growth mechanism.
INSERT INTO Foo VALUES (1)
GO
這個(gè)SQL 語(yǔ)句會(huì)阻塞，因?yàn)槭聞?wù)要寫(xiě)入事務(wù)日志記錄的事務(wù)日志，當(dāng)前不可用。為了進(jìn)一步分析這個(gè)阻塞情形，你可以打開(kāi)第3個(gè)會(huì)話窗口，執(zhí)行下列2個(gè)SQL語(yǔ)句：
- -- Analyze the blocking situation
- SELECT wait_type, * FROM sys.dm_exec_requests
- WHERE session_id IN (54, 55)
- SELECT wait_type, * FROM sys.dm_os_waiting_tasks
- WHERE session_id IN (54, 55)
- GO
（額，俺本機(jī)測(cè)試失敗………………）
從代碼里可以看到，我用2個(gè)DMV sys.dm_exec_requests 和 sys.dm_os_waiting_tasks對(duì)2個(gè)會(huì)話都進(jìn)行了跟蹤——觸發(fā)自動(dòng)增長(zhǎng)的會(huì)話，和被自動(dòng)增長(zhǎng)機(jī)制阻塞的會(huì)話。在這里，觸發(fā)自動(dòng)增長(zhǎng)的會(huì) 話里有所謂的搶占等待類(lèi)型（Preemptive Wait Type）——PREEMPTIVE_OS_WRITEFILEGATHER。搶占等待類(lèi)型是由SQL Server返回的等待類(lèi)型，當(dāng)SQL Server 執(zhí)行一個(gè)WIN32 API函數(shù)在調(diào)度機(jī)制之外時(shí)。這里自動(dòng)增長(zhǎng)是通過(guò)WriteFileGather的WIN32 API函數(shù)完成的。
INSERT語(yǔ)句嘗試在Foo表里插入新的記錄出現(xiàn)LATCH_EX等待類(lèi)型。如你從DMV sys.dm_os_waiting_tasks 里的resource_description列所見(jiàn)，在SQL Server的日志管理器上需要獲得閂鎖。你可以通過(guò)查詢(xún)DMV sys.dm_os_latch_stats 限制lactch class為L(zhǎng)OG_MANAGER再次確認(rèn)。在那個(gè)特定閂鎖上你會(huì)看到一些等待。那個(gè)閂鎖是事務(wù)獲取的，由事務(wù)日志的自動(dòng)增長(zhǎng)觸發(fā)，只要這個(gè)閂鎖要獲 得，每個(gè)其他寫(xiě)事務(wù)都會(huì)被阻塞。因此在系統(tǒng)上有大量等待時(shí)間時(shí)，這暗示這在事務(wù)日志里當(dāng)前有自動(dòng)增長(zhǎng)問(wèn)題需要處理。
希望我已經(jīng)用這個(gè)日志說(shuō)服你，依賴(lài)于事務(wù)日志的自動(dòng)增長(zhǎng)機(jī)制并不是***的解決方案。用這個(gè)簡(jiǎn)單的例子可以看到，在你數(shù)據(jù)庫(kù)里每個(gè)被自動(dòng)增長(zhǎng)操作阻塞的寫(xiě)入事務(wù)會(huì)發(fā)生阻塞，這肯定會(huì)傷及你數(shù)據(jù)庫(kù)的吞吐量和擴(kuò)展性。為了保證你有很好的事務(wù)日志性能，你可以***想實(shí)踐下這個(gè)文章。
當(dāng)前名稱(chēng)：為什么事務(wù)日志自動(dòng)增長(zhǎng)會(huì)降低你的性能
URL標(biāo)題：http://m.5511xx.com/article/dheciei.html
