通過事務日誌解決SQL Server常見四大故障

當系統出現故障時，只要存在資料日誌那麼就可以利用它來恢復資料解決資料庫故障。作為SQL Server資料庫管理員，瞭解資料日誌檔案的作用，以及如何利用它來解決一些資料庫的常見故障，這非常重要。既然事務日誌這麼重要，那麼他到底可以用來做什麼事情呢?口說無憑，筆者這裡就跟大家說說事務日誌到底可以用來解決什麼故障。

故障一：伺服器意外關閉造成的損失

俗話說，天又不測風雲。資料庫伺服器如果因為突然斷電或者其他一些原因意外當機時，再重新啟動伺服器後會出現一些資料的損失。這主要是因為資料庫中的資料發生更改後，並不會在第一時間就把資料寫入到硬碟中。為了提高資料庫的執行效率，往往是先把資料寫入到資料快取記憶體中;同時把更改的情況寫入到事務日誌中。等到一定的情況資料庫系統才會把資料寫入到硬碟檔案中。

此時，如果資料庫伺服器系統突然發生故障，資料庫系統就有可能還沒有把快取中的修改後的資料寫入到硬碟中，即資料檔案內有未完成事務所做的修改。如果確實有這種情況，則當啟動SQL Server例項時，如果沒有事務日誌或者事務日誌損壞時，修改後的資料就無法恢復過來了。但是，如果當事務日誌可用的話，則當例項啟動時，系統會丟每個資料庫執行恢復操作。前滾日至中記錄的、可能尚未寫入資料檔案的每個修改。在事務日誌中找到的每個未完成的事務都將回滾，以確保資料庫資料的完整性。

所以當資料庫伺服器意外故障時，資料庫管理員最好能夠確認一下事務日誌是否可用。如果事務日誌已經損壞，那麼就需要先恢復事務日誌然後再重新啟動資料庫例項。否則的話，資料庫例項在重新啟動時不能夠正常恢復資料。這一點在遇到伺服器突發行的故障時一定要注意。否則的話，很可能破壞資料庫資料的完整性。

故障二：解決備份資料庫的資料同步問題

有時候出於資料庫高可用性的目的，需要在生產伺服器之外的地方再部署一臺資料庫伺服器。當生產伺服器出現故障不可用時，則可以馬上啟用這個備用的伺服器。故就需要保證生產伺服器與備用伺服器之間資料的同步。那麼SQL Server資料庫是通過什麼技術來達到這個生產伺服器與備份伺服器之間的資料同步的呢?簡單的說，就是通過這個事務日誌的複製來實現資料同步的。具體的來說，SQL Server資料庫提供了兩種解決方案，分別為資料映象與日誌傳送。這兩個方案都是在事務日誌複製的基礎上來實現的。

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

一臺備用伺服器可以包含多臺不同生產伺服器中資料庫的備份副本。例如，某個集團公司可能有三臺資料庫伺服器，每臺伺服器都執行關鍵資料庫系統。在這種情況下，可以只使用一臺輔助伺服器，而不必使用三臺單獨的輔助伺服器。三個主系統上的備份都可以載入到這個備份系統中，從而減少所需的資源數量並節省開支，也可以資料庫管理員的工作量。

另外也可以通過資料庫映象方案中來解決生產伺服器與備用伺服器之間的資料同步問題。生產資料庫的每次更新都在獨立的、完整的備份資料庫中立即重新生成。主體伺服器例項立即將每個日誌記錄傳送到映象伺服器例項，映象伺服器例項將傳入的日誌記錄應用於映象資料庫，從而將其繼續前滾。“資料庫映象”是用於提高資料庫可用性的首選軟體解決方案。映象基於每個資料庫實現，並且只適用於使用完整恢復模式的資料庫。簡單恢復模式和大容量日誌恢復模式不支援資料庫映象。因此，所有大容量操作始終被完整地記入日誌。資料庫映象可使用任意支援的資料庫相容級別。在“資料庫映象模式”中，主體伺服器和映象伺服器作為夥伴進行通訊和協作。兩個夥伴在會話中扮演互補的角色：主體角色(生產伺服器)和映象角色(備份伺服器)。在任何給定的時間，都是一個夥伴扮演生產伺服器角色，另一個夥伴扮演備用伺服器角色。如果生產伺服器角色出現故障時，則備份伺服器角色馬上會頂替出現故障的生產伺服器角色，轉變為生產伺服器角色。從而實現資料庫的高可用性。

資料庫映象方案有兩種映象執行模式。一種是“高安全性模式”，它支援同步操作。在高安全性模式下，當會話開始時，映象伺服器將使映象資料庫儘快與主體資料庫同步，一旦同步了資料庫，事務將在夥伴雙方處提交，這會延長事務滯後時間。第二種執行模式，即高效能模式，它與第一種模式的主要差異就在於非同步執行。映象伺服器嘗試與主體伺服器傳送的日誌記錄保持同步。映象資料庫可能稍微滯後於主體資料庫。但是，資料庫之間的時間間隔通常很小。但是，如果主體伺服器的工作負荷過高或映象伺服器系統的負荷過高，則時間間隔會增大。在高效能模式中，主體伺服器向映象伺服器傳送日誌記錄之後，會立即再向客戶端傳送一條確認訊息。它不會等待映象伺服器的確認。這意味著事務不需要等待映象伺服器將日誌寫入磁碟便可提交。此非同步操作允許主體伺服器在事務滯後時間最小的條件下執行，但可能會丟失某些資料。具體採用哪種模式，則需要資料庫管理員根據企業對待資料損失的態度與工作負荷等來確定。

可見現在可用的備份伺服器與生產伺服器之間的資料同步解決方案都是基於事務日誌來實現的。

故障三：解決資料一致性問題

假設現在有這麼一種情況。在一個銀行系統中，某個使用者需要轉帳。這個轉帳作業主要是通過兩個步驟來完成。第一個步驟就是扣減使用者帳戶中的金額;第二個步驟是把錢轉入到另外一個使用者那裡。現在如果在轉帳的過程中，第一步成功了，但是第二個步驟因為某種原因出錯了。如使用者提供的帳戶名字與實際轉帳的帳戶名字不符，則第二個操作就會失敗。此時整個轉帳操作就會以失敗而告終。但是現在的問題是，第一個扣減的動作在資料庫zhon給已經完成了。而實際卻是沒有轉帳成功，就救造成了資料一致性的問題。

實際過程中如果應用程式發出 ROLLBACK 語句，或者資料庫引擎檢測到錯誤，就使用日誌記錄回滾未完成的事務所做的修改。也就是說，當第二個操作失敗的話，應用程式要發出一個ROLLBACK 語句，利用事務日誌回滾功能，恢復第一步的操作。也就是說，把扣減金額的操作進行恢復，從而實現資料的一致性。類似的應用，在資料庫開發過程中很頻繁。

故障四：資料庫時點恢復的問題

如現在遇到這麼一種故障。資料庫系統在上午11點突然發現故障，啟動不起來了。而資料庫系統是在昨天晚上12點剛做完一個完全備份。在這種情況下，如果只是從完全備份中恢復資料的話，只能夠恢復到昨天晚上12點的資料。那從昨天晚上12點到今天上午11點的資料就不能夠恢復了嗎?
其實不然。因為使用者在對資料庫做的任何一個修改都會儲存在事務日誌當中。為此只要事務日誌不損壞的情況下，資料庫管理員可以把資料恢復到上午11點那個時刻的資料。具體的操作方法很簡單，就好先利用完全備份檔案恢復資料庫系統，此時資料庫中的資料位昨天晚上12點的資料。然後再利用日誌恢復功能把資料恢復到今天上午11點的資料。可見事務日誌可以幫助管理員把資料恢復到某一個具體的時點。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-582425/，如需轉載，請註明出處，否則將追究法律責任。