通過交易記錄解決SQL Server常見四大故障（二）

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

　　可見現在可用的備份伺服器與生產伺服器之間的資料同步解決方案都是基於交易記錄來實現的。

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

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

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

　　故障四：資料庫時間點復原的問題。

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

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