前兩天在乙個客戶那裡發現tempdb log 檔案增長很大,已經使用40gb了，而tempdb log 檔案總的分配空間是70gb，並且日誌空間貌似不能重用，他們使用sql 2012 打的sp4補丁，遠端分析問題，沒有發現長時間開啟的事物，業務使用事物都是使用完即時關閉的，而且通過查詢tempdb log 檔案大小發現
--日誌檔案使用情況
select s.name,
convert(float,s.size) * convert(float,8) / 1024.0 as [初始大小mb],
convert(float,i.size) * (8192.0/1024.0)/1024.0 as [分配空間mb],
cast(fileproperty(s.name, 'spaceused') as float)* convert(float,8) / 1024.0 as [使用空間mb]
from
sys.master_files as s ,dbo.sysfiles as i
where s.name=i.name and
(s.type = 1 and s.database_id = db_id())
and s.name = 'templog'
每隔一兩秒的樣子，日誌檔案會增加 3~10 mb的使用空間,因為客戶使用的大量的臨時表，這個導致tempdb 的log 檔案增長，奇怪的是為什麼 之前的髒頁不會被重用，而是要重新分配新的空間？ 唯一能解釋的是可能有 事物長時間開著導致，但前面我們說過通過跟蹤查詢，沒有發現有長時間的事物開啟，所以有事務導致tempdb log 檔案持續增加 ，這個原因 就不成立啦；
通過查閱資料發現，在簡單恢復模式下 ，當日誌已滿 70% 資料庫引擎會自動觸發檢查點， 而我們上面所說客戶日誌分配空間是 70gb ,已經使用了 40gb,所以還不滿足觸發檢查點重新整理髒頁的條件；而另一種自動觸發自動檢查點的機制（恢復間隔）， 則不適用於tempdb ，為了驗證這觀點，我做了實驗 如下：
在本地設定tempdb log的初始大小 109mb,然後建立一張臨時表，再寫入資料，看看日誌檔案的使用情況，
在建立臨時表前 先查詢下 日誌檔案的使用情況，使用空間 3.3mb
建立臨時表 ，再插入一萬條資料
再次檢視 tempdb 日誌檔案的使用情況
這時我們可以 繼續插入 資料，但不要超過日誌70%的空間 ，這時再次記錄下使用空間，因為sqlserver 2012 的預設的檢查點時間為3分鐘 ，我們等3分鐘再看 ，會不會自動觸發檢查點重新整理髒頁，把日誌使用空間**，
三分鐘後 再查，日誌使用空間依舊沒有任何變化
如果再插入一萬條資料 大概會有 十幾mb 的增長，而這時就已經達到 日誌70% 使用的條件，會觸發檢查點去執行，
我們執行下看看 ，#dddd表中已經有8萬條資料了
而日誌的使用空間，已經因檢查點的執行 ，變回為8.5mb的使用空間了。
所以經過本次測試證實之前的觀點是對的，那麼我後來把客戶的 70gb tempdb log 給設小了 ，設成8gb ,觀察了一天，日誌使用空間始終在6gb以下。
日誌檔案不斷增長
原文 日誌檔案不斷增長 sqlserver定時執行 checkpoint 保證 髒頁 被寫入硬碟。沒做checkpoint的，可能是只在記憶體中修改，資料檔案還沒同步。sqlserver要在硬碟的日誌檔案中有記錄，一邊異常重啟後重新修改。所有日誌都有嚴格順序，不能有跳躍。如果恢復模式不是簡單模式，那...
日誌檔案不斷增長
sqlserver定時執行 checkpoint 保證 髒頁 被寫入硬碟。沒做checkpoint的，可能是只在記憶體中修改，資料檔案還沒同步。sqlserver要在硬碟的日誌檔案中有記錄，一邊異常重啟後重新修改。所有日誌都有嚴格順序，不能有跳躍。如果恢復模式不是簡單模式，那麼sqlserver會認...
簡單恢復模式下，日誌檔案的增長
最近公司要把兩個sql sever 2005 資料庫合併成乙個資料庫，乙個資料庫26g，乙個資料庫31g。這只是mdf檔案，不是ldf檔案。在合併之前就考慮到了日誌檔案會很大，但是沒有想到這麼大 把資料庫設定成簡單恢復模式，日誌檔案照樣非常大。簡單恢復模式並不等於沒有或者很少的日誌量。當我使用預設的...