本文導讀：SQL Server中的數(shù)據(jù)庫都是由一或多個數(shù)據(jù)文件以及一或多個事務日志文件組成的。SQL Server事務日志主要是用來記錄所有事務對數(shù)據(jù)庫所做的修改，SQL SERVER利用事務日志來確保持久性(Durability)和事務回滾(Rollback)。從而還部分確保了事務的ACID屬性.在SQL Server崩潰時，DBA還可以通過事務日志將數(shù)據(jù)恢復到指定的時間點。

一、SQLSERVER事務日志查看

?

利用下面SQL語句來查看所在數(shù)據(jù)庫的事務日志記錄

?

USE?[GPOSDB]?--要查看事務日志記錄的數(shù)據(jù)庫
GO
SELECT?*?FROM?[sys].[fn_dblog](NULL,NULL)

?

??

一些重要字段的說明

?

CurrentLSN：當前LSN號，事務日志中的每個記錄都由一個唯一的日志序列號 (LSN) 標識。LSN 是這樣排序的：如果 LSN2 大于 LSN1，則 LSN2 所標識的日志記錄描述的更改發(fā)生在日志記錄 LSN1 描述的更改之后

Operation：當前LSN所做的操作

Context：操作的上下文

TransactoinID：事務ID號

Log Record Fixed Length：LSN記錄的所占虛擬日志文件的固定長度

Previous LSN：前一個LSN號

AllocUnitID：修改的那條數(shù)據(jù)所屬分配單元ID

AllocUnitName：修改了數(shù)據(jù)的表名

Page ID：0001:00000121 轉(zhuǎn)換成十進制：289??? 所以查看pageid為289頁? DBCC PAGE([pratice],1,289,3)

Slot ID：數(shù)據(jù)所在數(shù)據(jù)頁面的第幾條記錄

PartitionID：數(shù)據(jù)所在數(shù)據(jù)頁面的所在分區(qū)ID

?

二、Sql Server事務日志滿的解決方法

?

因為磁盤空間已滿，SqlServer服務有可能無法正常啟動。先不要讓應用程序連接數(shù)據(jù)庫。

試著啟動SqlServer服務。看看能否啟動起來。如果不能，需要騰出來一點空間來。刪除一些暫時不要的軟件。總之要讓SqlServer服務啟動起來。如果SqlServer服務能起來，就做下面的。

?

1、執(zhí)行如下語句

backup log tempdb with no_log?? --清除事務日志
go
backup log SharePoint_Config with no_log?? --清除事務日志
go
?
use tempdb
go

dbcc shrinkfile (tempdev, 10240)????? --調(diào)整tempdb的主數(shù)據(jù)文件大小為10240 MB, 可根據(jù)需要調(diào)整, 這個命令不是必須執(zhí)行的。
go

?

?

三、事務在不斷增大的時候如何縮小日志

?

當數(shù)據(jù)如在頻繁修改或者刪除的同時，事務的日志就會不斷的增加，甚至超過了碰盤的大小，這時候就不能因此而直接刪除了事務日志的LDF文件，否則可能會帶來很大的麻煩。為了避免這種情況，我們需要有如下的操作：

1) 、盡量避免tempdb 日志與用戶數(shù)據(jù)庫日志放在同一磁盤上，tempdb 數(shù)據(jù)庫和事務日志具有足夠的空間來處理索引操作。不能在索引操作完成之前截斷 tempdb 事務日志。

2) 、通過執(zhí)行下列命令來縮小事務日志

DBCC SHRINKDATABASE

DBCC SHRINKFILE

操作會立即嘗試將物理日志文件收縮為所要求的大小。

如果虛擬日志文件中的邏輯日志未超出 target_size 標記，則釋放 target_size 標記之后的虛擬日志文件，并成功完成 DBCC 語句，不顯示任何信息。

如果虛擬日志中的邏輯日志超出了 target_size 標記，SQL Server Database Engine 將釋放盡可能多的空間并顯示一個信息性消息。該消息告訴您必須執(zhí)行什么操作來從文件尾部的虛擬日志中刪除邏輯日志。執(zhí)行完該操作后，可以重新發(fā)出 DBCC 語句以釋放剩余的空間。

DBCC SHRINKFILE 語句還顯示一個信息性消息，指出它不能釋放所要求的全部空間，并告訴您可以執(zhí)行 BACKUP LOG 語句來釋放剩余的空間。

?

四、事務日志的還原

事務日志在還原的時候可以選擇三種恢復模式：簡單模式、完整模式和大容量日志模式。

1、簡單恢復模式

此模式簡略地記錄大多數(shù)事務，所記錄的信息只是為了確保在系統(tǒng)崩潰或還原數(shù)據(jù)備份之后數(shù)據(jù)庫的一致性。

由于舊的事務已提交，已不再需要其日志，因而日志將被截斷。截斷日志將刪除備份和還原事務日志。但是，這種簡化是有代價的，在災難事件中有丟失數(shù)據(jù)的可能。沒有日志備份，數(shù)據(jù)庫只可恢復到最近的數(shù)據(jù)備份時間。如果您使用的是 SQL Server Enterprise Edition，需要考慮此問題。此外，該模式不支持還原單個數(shù)據(jù)頁。

?

2、完整恢復模式

此模式完整地記錄了所有的事務，并保留所有的事務日志記錄，直到將它們備份。在 SQL Server Enterprise Edition 中，完整恢復模式能使數(shù)據(jù)庫恢復到故障時間點。

?

3、大容量日志恢復模式

此模式簡略地記錄大多數(shù)大容量操作(例如，索引創(chuàng)建)，完整地記錄其他事務。

大容量日志恢復提高大容量操作的性能，常用作完整恢復模式的補充。大容量日志恢復模式支持所有的恢復形式，但是有一些限制，備份包含大容量日志記錄操作的日志時，需要訪問數(shù)據(jù)庫內(nèi)的所有數(shù)據(jù)文件。如果數(shù)據(jù)文件不可訪問，則無法備份最后的事務日志，而且該日志中所有已提交的操作都將丟失。

?

五、SqlServer事務日志常用來解決的問題

?

1、服務器意外關(guān)閉造成的損失

數(shù)據(jù)庫服務器如果因為突然斷電或者其他一些原因意外當機時，再重新啟動服務器后會出現(xiàn)一些數(shù)據(jù)的損失。這主要是因為數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生更改后，并不會在第一時間就把數(shù)據(jù)寫入到硬盤中。為了提高數(shù)據(jù)庫的運行效率，往往是先把數(shù)據(jù)寫入到數(shù)據(jù)高速緩存中;同時把更改的情況寫入到事務日志中。等到一定的情況數(shù)據(jù)庫系統(tǒng)才會把數(shù)據(jù)寫入到硬盤文件中。

此時，如果數(shù)據(jù)庫服務器系統(tǒng)突然發(fā)生故障，數(shù)據(jù)庫系統(tǒng)就有可能還沒有把緩存中的修改后的數(shù)據(jù)寫入到硬盤中，即數(shù)據(jù)文件內(nèi)有未完成事務所做的修改。如果確實有這種情況，則當啟動SQL Server實例時，如果沒有事務日志或者事務日志損壞時，修改后的數(shù)據(jù)就無法恢復過來了。但是，如果當事務日志可用的話，則當實例啟動時，系統(tǒng)會丟每個數(shù)據(jù)庫執(zhí)行恢復操作。前滾日至中記錄的、可能尚未寫入數(shù)據(jù)文件的每個修改。在事務日志中找到的每個未完成的事務都將回滾，以確保數(shù)據(jù)庫數(shù)據(jù)的完整性。

所以當數(shù)據(jù)庫服務器意外故障時，數(shù)據(jù)庫管理員最好能夠確認一下事務日志是否可用。如果事務日志已經(jīng)損壞，那么就需要先恢復事務日志然后再重新啟動數(shù)據(jù)庫實例。否則的話，數(shù)據(jù)庫實例在重新啟動時不能夠正常恢復數(shù)據(jù)。這一點在遇到服務器突發(fā)行的故障時一定要注意。否則的話，很可能破壞數(shù)據(jù)庫數(shù)據(jù)的完整性。

?

2、解決備份數(shù)據(jù)庫的數(shù)據(jù)同步問題

?

有時候出于數(shù)據(jù)庫高可用性的目的，需要在生產(chǎn)服務器之外的地方再部署一臺數(shù)據(jù)庫服務器。當生產(chǎn)服務器出現(xiàn)故障不可用時，則可以馬上啟用這個備用的服務器。故就需要保證生產(chǎn)服務器與備用服務器之間數(shù)據(jù)的同步。那么SQL Server數(shù)據(jù)庫是通過什么技術(shù)來達到這個生產(chǎn)服務器與備份服務器之間的數(shù)據(jù)同步的呢?簡單的說，就是通過這個事務日志的復制來實現(xiàn)數(shù)據(jù)同步的。具體的來說，SQL Server數(shù)據(jù)庫提供了兩種解決方案，分別為數(shù)據(jù)鏡像與日志傳送。這兩個方案都是在事務日志復制的基礎(chǔ)上來實現(xiàn)的。

在日志傳送方案中，生產(chǎn)服務器將生產(chǎn)數(shù)據(jù)庫的活動事務日志發(fā)送到一個或多個目標服務器。每個輔助服務器將該日志還原為其本地的輔助數(shù)據(jù)庫，從而實現(xiàn)備用服務器與生產(chǎn)服務器之間數(shù)據(jù)的一致性。使用日志傳送，您可以自動將“主服務器”實例上“主數(shù)據(jù)庫”內(nèi)的事務日志備份發(fā)送到單獨“輔助服務器”實例上的一個或多個“輔助數(shù)據(jù)庫”。事務日志備份分別應用于每個輔助數(shù)據(jù)庫。可選的第三個服務器實例(稱為“監(jiān)shi服務器”)記錄備份和還原操作的歷史記錄及狀態(tài)，還可以在無法按計劃執(zhí)行這些操作時引發(fā)警報。日志傳送配置中的主服務器是作為生產(chǎn)服務器的 SQL Server 數(shù)據(jù)庫引擎實例。主數(shù)據(jù)庫是主服務器上希望備份到其他服務器的數(shù)據(jù)庫。通過數(shù)據(jù)庫進行的所有日志傳送配置管理都是在主數(shù)據(jù)庫中執(zhí)行的。另外需要注意的是，如果采用日志傳送方案對于生產(chǎn)服務器的工作模式有限制。生產(chǎn)數(shù)據(jù)庫必須使用完整恢復模式或大容量日志恢復模式。如果將數(shù)據(jù)庫切換為簡單恢復模式會導致日志傳送停止工作。

一臺備用服務器可以包含多臺不同生產(chǎn)服務器中數(shù)據(jù)庫的備份副本。例如，某個集團公司可能有三臺數(shù)據(jù)庫服務器，每臺服務器都運行關(guān)鍵數(shù)據(jù)庫系統(tǒng)。在這種情況下，可以只使用一臺輔助服務器，而不必使用三臺單獨的輔助服務器。三個主系統(tǒng)上的備份都可以加載到這個備份系統(tǒng)中，從而減少所需的資源數(shù)量并節(jié)省開支，也可以數(shù)據(jù)庫管理員的工作量。

另外也可以通過數(shù)據(jù)庫鏡像方案中來解決生產(chǎn)服務器與備用服務器之間的數(shù)據(jù)同步問題。生產(chǎn)數(shù)據(jù)庫的每次更新都在獨立的、完整的備份數(shù)據(jù)庫中立即重新生成。主體服務器實例立即將每個日志記錄發(fā)送到鏡像服務器實例，鏡像服務器實例將傳入的日志記錄應用于鏡像數(shù)據(jù)庫，從而將其繼續(xù)前滾。“數(shù)據(jù)庫鏡像”是用于提高數(shù)據(jù)庫可用性的首選軟件解決方案。鏡像基于每個數(shù)據(jù)庫實現(xiàn)，并且只適用于使用完整恢復模式的數(shù)據(jù)庫。簡單恢復模式和大容量日志恢復模式不支持數(shù)據(jù)庫鏡像。因此，所有大容量操作始終被完整地記入日志。數(shù)據(jù)庫鏡像可使用任意支持的數(shù)據(jù)庫兼容級別。在“數(shù)據(jù)庫鏡像模式”中，主體服務器和鏡像服務器作為伙伴進行通信和協(xié)作。兩個伙伴在會話中扮演互補的角色：主體角色(生產(chǎn)服務器)和鏡像角色(備份服務器)。在任何給定的時間，都是一個伙伴扮演生產(chǎn)服務器角色，另一個伙伴扮演備用服務器角色。如果生產(chǎn)服務器角色出現(xiàn)故障時，則備份服務器角色馬上會頂替出現(xiàn)故障的生產(chǎn)服務器角色，轉(zhuǎn)變?yōu)樯a(chǎn)服務器角色。從而實現(xiàn)數(shù)據(jù)庫的高可用性。

?

數(shù)據(jù)庫鏡像方案有兩種鏡像運行模式

一種是“高安全性模式”，它支持同步操作。在高安全性模式下，當會話開始時，鏡像服務器將使鏡像數(shù)據(jù)庫盡快與主體數(shù)據(jù)庫同步，一旦同步了數(shù)據(jù)庫，事務將在伙伴雙方處提交，這會延長事務滯后時間。

第二種運行模式，即高性能模式，它與第一種模式的主要差異就在于異步運行。鏡像服務器嘗試與主體服務器發(fā)送的日志記錄保持同步。鏡像數(shù)據(jù)庫可能稍微滯后于主體數(shù)據(jù)庫。但是，數(shù)據(jù)庫之間的時間間隔通常很小。但是，如果主體服務器的工作負荷過高或鏡像服務器系統(tǒng)的負荷過高，則時間間隔會增大。在高性能模式中，主體服務器向鏡像服務器發(fā)送日志記錄之后，會立即再向客戶端發(fā)送一條確認消息。它不會等待鏡像服務器的確認。這意味著事務不需要等待鏡像服務器將日志寫入磁盤便可提交。此異步操作允許主體服務器在事務滯后時間最小的條件下運行，但可能會丟失某些數(shù)據(jù)。具體采用哪種模式，則需要數(shù)據(jù)庫管理員根據(jù)企業(yè)對待數(shù)據(jù)損失的態(tài)度與工作負荷等來確定。

?

可見現(xiàn)在可用的備份服務器與生產(chǎn)服務器之間的數(shù)據(jù)同步解決方案都是基于事務日志來實現(xiàn)的。

?

3、解決數(shù)據(jù)一致性問題

假設現(xiàn)在有這么一種情況。在一個銀行系統(tǒng)中，某個用戶需要轉(zhuǎn)帳。這個轉(zhuǎn)帳作業(yè)主要是通過兩個步驟來完成。第一個步驟就是扣減用戶帳戶中的金額;第二個步驟是把錢轉(zhuǎn)入到另外一個用戶那里。現(xiàn)在如果在轉(zhuǎn)帳的過程中，第一步成功了，但是第二個步驟因為某種原因出錯了。如用戶提供的帳戶名字與實際轉(zhuǎn)帳的帳戶名字不符，則第二個操作就會失敗。此時整個轉(zhuǎn)帳操作就會以失敗而告終。但是現(xiàn)在的問題是，第一個扣減的動作在數(shù)據(jù)庫zhon給已經(jīng)完成了。而實際卻是沒有轉(zhuǎn)帳成功，就救造成了數(shù)據(jù)一致性的問題。

實際過程中如果應用程序發(fā)出 ROLLBACK 語句，或者數(shù)據(jù)庫引擎檢測到錯誤，就使用日志記錄回滾未完成的事務所做的修改。也就是說，當?shù)诙€操作失敗的話，應用程序要發(fā)出一個ROLLBACK 語句，利用事務日志回滾功能，恢復第一步的操作。也就是說，把扣減金額的操作進行恢復，從而實現(xiàn)數(shù)據(jù)的一致性。類似的應用，在數(shù)據(jù)庫開發(fā)過程中很頻繁。

?

4、數(shù)據(jù)庫時點恢復的問題

?

如現(xiàn)在遇到這么一種故障。數(shù)據(jù)庫系統(tǒng)在上午11點突然發(fā)現(xiàn)故障，啟動不起來了。而數(shù)據(jù)庫系統(tǒng)是在昨天晚上12點剛做完一個完全備份。在這種情況下，如果只是從完全備份中恢復數(shù)據(jù)的話，只能夠恢復到昨天晚上12點的數(shù)據(jù)。那從昨天晚上12點到今天上午11點的數(shù)據(jù)就不能夠恢復了嗎?

其實不然。因為用戶在對數(shù)據(jù)庫做的任何一個修改都會保存在事務日志當中。為此只要事務日志不損壞的情況下，數(shù)據(jù)庫管理員可以把數(shù)據(jù)恢復到上午11點那個時刻的數(shù)據(jù)。具體的操作方法很簡單，就好先利用完全備份文件恢復數(shù)據(jù)庫系統(tǒng)，此時數(shù)據(jù)庫中的數(shù)據(jù)位昨天晚上12點的數(shù)據(jù)。然后再利用日志恢復功能把數(shù)據(jù)恢復到今天上午11點的數(shù)據(jù)。可見事務日志可以幫助管理員把數(shù)據(jù)恢復到某一個具體的時點。

總結(jié)

以上是生活随笔為你收集整理的Sql Server事务日志的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。