MSSQL_事務日誌已滿，因為發生Log_Backup

日誌檔案太大 是我們很多數據庫都常遇見的一個問題
主要客觀原因是
1. 資料庫復原模式選擇「完整」，但從未進行 log 備份（這是我們主要面臨的問題）
2. 進行了大量的批次寫入動作或者是複雜龐大的交易所導致

	我們所面臨的情況是
		1. 很多舊的數據庫更新數據的時候都是使用刷掉重新塞數據的方法；
		2.  由於數據庫結構不健康導致很多計算和操作都後面靠數據庫服務器（利用存儲過程）完成，導致數據庫經常要處理大量的事務；
		3. 很多舊的數據庫服務模式已經固定，修改起來有難度）。
		所以， 定期進行資料庫交易紀錄備份和清理是可以比較好的解決交易記錄檔爆炸的問題（待處理）

對於短時間內無法修改的數據庫 ： 可以在數據庫備份完成之後直接執行日誌壓縮，這可以有效的騰出磁盤空間

補充1 ：
關於復原模式的選擇
復原模式的設計目的是要控制交易記錄維護。復原模式共有三種：簡單、完整和大量記錄。 一般而言，資料庫會使用完整復原模式或簡單復原模式。 資料庫可以隨時切換到另一個復原模式。
我們可以根據具體的業務情況選擇合適的復原模式。
默認是完整的復原模式，如果選則這個模式，要記得定期進行資料庫交易紀錄備份（選擇合適的備份策略），否則交易紀錄會一直成長，直到儲存空間用盡。
簡單復原模式 ，在 CheckPoint 時間點上，就會自動清空 log file 檔案空間，因此簡單復原模式不支援需要交易記錄備份的作業。
大量記錄，記錄備份的大小可能會十分龐大，因為記錄備份會擷取最低限度記錄的作業。
補充2
何谓交易日志 （https://blog.51ct