1. SQL Server事務日誌被填滿的原因是什麼
錯誤描述：資料庫的事務日誌已滿。若要查明無法重用日誌中的空間的原因 ，請參閱sys.databases 中的 log_reuse_wait_desc 列 。
首先引入一下事務日誌的概念
事務日誌是一個與資料庫文件分開的文件。它存儲對資料庫進行的所有更改，並全部記錄插入、更新、刪除、提交、回退和資料庫模式變化。事務日誌還稱作前滾日誌或重做日誌。
事務日誌是備份和恢復的重要組件，也是使用 SQL Remote 或 [復制代理] 復制數據所必需的。
在預設情況下，所有資料庫都使用事務日誌。事務日誌的使用是可選的，但是，除非您因特殊原因而不使用，否則您應始終使用它。運行帶有事務日誌的資料庫可提供更強的故障保護功能、更好的性能以及數據復制功能。
引發異常的原因：
a.未提交的事務
b.非常大的事務
c.操作：DBCC DBREINDEX 和 CREATE INDEX
d.在從事務日誌備份還原時
e.客戶端應用程序不處理所有結果
f.查詢在事務日誌完成擴展之前超時，您收到假的「Log Full」錯誤消息
g.未復制的事務
解決辦法：
1.釋放磁碟空間（菜鳥適用）；
2.把資料庫移到內存充足的磁碟（原理同上）；
3.清空日誌：DUMP TRANSACTION 庫名 WITH NO_LOG；
4.截斷事務日誌：BACKUP LOG 庫名 WITH NO_LOG；
2. 如何從根本上解決SQL資料庫日誌已滿的問題
1、你設置了日誌文件的最大數，資料庫的恢復模式是完整恢復模式，所有的針對資料庫的改動都會記錄到日誌，不僅僅是你的改動資料庫，資料庫本身的操作也有記錄到日誌，所以，日誌文件才會不斷增長。
2、那是因為大部分的電腦上的資料庫，基本沒怎麼變過，但生產用的資料庫經常變動，所以日誌記錄也變得巨大，我見過資料庫200MB，但是日誌文件50GB，因為本來資料庫有10GB，因為測試需要刪除了大部分的數據，結果導致日誌文件增長到了50GB。
3、定時備份日誌並收縮日誌文件。
4、通過備份日誌，並收縮日誌文件，這個語句你自己網路。
5、日誌是一個以事務編號連續的記錄，比如，我第一次備份的日誌事務編號為1-1000，那麼日誌就會被截斷，並從1001開始，之後的日誌備份就從1001開始了，所以，初始備份一直到最後一次備份都不能刪除，否則使用日誌恢復時會出現問題。
3. SQL server資料庫日誌滿了怎麼處理
一、刪除日誌文件。
二、手動收縮。操作如下：
1、在資料庫頁面中選擇「選項」；
4. SQL server資料庫日誌滿了怎麼處理
解決方法
日誌文件滿而造成SQL資料庫無法寫入文件時，可用兩種方法：
一種方法：清空日誌。
1．打開查詢分析器，輸入命令
DUMP
TRANSACTION
資料庫名
WITH
NO_LOG
2.再打開企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。
另一種方法有一定的風險性，因為SQL
SERVER的日誌文件不是即時寫入資料庫主文件的，如處理不當，會造成數據的損失。
1:
刪除LOG
分離資料庫
企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫
2：刪除LOG文件
附加資料庫
企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫
此法生成新的LOG，大小隻有500多K。
注意：建議使用第一種方法。
如果以後,不想要它變大。
SQL2000下使用：
在資料庫上點右鍵->屬性->選項->故障恢復-模型-選擇-簡單模型。
或用SQL語句：
alter
database
資料庫名
set
recovery
simple
另外，如上圖中資料庫屬性有兩個選項，與事務日誌的增長有關：
Truncate
log
on
checkpoint
(此選項用於SQL7.0，SQL
2000中即故障恢復模型選擇為簡單模型)
當執行CHECKPOINT
命令時如果事務日誌文件超過其大小的70%
則將其內容清除在開發資料庫時時常將此選項設置為True
Auto
shrink
定期對資料庫進行檢查當資料庫文件或日誌文件的未用空間超過其大小的25%時，系統將會自動縮減文件使其未用空間等於25%
當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日誌文件的縮減只有在對其作備份時或將Truncate
log
on
checkpoint
選項設為True
時才能進行。
注意：一般立成建立的資料庫默認屬性已設好，但碰到意外情況使資料庫屬性被更改，請用戶清空日誌後，檢查資料庫的以上屬性，以防事務日誌再次充滿。
5. SQL Server日誌文件總結及日誌滿的處理
交易日誌（Transaction logs）是資料庫結構中非常重要但又經常被忽略的部分 由於它並不像資料庫中的schema那樣活躍 因此很少有人關注交易日誌 交易日誌是針對資料庫改變所做的記錄 它可以記錄針對資料庫的任何操作 並將記錄結果保存在獨立的文件中 對於任何每一個交易過程 交易日誌都有非常全面的記錄 根據這些記錄可以將數據文件恢復成交易前的狀態 從交易動作開始 交易日誌就處於記錄狀態 交易過程中對資料庫的任何操作都在記錄范圍 直到用戶點擊提交或後退後才結束記錄 每個資料庫都擁有至少一個交易日誌以及一個數據文件 出於性能上的考慮 SQL Server將用戶的改動存入緩存中 這些改變會立即寫入交易日誌 但不會立即寫入數據文件 交易日誌會通過一個標記點來確定某個交易是否已將緩存中的數據寫入數據文件 當SQL Server重啟後 它會查看日誌中最新的標記點 並將這個標記點後面的交易記錄抹去 因為這些交易記錄並沒有真正的將緩存中的數據寫入數據文件 這可以防止那些中斷桐桐畢的交易修改數據文件 維護交易日誌 因為很多人經常遺忘交易日誌 因此它也會給系統帶來一些問題 隨著系統的不斷運行 日誌記錄的內容會越來越多 日誌文件的體積也會越來越大 最終導致可用磁碟空間不足 除非日常工作中經常對日誌進行清理 否則日誌文件最終會侵佔分區內的全部可用空間 日誌的默認配置為不限容量 如果以這種配置工作 它就會不斷膨脹 最終也會占據全部可用空間 這兩種情況都會導致資料庫停止工作 對交易日誌的日常備份工作可以有效的防止日誌文件過分消耗磁碟空間 備份過程會將日誌中不再需要的部分截除 截除的方法是首先把舊記錄標記為非活動狀態 然後將新日誌覆蓋到舊日誌的位置上 這樣就可以防止交易日誌的體積不斷局芹膨脹 如果無法對日誌進行經常性的備份工作 最好將資料庫設置為 簡單恢復模式 在這種模式下 系統會強制交易日誌在每次記錄標記點時 自動進行截除操作 以新日誌覆蓋舊日誌 截除過程發生在備份或將舊標記點標為非活動狀態時 它使得舊的交易記錄可以被覆蓋 但這並不會減少交易日誌實際佔用的磁碟空間 就算不再使用日誌 它依然會占據一定的空間 因此在維護時 還需要對交易日誌進行壓縮 壓縮交易日誌的方法是刪除非活動記錄 從而減少日誌文件所佔用的物理硬碟空間 通過使用DBCC SHRINKDATABASE語句可以壓縮當前資料庫的交易日誌文件 DBCC SHRINKFILE語句用來壓縮指定的交易日誌文件 另外也可以在資料庫中激活自動壓縮操作 當壓縮日誌時 首先會將舊記錄標記為非活動狀態 然後將帶有非活動標記的記錄徹底刪除 根據所使用的壓縮方式的不同 你可能不會立即看到結果 在理想情況下 壓縮工作應該選在系統不是非常繁忙的時段進行 否則有可能影響資料庫性能 恢復資料庫 交易記錄備份可以用來將資料庫恢復到某一指定狀態 但交易記錄備份本身不足以完成恢復資料庫的任務 還需要備份的數據文件參與恢復工作 恢復資料庫時 首先進行的輪斗是數據文件的恢復工作 在整個數據文件恢復完成前 不要將其設為完成狀態 否則交易日誌就不會被恢復 當數據文件恢復完成 系統會通過交易日誌的備份將資料庫恢復成用戶希望的狀態 如果在資料庫最後一次備份後 存在多個日誌文件的備份 備份程序會按照它們建立的時間依次將其恢復 另一種被稱為log shipping的過程可以提供更強的資料庫備份能力 當log shipping配置好後 它可以將資料庫整個復制到另一台伺服器上 在這種情況下 交易日誌也會定期發送到備份伺服器上供恢復數據使用 這使得伺服器一直處於熱備份狀態 當數據發生改變時它也隨之更新 另一個伺服器被稱作監視（monitor）伺服器 可以用來監視按規定時間間隔發送的shipping信號 如果在規定時間內沒有收到信號 監視伺服器會將這一事件記錄到事件日誌 這種機制使得log shipping經常成為災難恢復計劃中使用的方案 性能優化 交易日誌對資料庫有重要作用 同時它對系統的整體性能也有一定影響 通過幾個選項 我們可以對交易日誌的性能進行優化 由於交易日誌是一個連續的磁碟寫入過程 在這當中不會發生讀取動作 因此將日誌文件放在一個獨立的磁碟 對優化性能有一定作用 另一項優化措施與日誌文件的體積有關 我們可以設置日誌文件的體積不超過硬碟空間的百分之幾 或者確定它的大小 如果將其設置的過大會浪費磁碟空間 而如果設置的過小則會強制記錄文件不斷嘗試擴展 導致資料庫性能下降 事務日誌文件Transaction Log File是用來記錄資料庫更新情況的文件 擴展名為ldf 在 SQL Server 和 SQL Server 中 如果設置了自動增長功能 事務日誌文件將會自動擴展 一般情況下 在能夠容納兩次事務日誌截斷之間發生的最大數量的事務時 事務日誌的大小是穩定的 事務日誌截斷由檢查點或者事務日誌備份觸發 然而 在某些情況下 事務日誌可能會變得非常大 以致用盡空間或變滿 通常 在事務日誌文件占盡可用磁碟空間且不能再擴展時 您將收到如下錯誤消息 Error: Severity: State: The log file for database % *ls is full 除了出現此錯誤消息之外 SQL Server 還可能因為缺少事務日誌擴展空間而將資料庫標記為 SUSPECT 有關如何從此情形中恢復的其他信息 請參見 SQL Server 聯機幫助中的 磁碟空間不足 主題 另外 事務日誌擴展可能導致下列情形 · 非常大的事務日誌文件 · 事務可能會失敗並可能開始回滾 · 事務可能會用很長時間才能完成 · 可能發生性能問題 · 可能發生阻塞現象 原因 事務日誌擴展可能由於以下原因或情形而發生 · 未提交的事務· 非常大的事務· 操作 DBCC DBREINDEX 和 CREATE INDEX· 在從事務日誌備份還原時· 客戶端應用程序不處理所有結果· 查詢在事務日誌完成擴展之前超時 您收到假的 Log Full 錯誤消息· 未復制的事務 解決方法 日誌文件滿而造成SQL資料庫無法寫入文件時 可用兩種方法 一種方法 清空日誌 ．打開查詢分析器 輸入命令DUMP TRANSACTION 資料庫名 WITH NO_LOG 再打開企業管理器 右鍵你要壓縮的資料庫 所有任務 收縮資料庫 收縮文件 選擇日誌文件 在收縮方式里選擇收縮至XXM 這里會給出一個允許收縮到的最小M數 直接輸入這個數 確定就可以了 另一種方法有一定的風險性 因為SQL SERVER的日誌文件不是即時寫入資料庫主文件的 如處理不當 會造成數據的損失 : 刪除LOG分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫 刪除LOG文件附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫此法生成新的LOG 大小隻有 多K 注意 建議使用第一種方法 如果以後 不想要它變大 SQL 下使用 在資料庫上點右鍵 >屬性 >選項 >故障恢復 模型 選擇 簡單模型 或用SQL語句 alter database 資料庫名 set recovery simple另外 如上圖中資料庫屬性有兩個選項 與事務日誌的增長有關 Truncate log on checkpoint(此選項用於SQL SQL 中即故障恢復模型選擇為簡單模型)當執行CHECKPOINT 命令時如果事務日誌文件超過其大小的 % 則將其內容清除在開發資料庫時時常將此選項設置為True Auto shrink定期對資料庫進行檢查當資料庫文件或日誌文件的未用空間超過其大小的 %時 系統將會自動縮減文件使其未用空間等於 % 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日誌文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行 注意 一般立成建立的資料庫默認屬性已設好 但碰到意外情況使資料庫屬性被更改 請用戶清空日誌後 檢查資料庫的以上屬性 以防事務日誌再次充滿 lishixin/Article/program/SQLServer/201311/22123