通過事務日志解決SQL Server常見四大故障（二）

　　資料庫鏡像方案有兩種鏡像運作模式。一種是“高安全性模式”，它支援同步操作。在高安全性模式下，當會話開始時，鏡像伺服器将使鏡像資料庫盡快與主體資料庫同步，一旦同步了資料庫，事務将在夥伴雙方處送出，這會延長事務滞後時間。第二種運作模式，即高性能模式，它與第一種模式的主要差異就在于異步運作。鏡像伺服器嘗試與主體伺服器發送的日志記錄保持同步。鏡像資料庫可能稍微滞後于主體資料庫。但是，資料庫之間的時間間隔通常很小。但是，如果主體伺服器的工作負荷過高或鏡像伺服器系統的負荷過高，則時間間隔會增大。在高性能模式中，主體伺服器向鏡像伺服器發送日志記錄之後，會立即再向用戶端發送一條确認消息。它不會等待鏡像伺服器的确認。這意味着事務不需要等待鏡像伺服器将日志寫入磁盤便可送出。此異步操作允許主體伺服器在事務滞後時間最小的條件下運作，但可能會丢失某些資料。具體采用哪種模式，則需要資料庫管理者根據企業對待資料損失的态度與工作負荷等來确定。

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

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

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

語句，或者資料庫引擎檢測到錯誤，就使用日志記錄復原未完成的事務所做的修改。也就是說，當第二個操作失敗的話，應用程式要發出一個ROLLBACK

語句，利用事務日志復原功能，恢複第一步的操作。也就是說，把扣減金額的操作進行恢複，進而實作資料的一緻性。類似的應用，在資料庫開發過程中很頻繁。

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

　　如現在遇到這麼一種故障。資料庫系統在上午11點突然發現故障，啟動不起來了。而資料庫系統是在昨天晚上12點剛做完一個完全備份。在這種情況下，如果隻是從完全備份中恢複資料的話，隻能夠恢複到昨天晚上12點的資料。那從昨天晚上12點到今天上午11點的資料就不能夠恢複了嗎?

　　其實不然。因為使用者在對資料庫做的任何一個修改都會儲存在事務日志當中。為此隻要事務日志不損壞的情況下，資料庫管理者可以把資料恢複到上午11點那個時刻的資料。具體的操作方法很簡單，就好先利用完全備份檔案恢複資料庫系統，此時資料庫中的資料位昨天晚上12點的資料。然後再利用日志恢複功能把資料恢複到今天上午11點的資料。可見事務日志可以幫助管理者把資料恢複到某一個具體的時點。