交易日志（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 時才能進行
注意
一般立成建立的數據庫默認屬性已設好
但碰到意外情況使數據庫屬性被更改
請用戶清空日志後
檢查數據庫的以上屬性
以防事務日志再次充滿
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22123.html
