Posts

Showing posts from December, 2014

[SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

Image
背景:
公司最近把一套每天有相對大量交易(之前公司更大很多很多倍)的系統轉移到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的塔配。

實現步驟:
好吧,根據之前實作流程的結論動手做看看吧。要自動化整個備份工…