| 導購 | 订阅 | 在线投稿
分享
 
 
 

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

來源:互聯網  2008-06-14 05:54:14  評論

事務日志(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 7.0 和 SQL Server 2000 中,如果設置了自動增長功能,事務日志文件將會自動擴展。

一般情況下,在能夠容納兩次事務日志截斷之間發生的最大數量的事務時,事務日志的大小是穩定的,事務日志截斷由檢查點或者事務日志備份觸發。

然而,在某些情況下,事務日志可能會變得非常大,以致用盡空間或變滿。通常,在事務日志文件占盡可用磁盤空間且不能再擴展時,您將收到如下錯誤消息:

Error:9002, Severity:17, State:2

The log file for database '%.*ls' is full.

除了出現此錯誤消息之外,SQL Server 還可能因爲缺少事務日志擴展空間而將數據庫標記爲 SUSPECT。有關如何從此情形中恢複的其他信息,請參見 SQL Server 聯機幫助中的「磁盤空間不足」主題。

另外,事務日志擴展可能導致下列情形:

· 非常大的事務日志文件。

· 事務可能會失敗並可能開始回滾。

· 事務可能會用很長時間才能完成。

· 可能發生性能問題。

· 可能發生阻塞現象。

原因

事務日志擴展可能由于以下原因或情形而發生:

· 未提交的事務

· 非常大的事務

· 操作:DBCC DBREINDEX 和 CREATE INDEX

· 在從事務日志備份還原時

· 客戶端應用程序不處理所有結果

· 查詢在事務日志完成擴展之前超時,您收到假的「Log Full」錯誤消息

· 未複制的事務

解決方法:

日志文件滿而造成SQL數據庫無法寫入文件時,可用兩種方法:

一種方法:清空日志。

1.打開查詢分析器,輸入命令

DUMP TRANSACTION 數據庫名 WITH NO_LOG

2.再打開企業管理器--右鍵你要壓縮的數據庫--所有任務--收縮數據庫--收縮文件--選擇日志文件--在收縮方式裏選擇收縮至XXM,這裏會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。

另一種方法有一定的風險性,因爲SQL SERVER的日志文件不是即時寫入數據庫主文件的,如處理不當,會造成數據的損失。

1.分離數據庫 企業管理器->服務器->數據庫->右鍵->分離數據庫

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 時才能進行。

注意:一般立成建立的數據庫默認屬性已設好,但碰到意外情況使數據庫屬性被更改,請用戶清空日志後,檢查數據庫的以上屬性,以防事務日志再次充滿。

事務日志(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 7.0 和 SQL Server 2000 中,如果設置了自動增長功能,事務日志文件將會自動擴展。   一般情況下,在能夠容納兩次事務日志截斷之間發生的最大數量的事務時,事務日志的大小是穩定的,事務日志截斷由檢查點或者事務日志備份觸發。   然而,在某些情況下,事務日志可能會變得非常大,以致用盡空間或變滿。通常,在事務日志文件占盡可用磁盤空間且不能再擴展時,您將收到如下錯誤消息:   Error:9002, Severity:17, State:2   The log file for database '%.*ls' is full.   除了出現此錯誤消息之外,SQL Server 還可能因爲缺少事務日志擴展空間而將數據庫標記爲 SUSPECT。有關如何從此情形中恢複的其他信息,請參見 SQL Server 聯機幫助中的「磁盤空間不足」主題。   另外,事務日志擴展可能導致下列情形: · 非常大的事務日志文件。 · 事務可能會失敗並可能開始回滾。 · 事務可能會用很長時間才能完成。 · 可能發生性能問題。 · 可能發生阻塞現象。   原因   事務日志擴展可能由于以下原因或情形而發生: · 未提交的事務 · 非常大的事務 · 操作:DBCC DBREINDEX 和 CREATE INDEX · 在從事務日志備份還原時 · 客戶端應用程序不處理所有結果 · 查詢在事務日志完成擴展之前超時,您收到假的「Log Full」錯誤消息 · 未複制的事務 解決方法:   日志文件滿而造成SQL數據庫無法寫入文件時,可用兩種方法: 一種方法:清空日志。 1.打開查詢分析器,輸入命令 DUMP TRANSACTION 數據庫名 WITH NO_LOG 2.再打開企業管理器--右鍵你要壓縮的數據庫--所有任務--收縮數據庫--收縮文件--選擇日志文件--在收縮方式裏選擇收縮至XXM,這裏會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。 另一種方法有一定的風險性,因爲SQL SERVER的日志文件不是即時寫入數據庫主文件的,如處理不當,會造成數據的損失。 1.分離數據庫 企業管理器->服務器->數據庫->右鍵->分離數據庫 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 時才能進行。   注意:一般立成建立的數據庫默認屬性已設好,但碰到意外情況使數據庫屬性被更改,請用戶清空日志後,檢查數據庫的以上屬性,以防事務日志再次充滿。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有