程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> SQLServer日志配置問題

SQLServer日志配置問題

編輯:關於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延遲。這些會在將來的文章中解釋。

    1. 上一頁:
    2. 下一頁:
    Copyright © 程式師世界 All Rights Reserved