熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> SQL Server >> 正文

SQL Server日志文件總結及日志滿的處理

2013-11-15 14:39:09  來源: 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
  
  (此選項用於SQLSQL 中即故障恢復模型選擇為簡單模型)
  
  當執行CHECKPOINT 命令時如果事務日志文件超過其大小的% 則將其內容清除在開發數據庫時時常將此選項設置為True Auto shrink定期對數據庫進行檢查當數據庫文件或日志文件的未用空間超過其大小的%時系統將會自動縮減文件使其未用空間等於% 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日志文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行
  
  注意一般立成建立的數據庫默認屬性已設好但碰到意外情況使數據庫屬性被更改請用戶清空日志後檢查數據庫的以上屬性以防事務日志再次充滿
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22123.html
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.