您現在的位置: 萬盛學電腦網 >> 程序編程 >> 數據庫 >> 數據庫綜合 >> SQLServer日志配置問題介紹

SQLServer日志配置問題介紹

作者:佚名    責任編輯:admin    更新時間:    2016-07-05 18:17:25

我們為大家收集整理了關于SQLServer日志配置問題,以方便大家參考。

太多VLFs

SQL Server數據庫引擎在內部將每一物理日志文件分成多個虛擬日志文件,這樣日志管理系統可以輕松的跟蹤那些部分是可以被重用的。事務日志文件根據下面的公式決定生成多少個VLFs,不管是自動增長還是手動增長:

Up to 1MB

2 VLFs, each roughly 1/2 of the total size

1MB to 64MB

4 VLFs, each roughly 1/4 of the total size

64MB to 1GB

8 VLFs, each roughly 1/8 of the total size

More than 1GB

16 VLFs, each roughly 1/16 of the total size

舉個例子,如果創建一個8GB的事務日志文件,那么會得到16個VLF,每個大約512MB.如果日志一次性增長4GB,那么我們會得到另外16個VLF,每個大約256MB,整個文件具有32個VLF.

一般最好的做法是設置日志的自動增長而不是默認的10%,這樣你可以更好控制日志由于zero-initializing操作導致的暫停。比方說,你創建一個256MB的事務日志,并設置自動增長到32MB,然后將日志增長到16GB的穩態大小。根據上述公式,這將導致你的交易記錄有4000多的VLF。

這許多的VLF很可能會對需要事務日志的操作(如崩潰恢復,清除日志,日志備份,事務復制,數據庫恢復)產生性能問題。這種情況被稱為有VLF碎片。一般來說任何數量的VLF超過一千元左右將是有問題的,需要加以解決(我曾經聽說過的最多的是154萬的VLF在超過1TB的大小事務日志!)。

太多的VLFs可能會導致一些操作在處理日志的時候遇到性能問題(比如崩潰恢復,清除日志,日志備份,事務復制,數據庫恢復)。這種情況被稱為VLF碎片。一般來說超過1000的VLF是有問題的,需要加以解決(我曾經聽說過的1TB的事務日志文件有超過154W的VLF).

查詢VLFs的數量可以使用undocumented(絕對安全)的DBCC LOGINFO命令。輸出的行數就是VLF在事務日志中的數量。如果你覺得VLF太多,可以用下面的方式減少:

1. 清除日志(比如通過日志備份等等截斷日志)

2. 手動收縮日志文件

3. 重復步驟1和2,直到日志達到小尺寸(在繁忙的生產系統可能會比較麻煩)

4. 手動將日志增長到期望的大小,比如8GB這樣VLFS單個VLF不超過0.5GB.

你可以閱讀更多有關VLF碎片問題并且如何解決:

· Microsoft KB article that advises reducing VLF numbers

· Can log files growth affect DML?

· 8 steps to better transaction log throughput

Tempdb

Tempdb日志配置應該跟其他數據庫一樣,而且也會像其他數據庫一樣自動增長。但是它有一些潛在的因素會導致問題。當一個SQL Server實例重新啟動后,tempdb數據庫的數據和日志文件將恢復到初始文件設置的大小,而其他數據庫會保持當前大小不變。

這種行為意味著當tmpdb已經增長到合適大小,你必須使用Alter database設置日志文件的固定大小,否則重啟之后日志文件需要從設置的初始值增長到合適大小。每當日志增長,新的空間必須要做零初始化并且將導致日志記錄暫停,這個會影響性能。所以如果你沒有正確的管理tempdb日志文件的大小,那么在實例重啟之后你將會付出性能的損失。

定期日志收縮

很多時候聽到人們說他們在發現由于一些些普通的操作(例如每周一次的數據導入)導致數據庫日志增長時,會做定期的收縮,這個操作我是不建議的。

正如我上面所解釋的,每當事務日志增長或自動增長,都會因為日志文件zero-initialize動作導致停頓。如果事務日志文件經常需要增長到大小x,那么這意味著你的應用將會在日志增長到X的過程中遭受性能影響。

如果你的交易記錄不斷增加X大小,不要管它!主動將其設置為大小X,按照我們上面提到的方法管理VLF,因為這個大小是數據庫正常操作需要的。

多個事務日志文件

一個數據庫創建多個日志文件對性能不會有提升。當前的日志空間不足時,可能需要增加第二個日志文件。如果不增加第二個日志文件可以通過將數據庫的恢復模式修改為Simple并且執行檢查點(這會打破記錄備份鏈)。

經常有人問我是否要除去第二個日志文件還是將它保留在原處。答案是盡快將其移除。

雖然第二個日志文件不會導致性能問題,但是可能影響災難恢復。如果你的數據庫由于某種原因被損壞,你需要從頭恢復。還原的第一步是當數據和日志文件不存在的時候創建這兩個文件。當你創建數據文件的時候可以啟用instantfile initialization參數,這個選項會跳過zero-initialization,但是這個參數不適用于日志文件。這意味著使用完整備份恢復需要創建所有的日志文件(或在事務日志備份恢復期間)并且做zero-initialize。如果創建了第二個日志文件但是沒有刪除,zero-initialize過程增加了總的停機時間。雖然這不會導致性能問題,但是影響了服務器的可用性。

從數據庫快照恢復

最后一個問題其實是在SQL Server中的bug。如果你使用一個數據庫快照,以此來快速恢復到某個時間已知點從而避免還原備份(稱為從快照恢復),那么你就可以節省大量的時間。然而,有一個很大的缺點。

當數據庫從數據庫快照恢復,事務日志重新創建了兩個0.25MB的VLF。這意味著你需要手動調整日志文件大小到最佳值(或它會??自動增長),否則又會導致前面提到的零初始化并且導致日志暫停的問題,顯然這不是我們期望的。

總結:

從這篇文章可以看出,有很多事情可以導致事務日志性能問題,進而導致整個庫性能問題。可以利用我們上面提到的方法設置你的日志,這樣會擁有健康的日志。除此之外,你還需要監視事務日志,比如由于自動增長和 過度的讀取和寫入IO延遲。這些會在將來的文章中解釋。

希望大家可以學會SQLServer日志配置問題.想了解更多精彩內容,請關注我們的網站!

相關推薦:

SQLserver本地管理員帳號無法登錄怎么辦呢

内蒙古十一选五跨度走势图