|
|
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已! |
|
恭喜您是本站第 1730399
位訪客!
登入 | 註冊
|
|
|
|
發表者 |
討論內容 |
冷日 (冷日) |
發表時間:2016/11/12 7:56 |
- Webmaster

- 註冊日: 2008/2/19
- 來自:
- 發表數: 15773
|
- [轉貼]SQL Server 解決 log 檔(ldf file)過度膨脹的實戰經驗
[SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗 背景:公司最近把一套每天有相對大量交易 (之前公司更大很多很多倍)的系統轉移到SQL Server去,不到一個月交易檔(ldf)已經貼近數據檔(mdf)的size,真的好可怕啊。 身為SQL Server的DBA當然 要替月行道,警惡懲奸 不能讓這種情況繼續下去。
解決方案選擇: - 第一個我想到的方法是把Database的Recovery model設成Simple,簡單來說就是不需要交易記錄,對於Insert Delete Update 很少的系統勉強還說得過去,不過對於交易量大的系統來說就不行了,沒有交易記錄萬一資料庫突然往生,總不能用full backup還原然後要User重新輸入一天的交易吧。
- 第二個方法是定時進行備份。為什麼log大小跟備份有關係呢? 簡單來說,資料庫的ldf檔就是用來儲存Full Backup後所發生的所有交易。如果你從今天從來沒有為資料庫進行過備份, 理論上ldf檔會無限的膨脹下去,而且利用Shrink指令也無法把交易檔壓縮。因為沒備份的話就等於ldf檔裡面的東西統統有用,當然沒辦法壓縮了。所以要保持交易檔案的size就是要持續保持備份,在每次備份完了以後自動把交易檔Truncate成初始大小,這樣可以長期保持相對小的交易檔。
所以,最後我選擇了方案二。 實作流程考慮因素:SQL Server的backup model一定要一份full backup再塔配其他備份檔一起使用( SQL Server的備份model解釋在此),要達到控制ldf檔案大小的目的,備份可以每天只是Full Backup,也可以是Full->T-log,也可以是最複雜Full->Diff->T-log,我考慮使用那一種的因素主要有以下: - 資料庫本身只是約55GB不是太大;
- 每天交易量不多,每分鐘約10筆交易;
- 使用者允許少量的data loss,一天Data loss肯定不行;
- 資料庫只是辦公時間才會用。
我個人認為Backup Plan越簡單越好,發生狀況的時候已經很緊張,複雜的Backup只會令事情更糟。反正今天硬碟實在是太便宜,天天備份幾次也無所謂,因此在儘量簡化備份流程的前題之下,小弟傾向 每天Full BackUp一次,每小時備份一次T-log,就是Full->T-log的塔配。
實現步驟: 好吧,根據之前實作流程的結論動手做看看吧。要自動化整個備份工作,SQL Server 2008以後有一個很好用的工具叫Maintainence Plan,可以把需要routie的日常維護的工作放到這裡。
總結: T-log ldf檔案過大除了浪費空間,還會直接影響系統的效能(想像一下每次要把資料寫進十幾GB的檔案),所以定時清理是必須的,可透過定時的備份把沒用的T-log清理掉,來保持T-log ldf檔不會無限制的過度膨脹。
如發現小弟任何觀念錯了歡迎提出喔^口^ 原文出處:1010: [SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗
|
|
討論串
|