通過事務日志解決SQL Server常見四大故障(二)_Mssql數據庫教程

推薦：談SQL Data Services將成為云中完整的數據庫
各大云計算提供商(亞馬遜、谷歌和微軟)目前都使用了鍵/值存儲方式。然而，在San Francisco召開的MSDN開發者大會上，微軟宣布他們在獲取ISV的反饋之后，決定通過SQL Data Service(SDS)提供SQL Server的RDBMS功能。 Register UK的Gavin Clarke采訪了Mark Hinds

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

可見現在可用的備份服務器與生產服務器之間的數據同步解決方案都是基于事務日志來實現的。

故障三：解決數據一致性問題。

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

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

故障四：數據庫時點恢復的問題。

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

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

分享：讓SQL Server數據庫自動執行管理任務(二)
二是什么時候CPU是空閑的?空閑是一個相對的標準。有時會CPU使用率30%以下可以定義為空閑;而有時候CPU使用率只有不到60%，就是空閑。這要根據服務器的配置已經所部屬的應用來考慮。所以管理員在采用CPU空閑計劃之前，先要對服務器進行觀測一定時間，采用性能