SQL Server 2005 數據庫鏡像詳解，快速遷移恢復熱備系統
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
概述 數據庫鏡像是SQL SERVER 2005 用于提高數據庫可用性的新技術。數據庫鏡像將事務日志記錄直接從一臺服務器傳輸到另一臺服務器，并且能夠在出現故障時快速轉移到備用服務器。可以編寫客戶端程序自動重定向連接信息，這樣一旦出現故障轉移就可以自動連接到備用服務器和數據庫。 自動進行故障轉移并且使數據損失最小化通常包括昂貴的硬件和復雜的軟件。但是，數據庫鏡像可以在不丟失已提交數據的前提下進行快速故障轉移，無須專門的硬件，并且易于配置和管理。 數據庫鏡像介紹 在數據庫鏡像中，一臺SQL Server 2005實例連續不斷的將數據庫事務日志發送到另一臺備用SQL Server實例的數據庫副本中。發送方的數據庫和服務器擔當主角色，而接收方的數據庫和服務器擔當鏡像角色。主服務器和鏡像服務器必須是獨立的SQL Server 2005實例。 在所有SQL Server數據庫中，在對真正的數據頁面進行修改之前，數據改變首先都記錄在事務日志中。事務日志記錄先被放置在內存中的數據庫日志緩沖區中，然后盡快地輸出到磁盤（或者被硬化）。在數據庫鏡像中，當主服務器將主數據庫的日志緩沖區寫入磁盤時，也同時將這些日志記錄塊發送到鏡像實例。 當鏡像服務器接收到日志記錄塊后，首先將日志記錄放入鏡像數據庫的日志緩沖區，然后盡快地將它們硬化到磁盤。稍后鏡像服務器會重新執行那些日志記錄。由于鏡像數據庫重新應用了主數據庫的事務日志記錄，因此復制了發生在主數據庫上的數據改變。 主服務器和鏡像服務器將對方視為數據庫鏡像會話中的伙伴。數據庫鏡像會話包含了鏡像伙伴服務器之間的關系。一臺給定的伙伴服務器可以同時承擔某個數據庫的主角色和另一個數據庫的鏡像角色。 除了兩臺伙伴服務器（主服務器和鏡像服務器），一個數據庫會話中可能還包含第三臺可選服務器，叫做見證服務器。見證服務器的角色就是啟動自動故障轉移。當數據庫鏡像用于高可用性時，如果主服務器突然失敗了，如果鏡像服務器通過見證服務器確認了主服務器的失敗，那么它就自動承擔主服務器角色，并且在幾秒鐘之內就可以向用戶提供數據庫服務。 數據庫鏡像中需要注意的一些重要事項： ◆主數據庫必須為FULL還原模型。由于bulk-logged操作而導致的日志記錄無法發送到鏡像數據庫。 注意：要想獲取更多與數據庫鏡像術語有關的信息，請參閱SQL Server 2005 Books Online中關于“Overview of Database Mirroring”。 操作模式 數據庫鏡像會話有三種可能的操作模式。根據事務安全性的設置以及鏡像會話中是否需要見證服務器來決定精確的操作模式。 表1：數據庫鏡像操作模式
如果safety設置為FULL，那么通過同步方式傳輸數據，并且需要一臺鏡像服務器才能提供數據庫服務。quorum投票表決要求至少兩臺服務器的參與才能夠決定兩個伙伴服務器各自承擔什么角色，主角色還是鏡像角色。 為了更深入研究這三種操作模式，首先來更進一步研究一下事務安全性和quorum的角色。 事務安全性 If 事務安全性（或者'safety'）設置為FULL，那么主服務器和鏡像服務器工作在同步傳輸模式下。當主服務器硬化其主數據庫日志記錄到磁盤時，也同時將日志發送到鏡像服務器。然后主服務器等待鏡像服務器的回答。鏡像服務器將那些相同的日志記錄硬化到鏡像日志所在磁盤后，對主服務器進行答復。當safety設置為OFF時，主服務器不會等待來自服務器的確認，因此主數據庫和鏡像數據庫可能不是完全同步的（也就是，鏡像可能滯后于主數據庫）。 同步傳輸方式保證鏡像數據庫事務日志中所有事務與主數據庫事務日志中的事務同步，因此可視為事務是安全傳輸的。要將safety設置為FULL，使用
當safety設置為OFF，主服務器和鏡像服務器之間的通信是異步的。主服務器不會等待鏡像服務器已將事務記錄硬化的確認信息。鏡像服務器通過盡快記錄事務日志的來試圖保持與主服務器同步，但是如果主服務器突然失敗同時強制鏡像服務器提供服務，那么某些事務還是有可能丟失（參閱SQL Server Books中的'Forced Service'）。 Quorum和見證服務器 當safety設置為FULL，數據庫鏡像需要quorum才能提供數據庫服務。quorum是在同步數據庫鏡像會話中要求的所有連接起來的服務器之間的最小關系。由于一個quorum至少需要兩臺服務器，因此當safety為FULL時，主服務器必須和其他某至少一臺服務器組成quorum才能夠提供數據庫服務。 見證服務器幫助主服務器或者鏡像服務器組成quorum。如果存在見證服務器，那么主數據庫或者鏡像數據庫失敗時，其余兩臺服務器還可以組成quorum。如果主服務器無法看到鏡像服務器，那么它可以和見證服務器組成quorum，并保持提供數據庫服務。類似地，如果鏡像服務器和見證服務器看不到主服務器，那么這兩臺服務器可以組成quorum，鏡像服務器擔當新主服務器的角色。 見證服務器失敗不被視為數據庫鏡像繪畫中的單點失敗。因為如果見證服務器失敗了，那么主服務器和鏡像服務器還可以組成quorum（更多信息請參閱SQL Server Books Online中的“Quorum in Database Mirroring Sessions”主題）。 高可用操作模式 高可用操作模式支持最大程度的數據庫可用性，如果主數據庫失敗將自動轉移到經銷數據庫。它要求將safety設置為FULL并且定義一臺見證服務器作為數據庫鏡像會話中的一員。 高可用操作模式最適合于那些服務器之間具有高速且可靠的通信線路，同時要求在單一數據庫上實現自動故障轉移的場景。當safety為FULL時，主服務器必須短暫等待來自鏡像服務器的回答，主服務器性能也因此受到鏡像服務器能力的影響。由于單數據庫失敗將導致自動故障轉移，因此如果有多數據庫應用程序，那么就應該考慮其他操作模式（參閱該白皮書中實現數據庫鏡像部分介紹的“多數據庫問題”） 高可用模式中數據庫鏡像是自監視的。如果主數據庫突然不可用，或者主服務器停機，那么見證服務器和鏡像服務器將組成quorum，然后鏡像的SQL Server將進行自動故障轉移。此時，競相服務器實例將其角色轉換為新主服務器并恢復數據庫。由于鏡像數據庫已經重新執行了主數據庫的事務日志并且其事務日志也與主數據庫同步，因此鏡像服務器可以快速提供數據庫服務。 此外，SQL Server 2005可以在數據庫恢復前就向用戶提供數據庫服務。SQL Server數據庫恢復包括三個階段：分析階段、redo階段、以及最后的undo階段。在SQL Server 2005中，只要redo階段完成，新恢復的數據庫就可以讓用戶訪問。因此如果數據庫鏡像故障轉移發生，新恢復的主數據庫只要完成了redo階段就可以向用戶提供服務了。因為鏡像數據庫自始至終都在重新執行事務日志記錄，因此所有鏡像服務器只須完成redo過程就可以了，通常幾秒鐘就可以完成。 高保護操作模式 高保護操作模式中事務安全性設置為FULL，但是鏡像會話中沒有見證服務器。主服務器必須組成quorum，可是沒有見證服務器，因此只能和鏡像服務器配合在一起。這種模式下由于沒有見證服務器來擔當平局決勝的角色，因此只能手動完成故障轉移。行自動故障轉移是不可能的，因為如果主服務器失敗，鏡像服務器沒有見證服務器來組成quorum。 safety設置為FULL，如果主服務器突然間失去了和鏡像服務器的quorum，那么鏡像服務器必須使其數據庫停止服務。不推薦使用高保護模式的數據庫鏡像配置，除非在高可用模式下必須臨時移除見證服務器時，可以使用該模式作為一種臨時過渡。 高性能操作模式 在高性能操作模式下，事務安全性設置為OFF，以異步方式傳輸日志記錄。主服務器無須等待鏡像服務器所有日志記錄已被硬化的確認信息。鏡像服務器盡自己最大可能保持與主服務器數據的一致，但不能保證在任何時刻來自主數據庫的所有最新事務日志記錄都能夠被硬化到鏡像數據庫的事務日志中。 在高性能模式下，見證服務器不承擔任何角色，也不需要quorum。因此高性能模式無法啟用自動和手動的故障轉移。唯一允許的故障轉移方式就是forced service ，它同樣也是一種手工操作：
forced service故障轉移導致立刻恢復鏡像數據庫。如果某些主數據庫的事務日志記錄還沒有被鏡像服務器接收，那么恢復鏡像數據庫將導致潛在的數據丟失。高性能模式特別適合于遠距離的數據傳輸（換句話說，用于遠程站點的災難恢復），或者對那些活動頻繁且可以容忍某種程度數據丟失的數據庫進行鏡像。 數據庫快照和數據庫鏡像 由于鏡像數據庫處于recovering狀態，因此不可訪問也不可讀。在SQL Server 2005企業版和開發人員版中可以創建數據庫快照來讀取某個時點的鏡像數據庫。數據庫快照提供了一個只讀的數據庫視圖，開放數據給用戶訪問。這些數據與創建快照時刻的數據庫數據相一致。 對數據庫快照的訪問如同訪問一個其他的數據庫。查詢數據庫快照時，從數據庫快照文件中讀出那些自快照創建后被修改的數據，從原始數據庫中讀出未修改的數據。最終效果就是讀取了在創建快照時刻數據庫當時的數據。（更多信息請參閱SQL Server Books Online中"Using Database Snapshots with Database Mirroring"主題。） 由于數據庫快照確實增加了鏡像服務器的負擔，因此需要當心它們對數據庫鏡像性能可能造成的影響。由于只能鏡像到一個數據庫，因此如果需要將數據擴充到多個只讀的報表服務器上，那么事務復制是更好的選擇。（更新信息請閱讀后面實現數據庫鏡像部分的“數據庫鏡像和復制”） 客戶端重定向 在SQL Server 2005中，如果使用ADO.NET或者SQL Native Client連接配置了鏡像的數據庫，那么應用程序就可以利用驅動程序的能力在發生數據庫鏡像故障轉移時自動重定向數據庫連接。必須在連接字符串中指定原始主服務器和數據庫名稱，以及可選的故障轉移伙伴服務器名稱。 連接字符串的寫法有許多種，以下只給出一個例子，指定server A作為主服務器，server B作為鏡像服務器，AdventureWorks作為數據庫名稱：
如果連接到原始主服務器失敗，那么就使用連接字符串中的failover partner作為備用服務器名稱。如果連接到原始主服務器成功，那么就不使用連接字符串中的failover partner名稱，但是會從主服務器上查詢其故障轉移伙伴的名稱并將結果存放在客戶端緩存中。 假設客戶端成功連接到主服務器，然后一個數據庫鏡像故障轉移發生（自動地、手動的、forced）。當下一次應用程序嘗試使用連接時，ADO.NET或者SQL Native Client驅動程序將會檢測到與舊主服務器的連接已經失敗，然后自動重新連接由failover partner名稱指定的新主服務器。如果連接成功并且新的鏡像服務器存在，那么驅動程序從新主服務器處獲取新的故障轉移伙伴名稱并將其存放在客戶端緩存中。如果無法連接到備用服務器，那么驅動程序將交替嘗試與每個服務器的連接直道連接超時。 使用內置在ADO.NET和SQL Native Client驅動程序中的數據庫鏡像支持的最大優點就是無須重新編寫應用程序，或者在應用程序中編寫特殊代碼來處理數據庫鏡像的故障轉移。 如果不使用ADO.NET或者SQL Native Client自動進行重定向，那么也可以使用其他技術使應用程序進行故障轉移。例如，如果客戶端連接到一臺虛擬服務器，可以使用Network Load Balancing手動重定向一臺服務器到另一臺服務器的連接。還可以編程實現自己的重定向代碼和連接重試邏輯。 但是，所有這些用于協調客戶端重定向和數據庫鏡像的技術都有一些重要限制。數據庫鏡像只能工作在數據庫級別，而不是服務器級別。如果應用程序查詢一臺服務器上的多個數據庫，或者使用完全限定對象名稱進行跨數據庫查詢，那么就需要多加小心了。如果多個數據庫位于一臺服務器并且都配置了和備用服務器的鏡像，就有可能出現其中一個數據庫故障轉移到備用服務器而其他數據庫依然在原始服務器的情況。如果是那樣的話，可能就要求每個數據庫查詢都使用一個單獨的連接，這樣將無法進行跨數據庫查詢，因為在鏡像服務器上只有一個數據庫是主數據庫，其余都是鏡像數據庫。 數據庫鏡像與SQL SERVER 2005版本 下表顯示各種版本的SQL SERVER 2005支持的數據庫鏡像功能。 表2：數據庫鏡像和SQL SERVER 2005版本
少數幾個數據庫鏡像功能要求使用SQL SERVER 2005企業版或者開發人員版： ◆高性能模式下safety設置為OFF （異步數據傳輸）； SQL Express和工作組版本可以作為數據庫鏡像的見證服務器，但不能作為伙伴服務器。 數據庫鏡像動態 要深入理解SQL SERVER 2005 數據庫鏡像，了解數據庫鏡像會話如何變化將對您大有幫助。這一部分內容包括數據庫鏡像會話中不同的數據庫狀態、同步和異步的日志記錄傳輸機制、以及故障轉移次序。 配置和安全性 一旦確定了主服務器、鏡像服務器、以及可選的見證服務器，設置數據庫鏡像主要包括三個步驟。 1.必須備份數據庫并使用norecovery在鏡像數據庫上還原該數據庫。 注意：在備份數據庫并還原到鏡像數據庫之前，主數據庫必須設置為FULL還原模型。如果必須在事務日志中傳輸Bulk-logged記錄，那么數據庫鏡像將無能為力。鏡像服務器必須有足夠的磁盤空間以允許和主數據庫同樣的文件增長。如果希望在鏡像服務器中創建數據庫快照，那么還必須為快照提供額外的磁盤空間。 如果備份、拷貝、以及還原數據庫耗費了相當長的時間，那么可能需要現在原始數據庫上進行一次事務日志備份來控制日志的大小。但是，如果通過日志到日志的備份清理了日志記錄，數據庫鏡像將無法初始化。因此必須在初始化數據庫鏡像之前在鏡像數據庫上按順序恢復那些事務日志記錄備份。 2.參與數據庫鏡像會話的服務器必須彼此信任。對于本地通信而言，例如一個域內的通信，信任意味著SQL Server實例登陸賬號必須有權限連接到其他鏡像服務器，也包括endpoints。首先在每個服務器上使用CREATE LOGIN命令，然后使用GRANT CONNECT ON ENDPOINT命令（參閱" in SQL Server Books Online中“Example of Setting Up Database Mirroring Using Windows Authentication”） 非信任域之間的通信必須使用證書。如果使用CREATE CERTIFICATE語句創建自簽名的證書，基本上所有數據鏡像證書的要求都可以滿足。確認在CREATE CERTIFICATE語句中將證書標記為ACTIVE FOR BEGIN_DIALOG。 3.下一步是創建數據庫鏡像的endpoints。創建endpoints要求您必須具有SQL Server instance的系統管理員權限。必須在每臺服務器上創建專門用于數據庫鏡像的endpoints. 創建endpoints最簡單的方式就是使用Configure Database Mirroring Security向導，可以在Database Properties對話框中Mirroring頁面上單擊Configure Security按鈕啟動該向導。Configure Security對話框會在構造和執行CREATE ENDPOINT命令之前，提示您輸入正確的計算機名稱和端口號，以及可選的登陸帳號。（參閱SQL Server Books Online中 “How to: Create a Mirroring Endpoint (Transact-SQL)”） 如果在域中設置數據庫鏡像，并且所有的SQL Server實例使用相同的服務帳號和密碼，那么就不需要在每個服務器上創建登陸帳號。類似的，如果在工作組中，并且所有的SQL Server實例使用相同的服務帳號和密碼，也不需要在每個服務器上創建登陸帳號。設置endpoints時將Configure Database Mirroring Security向導中的登陸帳號保留為空就可以了。 每個數據庫endpoint必須指定服務器上一個唯一的端口號。如果使用不同服務器上的SQL Server實例，那么這些端口號可以是相同的。Configure Database Mirroring Security向導會自動建議您使用5022作為端口號。如果任何SQL Server實例運行在同一臺服務器上，那么每個實例的端口號必須唯一，所有的鏡像端口號也必須唯一。 假設在高可用鏡像會話中有三臺服務器。Server A是主服務器，server B是鏡像服務器，server W作為見證服務器。對于server A而言，下面的命令在5022端口創建endpoint：
注意：角色被指定為PARTNER，這樣該服務器可以擔當數據庫鏡像的主服務器或者鏡像服務器。在server B上執行相同的命令。因為server B是獨立物理服務器上的SQL Server實例，因此可以使用相同的端口號。然后對于server W，使用
注意：對于server W，角色被指定為WITNESS。 默認不啟動endpoint。接下來在每個服務器上使用下面的命令來啟動endpoint：
可以在CREATE ENDPOINT命令中插入可選的STATE選項。在每臺服務器上反復執行該選項。 使用CREATE ENDPOINT創建endpoint時，可以通過協議特定的參數根據IP地址來限制對endpoint的訪問。結合RESTRICT_IP with ALL選項和EXCEPT_IP加上那些允許訪問的特殊IP地址可以對一組IP地址作限制。（參閱SQL Server Books Online中的See “CREATE ENDPOINT”）。 查詢每個服務器的sys.database_mirroring_endpoints目錄視圖來檢查數據庫鏡像的endpoints：
4. 要啟動數據庫鏡像，接下來指定指定伙伴服務器和見證服務器。必須具有數據庫管理員權限才可以啟動和管理一個給定的數據庫鏡像會話。在server A，即打算作主服務器的機器上設置主數據庫角色以及伙伴（鏡像）服務器：
鏡像伙伴的名稱必須為完全限定計算機名。決定機器的完全限定名稱可能有些難，不過Configure Database Mirroring Security向導會在建立endpoint時自動找出它們。 從命令行提示中運行下面的命令也可以找出一臺機器的完全限定名稱： IPCONFIG /ALL 將"Host Name"和"Primary DNS Suffix"連接到一起。如果您看到的信息類似于： Host Name . . . . . . . . . . . . : A 那么計算機名就是A.corp.mycompany.com。加上'TCP://'前綴然后再附加':<端口號>' ，就是鏡像伙伴名稱。 在鏡像服務器上重復相同的命令，但是要指定主服務器名稱：
接下來在主服務器上指定見證服務器：
執行完CREATE ENDPOINT后見證服務器上就不需要執行其他命令了。 最后，在主服務器上指定會話的safety級別：
此時，鏡像將自動啟動，然后主服務器和鏡像服務器將進行同步。 可以調整判定鏡像伙伴是否故障的超時值，使用ALTER DATABASE命令的TIMEOUT參數。例如將TIMEOUT值改為20秒（默認是10），在主服務器上執行：
最后，在主服務器上使用ALTER DATABASE和REDO_QUEUE選項可以鏡像服務器上redo隊列的大小。下面的查詢將鏡像服務器的redo隊列設置為100兆：
只要指定了鏡像伙伴，鏡像將立即啟動。 數據庫鏡像目錄視圖 數據庫鏡像會話包括組成伙伴的服務器，可能還有見證服務器之間的關聯。每臺參與鏡像的服務器都保存關于鏡像會話和當前數據庫狀態的元數據。可以在主服務器和鏡像服務器上通過查詢sys.database_mirroring目錄視圖來檢查會話狀態。使用另一個視圖sys.database_mirroring_witnesses可是返回見證服務器的信息（要想獲得兩個目錄視圖中所有列的更完整的描述，請參閱 SQL Server Books Online的“sys.database_mirroring" and "sys.database_mirrroing_witnesses”）。 了解數據庫鏡像會話如何工作以及數據庫處于何種狀態的一種不錯的方法就是檢查目錄視圖里的數據。我們從高可用配置開始（safety設置為FULL，有一臺見證服務器）。下面的查詢返回了主服務器或者見證服務器上數據庫鏡像會話的基本描述信息。
在見證服務器上運行下面類似的查詢，可以返回見證服務器的相關描述信息。
現在來比較在一個典型的數據庫鏡像會話中兩個查詢的輸出結果。假設已經設置了server A到 server B的數據庫鏡像，使用safety為FULL。（設置以下配置的示例代碼，請參閱后面的實現數據庫鏡像“配置和安全性”）見證服務器是server W，對AdventureWorks數據庫做鏡像。表3顯示了兩個查詢的輸出結果： 表3：高可用鏡像會話，兩個伙伴服務器sys.database_mirroring輸出結果
注意數據庫鏡像會話中的每個伙伴保存的所有元數據從另一個伙伴的角度來看是完全相同的。每個伙伴保存其數據庫名稱、整個會話的safety設置、數據庫的鏡像狀態、以及兩個序列計數器。 ◆mirroring_safety_sequence計數器保存在兩個伙伴上，只要safety設置改變時將增加該計數器的值。 伙伴數據庫的狀態以及見證服務器的狀態都保存在每個伙伴服務器上： ◆mirroring_state_desc顯示了會話中伙伴數據庫的狀態。 最后，每個伙伴都包含一個mirroring_failover_lsn。LSN是一個日志序列號，用于唯一標識每條事務日志記錄。鏡像伙伴將上次硬化的最后一組日志記錄的最高LSN +1保存起來。在上表中，由于主數據庫中只有為數不多的活動，因此 鏡像轉移故障的lsn和主服務器以及見證服務器的lsn相同。當傳輸大量數據時，可能就會發現主服務器的lsn值大于鏡像服務器的值，因為鏡像服務器的運行有些滯后。 現在比較一下在見證服務器上找到的元數據。下表顯示了來自見證服務器元數據的一些可比較信息： 表4：見證服務器上sys.database_mirroring_witnesses的輸出，關聯了伙伴的元數據
注意見證服務器的元數據包含了safety的描述、safety的序列號、以及角色序列號。見證服務器還保存了會話是否被掛起的信息，以及主服務器和鏡像服務器的名稱。注意見證服務器的目錄視圖并沒有報告鏡像故障轉移的lsn，而且也不保存數據庫狀態。 數據庫鏡像所需的全部元數據（特別是故障轉移lsn和伙伴服務器名稱）都保存在鏡像伙伴上。見證服務器只保存在高可用模式下作為見證者必須保存的那些數據，特別是用于跟蹤會話中角色轉換數目的角色序列號。該計數器用于幫助判定何時一臺主服務器可以做角色轉換。相關知識會在下一部分介紹的場景中進行闡述。 數據庫鏡像狀態和狀態轉換 在數據庫鏡像會話過程中，每臺伙伴服務器都對數據庫狀態作記錄和保存，可以通過sys.database_mirroring目錄視圖來查看。mirroring_state列返回狀態號，mirroring_state_desc列返回狀態的描述性名稱。（要想獲取關于數據庫狀態號和描述性名稱的完整列表，請看SQL Server Books Online中的“sys.database_mirroring”）。同樣的目錄視圖還用于報告見證服務器的狀態信息。 除了為每個數據庫報告狀態信息以外，還有三個重要術語用來對數據庫鏡像中的服務器和數據庫進行描述。 1.主服務器上的數據是exposed ，當它進行事務處理但是沒有日志數據被發送到鏡像服務器。 當主數據庫是exposed，它可以接收用戶連接和進行事務處理，但是沒有日志記錄被發送到鏡像數據庫。因此如果主數據庫失敗了，那么鏡像數據庫不包含任何自主數據庫進入exposed狀態后主服務器上發生的事務。同樣的，也不可以清理主數據庫的事務日志，這導致日志文件的無限增長。 當safety設置為FULL時，如果主服務器無法和其他服務器組成quorum，它將停止提供數據庫服務。主服務器將不允許主數據庫上的用戶連接和事務，并斷開所有當前的用戶。只要主服務器能再次組成quorum，就立刻重新提供數據庫服務。 一臺服務器可能運轉正常但是它和數據庫鏡下會話中的其他服務器之間的通信連路中斷了。如果那樣的話，我們稱服務器被孤立了。當safety為FULL時，如果主服務器被孤立，那么它將無法提供數據庫服務，因為會話中沒有其他服務器可與之共同組成quorum。 現在來關注一下數據庫鏡像狀態，從主服務器和數據庫開始。 主服務器數據庫狀態 當safety設置為FULL，主數據庫的正常操作狀態時SYNCHRONIZED狀態。當safety設置為OFF，主數據庫的正常操作狀態是SYNCHRONZING狀態。 ◆如果safety設置為FULL，主數據庫的起始狀態始終是SYNCHRONIZING，當主數據庫和鏡像數據庫事務日志同步后，數據庫狀態就轉換成SYNCHRONIZED， 下表顯示了主數據庫可能的狀態，以及導致狀態轉換的一些事件。 表5：主數據庫狀態，safety為FULL以及safety為OFF
當safety設置為FULL，主數據庫首先進入SYNCHRONIZING狀態，只要和鏡像數據庫同步，兩個伙伴都進入SYNCHRONIZED狀態。當safety設置為OFF，伙伴數據庫從SYNCHRONIZING狀態開始并在整個鏡像過程中保持該狀態。 對于這兩個safety設置，如果會話被掛起或者出現了鏡像服務器的redo錯誤，那么主數據庫進入SUSPENDED狀態。如果鏡像服務器不可用，那么主數據庫進入DISCONNECTED狀態。 在DISCONNECTED和SUSPENDED狀態下： ◆當safety設置為FULL，如果主服務器無法和見證服務器或者鏡像服務器自稱quorum，那么主數據庫被視為exposed。這意味著主數據庫為活動狀態，支持用戶連接和事務處理。但是沒有日志記錄被發送到鏡像數據庫。因此如果主數據庫失敗了，那么鏡像數據庫不包含任何自主數據庫進入exposed狀態后主服務器上發生的事務。同樣的，也不可以清理主數據庫的事務日志，這導致日志文件的無限增長。 注意：Management Studio's Object Explorer會在Server樹圖中數據庫名稱的旁邊報告主數據庫狀態。將主數據庫的SYNCHRONIZED狀態報告為 'Principal, Synchronizing'，DISCONNECTED狀態報告為'Principal, Disconnected.' 鏡像數據庫狀態 鏡像數據庫具有和主數據庫相同的狀態，但是由于鏡像數據庫始終處于nonrecovered狀態，因此在擔當鏡像角色的時候不能提供數據庫服務。下表顯示了可以導致鏡像服務器和數據庫狀態改變的一些最常見事件。 表6：鏡像服務器狀態，safety為FULL以及safety為OFF
和主數據庫一樣，Management Studio's Object Explorer在Server樹的數據庫名稱旁邊報告鏡像數據庫狀態。鏡像數據庫的SYNCHRONIZED狀態報告為'Mirror, Synchronizing'，DISCONNECTED狀態報告為'Mirror, Disconnected.' 見證服務器狀態 在sys.database_mirroring目錄視圖中有三種見證服務器狀態，CONNECTED、 DISCONNECTED和UNKNOWN。 表7：Witness服務器狀態（記錄在伙伴服務器上）
由于見證服務器狀態真正記錄在伙伴服務器而不是見證服務器上，因此這些狀態是從有利于伙伴的角度來設置的，因此當您看到見證服務器為DISCONNECTED狀態時，意味著伙伴和見證服務器斷開了。數據庫鏡像啟動后，如果鏡像服務器無法與主服務器進行初始化，那么見證服務器進入UNKNOWN狀態。 傳輸事務日志記錄 SQL Server主服務器和鏡像服務器傳輸消息和日志記錄的次序根據事務安全性的設置而不同。我們先研究同步傳輸，然后再研究異步傳輸。 當SQL Server將事務事件記錄在事務日志中時，日志記錄被寫入磁盤前暫時存放在日志緩沖區中。數據庫鏡像時，每次日志緩沖區被輸出到硬盤時（硬化），主服務器也將相同的日志記錄塊發送到鏡像服務器。 1. 當safety設置為FULL，只要SQL Server主服務器硬化它的日志記錄塊，就同時將相同的日志記錄塊發送到鏡像服務器，并認為本地的日志I/O和遠程鏡像服務器的日志I/O從本質上來說是一樣 的。這種傳輸稱為同步的，因為在一個事務提交之前，主服務器既要等待本地的I/O（硬化）還要等待等待鏡像服務器有關完成I/O（硬化）的答復。 每次主服務器或者鏡像服務器硬化日志緩沖區時，都會將緩沖區中最高的日志序列號（LSN）+ 1作為mirroring_failover_lsn記錄在元數據中。 mirroring_failover_lsn 用于協商事務日志最后的保障點，這樣兩個伙伴數據庫就可以在初始化時保持同步，在故障轉移后也保持同步。 當主服務器發送日志記錄給鏡像服務器時，主服務器上的mirroring_failover_lsn通常會提前一些。鏡像服務器硬化日志記錄時會記錄其mirroring_failover_lsn，然后回復主服務器。但是等主服務器接收到來自鏡像的確認信息時，主服務器可能已經開始硬化新的一組日志記錄了。 表8顯示了主服務器和鏡像服務器safety為FULL時的一個事件序列示例。 表8：Safety為FULL （同步傳輸）事件序列的示例
以上事件序列中關鍵的一點就是：當 safety設置為FULL時，主服務器硬化日志緩沖區以及將日志緩沖區中日志記錄的副本發送到鏡像服務器，二者是同時進行的。然后主服務器開始等待自己的I/O以及鏡像服務器的I/O，兩個I/O都完成后才認為事務完成了。當主服務器接收到來自鏡像的答復后，再開始處理下一次硬化。 當safety設置為FULL時，盡管主服務器和鏡像服務器之間協調緊密，但是數據庫鏡像不是分布式事務，也不使用兩階段提交協議。 ◆在數據庫鏡像中，兩個事務分別在兩臺服務器上執行，并不是一個跨服務器的分布式事務。 2. 當safety設置為OFF時，主服務器不等待來自鏡像服務器的確認消息，因此主服務器上已提交事務數量可能多于鏡像服務器，如圖9所示： 表9：Safety為OFF （異步傳輸）事件序列的示例
數據庫鏡像角色轉換 可以從數據庫鏡像服務器或者應用程序的角度來思考數據庫鏡像故障轉移問題。從數據庫鏡像服務器角度，故障轉移就是將鏡像服務器轉換為主服務器，以及使用新恢復的數據庫作為主數據庫。故障轉移可以是自動的、手動的、或者forced service。 ◆自動的 – 只有高可用模式下才會產生（safety設置為FULL以及見證服務器的參與） 當safety設置為FULL時，用于互換服務器角色的最好的方式是使用手動故障轉移，而不是forced service。 自動故障轉移 自動故障轉移是高可用模式下（safety為FULL使用見證服務器）數據庫鏡像的功能。大多數情況下，SQL Server可以在幾秒鐘內完成自動故障轉移。SQL Server可以進行局部自動故障轉移，因為包含在數據庫鏡像會話中的SQL服務器會彼此測試對方的存在。該過程稱為“ping”，但包含的操作遠不止一個普通的 IP地址ping。鏡像服務器和見證服務器聯系主服務器以檢查主物理服務器是否存在、SQL Server是否存在、以及主數據庫是否可用。類似的， 主服務器和見證服務器ping鏡像服務器以檢查鏡像物理服務器和SQL Server實例的可用性，以及鏡像數據庫的還原狀態。 假設使用safety FULL和見證服務器配置了數據庫鏡像。鏡像服務器即Server B通過ping發現主服務Server A不可用。Server B與見證服務器通信并收到見證服務器也看不到Server A的確認消息。那么Server B將和見證服務器組成quorum并將自己提升為主服務器角色。它將恢復它的數據庫并且通知見證服務器如今自己擔當了主服務器的角色（盡管數據庫處于disconnected狀態，新主數據庫的事務日志也不能被截斷）。 Server B的新主數據庫繼續重新執行事務日志中的活動，但是它將持續redo狀態而且大多數情況下只有很少的工作需要完成。在所有SQL Server版本中，新主數據庫只要完成redo過程就立刻可用了。當數據庫進入undo狀態時將可以接收用戶連接了。完成redo通常只需幾秒鐘，盡管余下的undo階段時間可能很長。在數據庫鏡像中，新的主數據庫只要redo階段完成就可以為用戶連接提供服務。新主服務器B的數據庫處于DISCONNECTED狀態而且是exposed，但是只要redo過程完成就可以提供數據庫服務。 通常將整個應用程序從主服務器重新定向到新主服務器花費的時間要多于數據庫鏡像的自動故障轉移。應用程序必須檢測和重試連接，這樣也會增加該過程的整體時間。此外，如果將新的SQL Server驗證登陸賬號添加到服務器，還需要使用系統存儲過程sp_change_users_login將這些登陸賬戶映射到新主數據庫的用戶賬戶。如果舊的主服務器上一些關鍵對象，如SQL Agent作業還沒有拷貝到新主服務器上，也會耽誤應用程序故障轉移的完成。（更多信息請閱讀該白皮書實現數據庫鏡像部分的“為故障轉移準備鏡像服務器”） 現在假設舊的主服務器聯機了。如果是手動故障轉移，或者舊的主服務器被快速修復的自動故障轉移場景，兩臺服務器需要進行角色互換，那么就必須進行一個協商過程。在數據庫鏡像重新開始之前，兩臺伙伴服務器需要決定彼此怎樣進行同步。鏡像故障轉移lsn這個過程中扮演了一個關鍵角色。 Server A （新鏡像服務器）落后了，但它并不清楚自己落后了多少。Server A向server B（新主服務器）報告它從server B接收的最后的鏡像故障轉移lsn。另一方面，Server B由于某些提交的工作而導致它有最新的鏡像故障轉移lsn，server A必須要追趕上server B。Server B將足夠數量的事務日志發送給server A，使server A通過重新這些執行事務并與Server B同步。 手動故障轉移 手動故障轉移就是依次交換兩個伙伴服務器的角色。它要求safety設置為FULL，并且主服務器和鏡像服務器處于SYNCHRONIZED狀態。 在主服務器上使用下面的ALTER DATABASE命令進行手動故障轉移：
或者在Management Studio的Database Properties/Mirroring對話框中單擊Failover按鈕。手動故障轉移在舊的主數據庫上斷開所有用戶連接并回滾所有未完成的事務。通過完成所有redo隊列中已提交的事務，回滾所有未完成的事務（在undo階段）來恢復鏡像數據庫。舊的舊的鏡像數據庫被分配了主數據庫角色，而舊的主數據庫則擔當新的鏡像數據庫角色。兩臺服務器根據它們的鏡像故障轉移lsn協商數據庫鏡像的新起點，然后處理角色互換。 可以使用手動故障轉移作為實現操作系統或者SQL SERVER實例的‘滾動升級’的一種方式來，假如您在初始化鏡像服務器之前首先升級鏡像服務器。更多信息請參閱SQL Server Books Online中'Manual Failover' 主題。 Forced Service 在鏡像服務器上使用ALTER DATABASE命令進行forced Service：
通常只有當safety為OFF并且主服務器再也無法運轉時才使用這種方式。也可以在safety為FULL使使用該命令，但是如果恢復的鏡像服務器無法組成quorum，它也不能提供數據庫服務。因此最好在safety為OFF（高性能操作模式）是使用該命令。由于異步的數據傳輸無法保證鏡像數據庫包含所有主服務器上提交的最新事務，因此有些數據可能會丟失。 數據庫鏡像可用性場景 在這一部分，您將根據以下兩類事件對數據庫鏡像預期的可用性結果進行研究： ◆一個或多個服務器或者數據庫失敗 服務器失敗可能是由于某個鏡像伙伴數據庫、或者某個SQL SERVER實例不可用。此外，即使服務器本身可以繼續運轉，但是數據庫鏡像伙伴服務器之間的通信連路可能中斷。 以下場景中，兩個組件的同時失敗被視為一個組件緊接著另一個組件的順序失敗。例如，Server A和B出現了同時失敗，鏡像系統將該事件視為一個順序事件：Server A失敗然后Server B失敗，或者反過來。 使用下面的規則來判定一個不可用事件的預期結果： 1.當safety設置為FULL時，主服務器需要至少一臺其他服務器才能形成quorum來保持數據庫可用。 如果主服務器無法組成quorum，也就無法再提供數據庫服務了。 2.當safety設置為FULL，如果鏡像服務器和見證服務器都無法聯系到主服務器，那么鏡像服務器可以和見證服務器組成quorum并且改變其角色，使之成為新的主服務器。 這就是自動的故障轉移。 3.當safety設置為FULL，如果主服務器和見證服務器合作組成quorum，但是斷開了和鏡像服務器的連接，那么主服務器失敗將不允許鏡像服務器和見證服務器組成quorum，也不允許鏡像服務器承擔主服務器的角色。 這樣可以防止所做的工作由于會話中斷而丟失。 4.當safety設置為FULL，如果失敗的主服務器在停機或者孤立后重新加入會話，同時舊的鏡像服務器已經承擔了主服務器的角色（和見證服務器組成quorum），那么舊的主服務器將在此次會話中承擔新鏡像服務器角色。 在故障轉移過程中，鏡像服務器和見證服務器會增加鏡像角色順序計數器。因為主服務器的鏡像角色順序計數器 小于另一個伙伴服務器和見證服務器的順序計數器，因此那兩臺服務器會在舊的主服務器重新加入會話之前組成quorum并開始工作。舊的主服務器擔當起鏡像的角色。 5.當safety設置為FULL并且會話中沒有見證服務器，或者見證不知何故退出了會話，鏡像伙伴服務器的失敗將導致無法組成quorum，主服務器也因此不再保持主數據庫可以使用。 無法組成quorum，因此不可能進行自動的故障轉移，如果見證服務器不包含在safety為FULL的會話中。 高可用場景中服務器失敗 高可用操作模式下的數據庫鏡像其目的就是盡可能增加數據庫的可用性。在這種模式下，如果主數據庫無法訪問，那么數據庫鏡像將迅速使鏡像數據庫可以接受訪問。在下面的一組場景中，我們的討論將從高可用配置加上三臺獨立的服務器開始。 在下面的高可用場景中，Server A作為主服務器啟動，Server B是鏡像服務器，而Server W是見證服務器，如圖1所示：
圖1：示例數據庫鏡像會話在高可用操作模式下啟動 所有這三臺服務器可以在同一個站點使用局域網連接，也可以在不同的站點使用WAN進行連接。Server A和Server B可以互換角色，但是Server W始終作為見證服務器。 現在來考慮如果其中一臺服務器出現故障時產生的結果。 場景 HASL1.1：主服務器失敗 下面的場景分析了在高可用模式下主服務器失敗時會發生什么。圖 2顯示了不同的角色，以及鏡像伙伴之間如何做角色轉換。
圖2：在高可用模式下，當主服務器Server A失敗，故障轉移發生 主服務器Server A失敗后，鏡像和見證服務器組成quorum，自動的故障轉移產生。如果重新恢復了原始的主服務器，它將擔當起鏡像服務器的角色。 注意：要導致高可用模式下的故障轉移，失敗可以發生在不同的級別上：服務服務器可能停機、主服務器上的SQL SERVER實例可能停止或者失敗、服務器上的主數據庫可能不可用或狀態可疑。在下面場景中，主服務器失敗可能由這些事件中的任何一個引起。 因為Server B和W可以組成quorum，并且二者均無法聯系Server A，那么Server B可以將自己提升為新的主服務器。但是如果沒有鏡像服務器，鏡像會話就被認為是exposed。 Server A恢復后，它成為新的主服務器，鏡像會話也不再是exposed。 單服務器失敗事件并不多見，兩臺服務器失敗就更少見了，因此研究在這種情況下出現的結果十分有用。 兩臺服務器可以同時或者幾乎同時失敗，但從數據庫鏡像的角度來看，其結果被視為一臺服務器失敗緊接著另一臺也失敗了。因此這些場景只考慮當多臺服務器順序失敗時的后果。 接下來的兩個場景分析主服務器 Server A失敗，緊接著其他兩臺服務器也失敗時會產生的結果。 ◆新的主服務器 Server B失敗； 場景 HASL1.2：主服務器失敗，隨后新的主服務器失敗 同前面的場景一樣，在高可用操作模式下，如果主服務器首先失敗，那么故障轉移發生。圖3顯示了如果新的主服務器接下來也失敗了，那么無論怎樣恢復這些服務器，新的主服務器（Server B）始終保持其主服務器的角色。
圖3：由于主服務器失敗，接著新主服務器也失敗而導致角色轉換 Server A失敗后，Server B成為新的主服務器，但是無法將數據發送給鏡像服務器，因此主服務器處于exposed，即使它仍然提供數據庫服務。當Server A失敗緊接著Server B也失敗，那么就不存在數據庫鏡像了，因為Server B已經停工了。 如果Server A首先恢復，它從見證服務器的mirroring_role_sequence號中檢測到見證服務器已經組成了新的quorum。 Server A接納了鏡像服務器的角色，然后等待Server B恢復。Server B一旦恢復，立刻開始了和Server A的數據庫鏡像過程。如果Server B先恢復，那么就重新回到了在HASL1。1中顯示的初始場景。 注意：如果Server W在Server A和Server B相繼失敗后也宣告失敗，導致所有三臺服務器均停工，那么無論以什么次序恢復見證服務器，已經轉換完成的Server A和Server B的角色將保持不變。 場景 HASL1.3：主服務器失敗，隨后見證服務器失敗 主服務器失敗后發生故障轉移。見證服務器可能接下來也失敗，如圖4所示：
圖4：見證服務器緊隨原始主服務器出現失敗，那么新主服務器無法提供數據庫服務 當見證服務器 Server W主服務器 Server A失敗后也出現失敗，那么新主服務器 Server B依然為主服務器但被孤立，無法組成quorum，也不能提供數據庫服務。 如果Server A首先恢復，Server B的mirroring_role_sequence號將比Server A的大1，因為產生了故障轉移。這些信息指示Server A如今Server B在Server A只有擔當了主服務器的角色。Server A和Server B組成quorum 并成為一對鏡像，此后兩臺服務器保持同步。除非Server W恢復，否則不會產生自動故障轉移。 注意：如果Server W在Server A和Server B相繼之后也宣告失敗，那么無論以什么次序恢復見證服務器，已經轉換完成的Server A和Server B的角色將保持不變。 場景 HASL2.1：鏡像服務器失敗 如果鏡像服務器首先失敗，那么主服務器被視為exposed，因為它無法發送數據給鏡像服務器。圖 5顯示了Server B，即鏡像服務器失敗時的行為。
圖5：在高可用模式下，當鏡像服務器Server B失敗時不產生故障轉移 沒有自動故障轉移發生，鏡像伙伴也不會交換角色。當Server B恢復時，所有三臺服務器還原到其初始角色和狀態。 下表顯示了鏡像服務器Server B失敗以及恢復時數據庫狀態。 由于沒有鏡像服務器，數據無法存放在冗余數據庫中，因此會話處于exposed。 Server B一旦恢復立刻重新擔當起它的鏡像服務器角色。只要兩臺服務器同步，鏡像會話就不再被視為exposed。 接下來的兩個場景考慮鏡像服務器Server B失敗，緊接著主服務器Server A或者見證服務器Server W失敗時產生的結果。 場景 HASL2.2：鏡像服務器失敗，隨后主服務器失敗 緊隨鏡像服務器之后主服務器也失敗了，鏡像伙伴服務器的角色保持不變。圖6顯示了采用不同方式還原服務器時角色將如何轉換。
圖6：鏡像服務器失敗隨后主服務器主失敗，那么見證服務器被孤立 在Server B和Server A都失敗后，各服務器狀態顯示在圖中的右上角處。 注意：如果Server W在Server B和Server A相繼失敗之后也宣告失敗了，那么以任何順序還原這些服務器將導致相同結果。 場景 HASL2.3：鏡像服務器失敗，隨后見證服務器失敗 鏡像服務器失敗，隨后見證服務器也失敗，那么主服務器被孤立并且無法和任何其他服務器組成quorum。因此它必須停止數據庫的工作，如圖7右上角所示。
圖7：A鏡像服務器失敗，隨后見證服務器失敗，導致主服務器無法提供數據庫服務 由于鏡像服務器故障以及隨后的見證服務器失敗，主服務器 Server A保持其主服務器角色，由于無法和任何其他服務器組成quorum，而safety又被設置成FULL，因此不再為數據庫提供服務，并斷開所有的用戶連接。 如果Server B首先恢復，那么數據庫鏡像將重新開始工作，盡管由于缺失見證服務器而不會產生自動故障轉移。 如果Server W首先恢復，那么情況與圖5中顯示的一樣。 注意：如果Server A在Server B和Server W相繼失敗之后也宣告失敗，那么以任何次序還原這些服務器其最終結果保持不變。 場景 HASL3.1：見證服務器失敗 見證服務器失敗時，數據庫鏡像繼續進行但是不可能產生自動的故障轉移。如果再有一臺或多臺服務器失敗，就意味著沒法組成quorum，那么主服務器上的數據庫也不再服務于數據庫用戶。
圖8：在高可用模式下，見證服務器Server W首先失敗，那么數據庫鏡像繼續 Server W恢復后，兩個伙伴服務器Server A和Server B維持它們的初始角色。 下表顯示了見證服務器失敗以及恢復后，數據庫狀態以及quorum的變化。 下面的兩個場景考慮見證服務器Server W失敗，緊接著主服務器 Server A或者鏡像服務器Server B失敗時產生的結果。 場景 HASL3.2：見證服務器失敗，隨后主服務器失敗 見證服務器首先失敗，那么數據庫鏡像將繼續進行，但是不可能產生自動的故障轉移。其余兩臺服務器中任何一臺失敗將導致無法組成quorum，余下的那臺服務器將被孤立。
圖9：原始見證服務器失敗，隨后主服務器失敗，鏡像伙伴角色保持不變 如果Server W首先恢復，那么Server B將從見證服務器那里檢測到最后的主服務器是Server A，同時Server B依然是鏡像服務器。最終Server A恢復時，它將保持其主服務器角色。 注意：如果Server B在Server W和Server A相繼失敗后也宣告失敗了，那么以任意次序還原這些服務器都不會影響最終結果。 場景 HASL3.3：見證服務器失敗，隨后鏡像服務器失敗 如果見證服務器失敗，隨后鏡像服務器也失敗，那么主服務器被孤立。由于safety設置為FULL并且主服務器無法組成quorum，它將不再提供數據庫服務，如圖10所示。
圖10：見證服務器失敗，隨后鏡像服務器失敗，主服務器必須停止其數據庫服務 注意：如果Server A在Server W和Server B相繼失敗之后也宣告失敗， 那么以任意次序還原這些服務器都不會影響最終結果。 總結：高可用場景中服務器失敗 從這些場景中可以得出幾個結論。在高可用操作模式下： 1.如果主服務器首先不可用，那么產生自動的故障轉移，原先的鏡像服務器將擔當主服務器角色，并使其數據庫服務于用戶活動。后續的服務器失敗和恢復不會影響使用新主服務器的數據庫鏡像的整體配置。數據庫鏡像將以相反的方向繼續進行。 2.如果鏡像首先不可用，那么產生自動的故障轉移 。后續的服務器失敗以及恢復次序都不會影響鏡像伙伴角色。 3.如果見證服務器首先不可用，那么不可能產生自動的故障轉移，鏡像伙伴服務器將保持其初始角色。后續的服務器失敗以及恢復都不會影響鏡像伙伴角色。 下表總結了在高可用場景中出現一臺或兩臺服務器失敗時產生的結果。表中假設的條件是safety設置為FULL并且鏡像會話中的服務器滿足下列條件： A：主服務器， SYNCHRONIZED 表中使用灰色加亮顯示故障轉移場景。 表10：總結：單服務器或者雙服務器失敗，顯示伙伴服務器角色和數據庫狀態
高可用場景中通信失敗 高可用操作模式需要三個SQL Sever實例。如果這些服務器位于兩個或三個獨立的物理站點并且相距很遠，那么這些站點間的通信就很可能出現問題。換句話說，服務器依然運轉但是彼此間的通信連路中斷了。這種情況比前面的那些場景要復雜一些，但原理是一樣的。 下面高可用操作場景中通信失敗的研究將通過兩組來完成。第一組是基于三個來自不同站點的SQL SERVER實例，因此有三條獨立的通信連路。第二組是基于兩個獨立站點上的服務器，第一個站點上的一對服務器和第二個站點上的第三臺服務器之間有一條通信連路。 先從第一組開始，假設一個數據庫會話中所有三臺服務器之間有三條獨立的通信連路。例如，主服務器、鏡像服務器和見證服務器位于三個獨立的協作站點上（也有可能三臺服務器位于同一個站點，但使用私有網絡連接） 初始條件是Server A上運行主數據庫并且與其鏡像伙伴Server B保持同步。 Server B上是鏡像數據庫Safety設置為FULL，見證服務器 (Server W)也包含在數據庫鏡像會話中。圖11顯示了初始配置。
圖11：高可用配置中三臺獨立服務器、三條獨立通信連路的初始狀態 注意：要獲得頁面上圖表的解釋，請參閱前面介紹的“高可用場景中服務器失敗” 根據圖11，三條鏈路可能首先中斷：A/B， A/W和B/W。注意當某條通信連路中斷時，所有三臺服務器依然運轉正常。只有主服務器和鏡像服務器之間的通信連路有一些影響，如表11所示。 表11：總結：單條通信連路中斷
只有主服務器/鏡像服務器的連接中斷會對鏡像造成影響。其他的連路中斷，例如主服務器/見證服務器或者鏡像服務器/見證服務器之間的通信中斷不會改變數據庫鏡像會話的行為。 總之，表HACL1顯示出： ◆所有單條鏈路中斷場景中只有主服務器/鏡像服務器鏈路中斷會影響數據庫鏡像，主服務器運行 狀態為exposed，因為沒有日志記錄發送到鏡像。 現在考慮如果第二條連路中斷產生的結果。兩條連路可以同時中斷，也可以相繼中斷。 如果兩條連路同時中斷，其最終結果與兩條連路相繼中斷是一樣的。但是無法事先預料中斷的先后順序；只有知道了先后次序才能夠據此分析鏈路同時中斷的結果。 由于這個原因，我們只考慮鏈路順序中斷的情形。表12列出了高可用模式中通信鏈路中斷的一些基本場景。 表12：大部分雙-通信鏈路中斷的結果與服務器故障場景中單機故障是一樣的
表HACL2顯示所有順序的雙-通信鏈路失敗都等價于前一部分介紹的單服務器故障場景，因此我們不再這里對它們作重復分析了。 值得注意的一點是： ◆兩條鏈路中斷時只有一個場景會產生故障轉移：主服務器/見證服務器鏈路中斷，隨后主服務器/鏡像服務器鏈路中斷。 如果主服務器/鏡像服務器鏈路中斷，隨后主服務器/見證服務器也出現鏈路中斷，那么不會產生故障轉移，即使主服務器被孤立而且鏡像服務器和見證服務器無法聯系上它。 我們再仔細研究一下場景 HACL1.2。 場景 HACL1.2：主服務器/鏡像服務器連路中斷，隨后主服務器/見證服務器鏈路中段 如果主服務器/鏡像服務器鏈路中段，隨后主服務器和見證服務器之間的鏈路也中斷了，那么主服務器被孤立。它看不到其他服務器并且失去了它的quorum。同時，鏡像服務器和見證服務器無法知道主服務器是否依然健在，因此Server B擔當起主服務器，然后自動的故障轉移產生。圖12顯示了這些事件。 圖12：在高可用模式下， 主服務器/鏡像服務器鏈路中段，隨后主服務器/見證服務器鏈路中段，不產生故障轉移 當主服務器/鏡像服務器以及主服務器/見證服務器之間的通信鏈路相繼中斷有，Server A被孤立并使其數據庫停止服務。Server B和W無法形成quorum，因為Server A可能執行了一些Server B上沒有的工作。 如果主服務器/見證服務器 (A/W) 鏈路中斷首先修復，那么Server A繼續擔當其主服務器角色，狀態為DISCONNECTED。但是不會進行數據庫鏡像，因為主服務器和鏡像服務器之間的連接還沒有修復。 如果主服務器/鏡像服務器 (A/B) 鏈路中斷首先修復，那么Server A將繼續與Server B的數據庫競相，即使沒有見證服務器，因此該會話是exposed。除非主服務器/見證服務器連接最終被修復，否則不會產生自動的故障轉移。 總結：高可用場景中通信失敗：三個站點 下表總結了使用三臺獨立物理服務器時單鏈路和雙-鏈路中斷的行為。 表中的初始條件是Safety設置為FULL，服務器分別是：A：主服務器， SYNCHRONIZED 表13：總結：單條鏈路中斷和雙-鏈路中斷，高可用模式，三臺獨立服務器，Safety設置為FULL 場景 HACL4：兩個站點，見證服務器位于鏡像服務器站點 如果所有服務器之間僅有一條通信連路，那么必須選擇見證服務器的位置。首先，假設見證服務器和鏡像數據庫服務器放置在一起。兩組服務器之間僅有一條通信連路，該鏈路可能中斷，如圖13所示。
圖13：主服務器和鏡像服務器/見證服務器站點之間的通信連路中斷了 Server A看不到見證服務器Server W或者鏡像數據庫服務器Server B，因此無法組成quorum。Server B和Server W可以組成quorum，但二者均無法看見主服務器Server A。鏈路中斷的結果顯示在圖14。
圖14：通信連路中斷并且見證服務器位于鏡像服務器站點，產生故障轉移 因為Server A無法看見見證服務器Server W或者原先的鏡像伙伴Server B，因此必須進入disconnected狀態并使數據庫不可用。Server B和Server W可以組成quorum。Server B無法看見Server A，因此Server B試圖成為主服務器并使其數據庫聯機。因為Server W也看不到Server A，因此同意了Server B。Server B現在有了quorum，擔當起會話的主服務器角色，然后還原其數據庫。 如果恢復通信連路，Server A能夠看到Server B如今成為主服務器，并檢測到見證服務器Server W也認可Server B為主服務器。Server A將其角色轉換為鏡像服務器，然后嘗試與新主服務器同步。同步之后的配置結果如圖15所示。
圖15：該場景通信連路恢復后的版本，數據庫鏡像按反方向進行 總結：見證服務器位于鏡像服務器的遠程站點上，如果站點間的通信鏈路中斷，自動的故障轉移產生。 場景 HACL5：兩個站點，見證服務器位于主服務器站點 在這個高可用場景中，假設將見證服務器放置在主服務器所在的同一站點上，如圖16所示，然后兩個站點間的通信中斷了。
圖16：主服務器/見證服務器和鏡像服務器之間的通信中斷 在這種情況下，負責鏡像數據庫的Server B被主服務器和見證服務器孤立。Server A和Server W繼續組成quorum，因此Server A保持其數據庫為主數據庫。 但是，Server A同時將數據庫設置成disconnected狀態，因為它無法看到Server B也不可能進行數據傳輸。Server B也無法看到Server A，因此也進入disconnected狀態。配置結果如圖17所示。 圖17：該場景中通信失敗導致兩個伙伴為disconnected狀態 Server A繼續接受事務但無法截斷事務日志記錄。如果迅速恢復了鏈路，鏡像會話還可以重新同步并返回到初始操作狀態。 總結：見證服務器和主服務器位于同一站點，鏡像服務器位于遠程站點，站點之間的通信中斷不會產生自動的故障轉移。 總結：高可用場景中通信連路中斷 在使用三臺獨立服務器的高可用配置中，有三條獨立的通信連路。 ◆主服務器/鏡像服務器出現通信失敗，沒有自動的故障轉移會發生。
圖19：高保護場景中如果鏡像服務器不可用 ，那么主數據庫不受影響 場景3：高保護場景中如果主數據庫不可用，那么鏡像數據庫必須繼續擔任鏡像，但進入disconnected狀態，如圖20所示。 圖20：高保護場景中如果主數據庫不可用，那么鏡像數據庫進入disconnected狀態 因為高保護操作模式使用safety FULL，因此任何破壞都導致主數據庫比可用，而鏡像數據庫繼續維持recovering狀態：沒有數據庫是聯機的。其結果是：該模式對于高可用性需求而言不是一個好的解決方案，因此更適合作為一種臨時方案，如必須將見證服務器移除一小段時間。 高性能方案 高性能操作模式配合safety OFF一起工作。沒有見證服務器角色。因為鏡像配置中只包括主數據庫服務器和鏡像數據庫服務器，因此只有一條通信連路。盡管類似于高保護模式，但由于safety設置為OFF，因此其行為與高保護模式并不相同。 場景1：在高性能操作模式中使用兩個SQL SERVER實例。一個負責主數據庫另一個負責鏡像數據庫。因此服務器之間只有一條通信連路并且可能中斷，導致如圖21所示的配置結果。 圖21：高性能場景中通信失敗，兩個伙伴均進入disconnected狀態，但是主數據庫依然可用 由于safety設置為OFF， Server A不需要quorum就可以使數據庫保持為可用狀態。因此盡管已經進入disconnected狀態，主服務器還可以繼續接受用戶活動。如果通信恢復，那么鏡像數據庫將嘗試追趕主數據庫但無法做到，或者出現redo錯誤，如果它不能找回所有丟失的事務。 場景2：在高性能場景中，如果鏡像數據庫不可用，那么主數據庫結果顯示在圖22中。 圖22：如果在高性能模式下鏡像服務器不可用，主數據庫不受影響 由于safety設置為OFF，因此主數據庫依然可用。 場景 3：如果在高保護模式下主數據庫不可用，那么鏡像數據庫依然作為鏡像，但將被斷開，如圖23所示。
圖23：如果主服務器不可用，那么Server B不會受到影響，但是進入disconnected狀態 高性能操作模式和高保護模式一樣，沒有自動的故障轉移。由于safety設置為OFF，當鏡像服務器不可用時，主服務器將保持其數據庫為可用。同樣由于safety設置為OFF，不保證事務一定到達鏡像數據庫。如果強制故障轉移到鏡像服務器，那么有些事務可能會因此丟失。 實現數據庫鏡像 可以在SQL SERVER 2005 Books Online，數據庫鏡像主題的“How To”中找到實現數據庫鏡像的基本信息。在白皮書的這一部分，我們來研究實現數據庫鏡像的一個特殊示例以及最佳實踐。 監視數據庫鏡像 通過在SQL SERVER 2005 Management Studio的Object Explorer中檢查主數據庫和鏡像數據庫，可以查明每個數據庫鏡像伙伴的狀態。如果主數據庫和鏡像數據庫是同步的，那么Object Explorer就在主數據庫名稱的后面附加一個（Principal， Synchronized）消息，在鏡像服務器名稱的旁邊附加一個（Mirror， Synchronized）。可以在主服務器上彈出的數據庫 Properties對話框中觀察Mirroring頁面下方的狀態框，從而檢查數據庫鏡像會話的狀態。（數據庫 Properties對話框不會在鏡像服務器上打開）。 還可以查詢數據庫鏡像目錄視圖sys.database_mirroring和sys.database_mirroring_witnesses（更多關于使用目錄視圖檢查鏡像會話中數據庫狀態的信息，請參閱該白皮書前面數據庫動態部分的“Database Mirroring Catalog View Metadata”。SQL SERVER Books Online中也包含了目錄視圖的完整文檔。） 數據庫鏡像性能計數器 可以使用性能計數器監視數據庫鏡像會話中鏡像伙伴之間的網絡流量。SQL Server Database Mirroring對象包含了大量有用的性能計數器來監視主服務器和見證服務器。（參閱SQL Server Books Online中的"Monitoring Database Mirroring"） 可以在每個數據庫上設置Database Mirroring對象。如果需要在一臺服務器上監視不止一個數據庫，那么既可以單獨監視某個數據庫的活動，也可以監視所有數據庫的全部活動。 對于主服務器，Log Bytes Sent/sec 計數器指示主服務器發送日志數據到鏡像服務器的速率，而Log Send Queue指示在某個給定時間點事務日志緩沖區中有多少字節要發送到鏡像服務器。隨著事務日志記錄從主服務器發送到鏡像服務器，主服務器的發送隊列將逐漸縮小，但也會隨著新的日志記錄進入日志緩沖區而增長。主服務器上的Transaction Delay 計數器指示主服務器由于等待鏡像服務器關于日志接收的確認消息導致的延遲。主服務器上的Sent/sec計數器與主服務器給鏡像服務器發送的數據頁面有關。 在鏡像服務器上，Log Bytes Received/sec指示鏡像服務器和主服務器之間相差多少。（見上面Log Bytes Sent/sec 計數器）。Redo Queue 計數器指示redo隊列的大小。鏡像服務器在redo階段使用redo隊列重新執行來自主服務器的事務。Redo Bytes/sec指示鏡像服務器執行redo隊列中事務的速率。 對于每個伙伴服務器，Sends/sec和Receives/sec 計數器指示有多少個發送和接收動作Bytes Sent/sec和Bytes Received/sec 計數器指示在每個伙伴服務器上那些發送和接收動作包含的字節數。 估計Redo和Catch-up時間 如果出現故障轉移，可以使用Redo Queue和Redo Bytes/sec來估算鏡像數據庫完成redo并成為可用狀態需要花費的時間。使用下面的簡單公式進行計算： 估計的redo時間（秒） = Profiler事件 SQL Server 2005 Profiler包含了一個數據庫鏡像事件類。Database:Database Mirroring State Change事件將記錄被監視服務器是否發生了狀態改變。（參見SQL Server Books Online主題“Database Mirroring State Change Event Class”）。當使用這個事件類時包含Database Name和State來會對您大有幫助。可以使用該事件通知您數據庫鏡像會話中的任何狀態改變。 數據庫鏡像排錯 數據庫鏡像最容易出錯的地方就是配置過程和運行過程。 排除設置錯誤 如果已經設置了數據庫鏡像但是無法啟動，那么重新開始所有配置步驟。 1.確認鏡像服務器盡可能接近主數據庫。如果嘗試啟動數據庫鏡像時收到了以下的錯誤消息： 遠程“AdventureWorks”數據庫沒有前滾到本地數據庫日志副本中包含的一個時間點。（Microsoft SQL SERVER， 錯誤：1412） 說明鏡像數據庫滯后于主數據庫。需要將主數據庫的事務日志備份應用到鏡像數據庫（使用NORECOVERY），從而使鏡像數據庫恢復到某個時間點，并可以從此時間點開始接收來自主數據庫的日志記錄。 2.確認每個服務器的SQL SERVER Windows服務帳戶彼此相互信任。如果服務器所在的域沒有建立信任關系，那么確保證書是正確的。 3.通過查詢sys.database_mirroring_endpoints目錄視圖，確認不僅定義而且啟動了endpoint：
確認使用了正確的完全限定計算機名稱以及正確的端口號。如果在一臺物理服務器的多個實例之間配置鏡像，那么端口號就必須是唯一的。SQL SERVER服務登陸帳號需要CONNECT到endpoint的訪問權限。 最后，確認為服務器定義了正確的endpoint角色。 4.確認在ALTER DATABASE命令中指定了正確的鏡像伙伴名稱。可以在主服務器和鏡像服務器的sys.database_mirroring目錄視圖中（以及高可用模式下的sys.database_mirroring_witnesses witnesses）檢查鏡像伙伴名稱。 排除運行時錯誤 如果數據庫鏡像設置正確，然后在運行過程中出現了錯誤，請檢查會話的當前狀態。如果由于錯誤而使鏡像處于SUSPENDED狀態，就可能在鏡像服務器上產生redo錯誤。檢查并確認鏡像服務器上有足夠的磁盤空間用于redo（數據文件所在分區的剩余空間）和日志hardening（日志文件所在分區的剩余空間）。當您準備重新啟動會話時，使用ALTER DATABASE來重新開始會話。 如果無法連接到主數據庫，最可能的原因就是safety設置為FULL并且主服務器無法組成quorum。這種情況能夠發生，例如，如果系統在高保護模式下運行（safety為FULL但沒有見證服務器），鏡像服務器又斷開了和舊的主服務器的聯系。可以在鏡像服務器上使用下面的命令強制鏡像服務器進行恢復：
問題就在于一旦恢復了鏡像數據庫，鏡像服務器將成為主服務器但卻無法形成quorum，因此無法服務于數據庫。如果那樣的話，只要把safety設置為OFF就可以允許它服務于數據庫了。 安全性與性能 數據庫鏡像的性能是關于活動類型和事務安全性的一個函數。 傳輸日志到鏡像服務器會影響主服務器性能。數據庫鏡像給主服務器帶來的開銷是關于活動類型的一個函數。數據庫鏡像在多用戶以及大量長事務的系統上操作性能最好，因為數據庫服務器正常的事務活動會掩蓋傳輸日志記錄到鏡像服務器的引起的開銷。如果單個用戶順序執行大量短事務，那么數據庫鏡像給每個事務造成的開銷將十分顯著。 主服務器性能同樣受Safety設置的影響。當safety設置為FULL時，主服務器必須等待鏡像服務器表示已經收到日志記錄的確認信息，才可以將事務提交消息返回給客戶端。如果有大量的用戶和大量的長事務，那么這種等待導致的開銷并不明顯。單線程系統和包含許多小事務的系統在safety OFF時可以運行的更好。 因為鏡像服務器連續不斷地重新執行從主服務器接收的數據更新事務，鏡像服務器的數據緩存將變得'hot'。換句話說，就是使用那些和主服務器類型相同的數據更新操作所涉及的數據頁面和索引頁面來加工緩存。為了使鏡像服務器的緩存更接近于主服務器緩存，數據庫鏡像將一個SELECT提示也傳遞給鏡像服務器，從而可以在鏡像服務器重新生成用于數據查詢的緩存內容。這樣可以幫助鏡像服務器更接近于主服務器，同時減少故障轉移時剩余的redo時間。很明顯，鏡像服務器上任何其他活動，包括對數據庫快照的查詢也會影響緩存的狀態，并因此增加故障轉移時完成日志redo的時間。 測試數據庫鏡像 當設置自己的系統來測試數據庫鏡像時，有許多選項可用。所有數據庫鏡像都要求在數據庫鏡像會話中的服務器必須是不同的SQL SERVER實例。因此可以在一臺物理服務器上配置和測試數據庫鏡像，如果您安裝了多個SQL SERVER 2005關系數據庫引擎。也可以在一臺虛擬服務器上測試多個實例，但是在物理服務器上進行測試更加可信。 進行數據庫鏡像的負載和壓力測試時需要不同的物理服務器。一臺服務器上的兩個或者三個實例可能會消耗不切實際的服務器資源。此外服務器之間的網絡連接質量也同樣重要。主服務器和鏡像服務器之間的網絡越好，日志記錄和消息傳送的速度就越快。 最逼真的測試就是在一臺真正的目標服務器或者試驗臺上進行，并且和最終系統的物理屬性完全相同。當您在一臺服務器上測試多個實例時，只能通過停止實例或者關機的方式來模擬數據庫鏡像中服務器失敗的效果。使用多臺物理服務器時，就可以通過斷開網線的方式來測試網絡連接失敗的效果。 下面的實踐能夠幫助您創建測試環境： ◆要測試服務器失敗，關閉SQL SERVER實例，通過SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。
為故障轉移準備鏡像服務器 數據庫鏡像其實就是數據庫到數據庫的聯系。只有數據庫中的數據會通過日志記錄從主數據庫發送到鏡像數據庫。就像日志傳送和復制一樣，必須準備備用服務器和鏡像數據庫，以便出現故障時可以完全接管主數據庫的工作。當您準備鏡像服務器時，應該從以下幾個層面進行考慮。 在物理服務器層面，確保備用服務器和主服務器擁有相同的或者盡可能接近的物理CPU和內存配置，否則備用服務器在故障轉移后將無法勝任工作。此外可能還有一些支持應用程序、監視器、以及支持程序運行的可執行文件等等，都需要在鏡像服務器上進行配置。 在SQL SERVER層面，確保備用服務器和主服務器擁有相同的SQL SERVER配置（例如，AWE、最大并行化程度）。但最重要的就是登陸帳戶和賬戶權限。主服務器上所有激活的SQL SERVER登陸帳戶都必須同時存在鏡像服務器上，否則一旦出現故障轉移，那么應用程序將無法使用這些登陸帳戶連接到新的主服務器上。可以使用SQL SERVER集成服務的Transfer Logins任務將登陸帳戶和密碼從一臺服務器拷貝到另一臺服務器，但您還必須為這些登陸帳戶設置數據庫權限。如果將登陸帳戶傳輸到另一個不同的域，那么可能出現不匹配色的SID，需要您去匹配它們。SQL SERVER主服務器上可能還存在大量的支持對象需要被轉移到備用服務器上：SQL Agent作業和警報、SQL SERVER集成服務包、支持數據庫、連接服務器的定義、備份設備、維護計劃、SQL Mail或者數據庫設置、可能還有分布式事務協調器（MSDTC）設置，等等。 當SQL Agent作業被傳輸到備用服務器后，大部分將被迫設置為禁用。一旦出現故障轉移，需要您啟用這些作業。故障轉移后，如果應用程序使用SQL SERVER驗證，還需要將SQL SERVER新的主服務器上的登陸帳戶解析成新的主服務器上的數據庫用戶。完成該任務最好的工具就是存儲過程sp_change_users_login。 多數據庫的問題 許多應用程序使用一臺服務器上的多個數據庫。多個數據庫可以被一個應用程序引用，也可能被多個應用程序引用。但是數據庫鏡像每次只能在一個數據庫上工作。當您設計數據庫鏡像時需要考慮這一點。 如果您希望高可用模式，那么最適合的就是一個應用程序配合一個數據庫。當自動的故障轉移發生時應用程序不再需要主服務器上的任何數據庫。考慮如果多個數據庫在一臺服務器上并且操作在高可用模式下，那么可能出現什么情況呢？如果一臺物理服務器掉電了，或者一個SQL SERVER實例失敗了，或者網絡通信失敗了，那么所有數據庫將自動故障轉移到備用服務器，而他們的鏡像將成為新的主數據庫。如果見證服務器可用，應用程序可以連接到新的主數據庫。但是如果某個數據庫由于磁盤失敗而產生了分頁，因此只有這個數據庫被故障轉移，那么會發生什么呢？如果那樣的話，應用程序就有可能無法連接到所有正確的數據庫。 數據庫鏡像和高可用性技術 SQL SERVER 2005現在至少支持四種高可用性技術，盡管不同技術相互之間有些功能重疊，但每種技術都有各自的優缺點。 這些技術是： ◆數據庫鏡像 – 為了便于討論，我們將考慮高可用操作模式以及FULL safety和見證服務器。 表14：比較SQL SERVER 2005高可用性技術
數據庫鏡像和群集 數據庫鏡像和故障轉移群集最主要的差異就是提供了不同級別的冗余。數據庫鏡像提供的保護是數據庫級別的，而群集提供的保護是服務器實例級別的。另一個主要差別就是在數據庫鏡像中，主服務器和鏡像服務器是獨立的 SQL SERVER實例，兩個實例有不同的名稱；而群集中的 SQL SERVER實例則使用相同的虛擬服務器名稱和IP地址，而且無論哪個節點主持群集實例，虛擬服務器名稱和IP地址始終保持不變。 如果您需要在服務器一級的數據庫保護（例如，您的應用程序需要同時訪問統一服務器上的多個數據庫），故障轉移群集將是更適合的選擇。但是，如果每次只須為一個數據庫提供可用性，那么數據庫鏡像具有更多優勢。 數據庫鏡像不像群集那樣需要專門的硬件，也沒有共享存儲介質失敗的潛在危險。數據庫鏡像可以在最短時間內讓備用數據庫開始提供服務，其速度快于任何其它的高可用技術。此外，數據庫鏡像能夠與ADO。NET和SQL Native Access Client很好的配合在一起，從而實現客戶端的故障轉移。 不能在群集中使用數據庫鏡像，但是可以考慮使用數據庫鏡像作為一種手段來創建群集數據庫實例的一個熱備用份。這樣做需要特別小心，因為群集的故障轉移時間長于數據庫鏡像的超時值，高可用模式下的鏡像會話將對群集的故障轉移做出反應，認為這是主服務器失敗了，然后會將群集節點設置為鏡像狀態。
數據庫鏡像和日志傳輸 數據庫鏡像和日志傳輸都依賴SQL SERVER數據庫提供的恢復和還原功能。在數據庫鏡像中，鏡像數據庫始終保持recovering狀態，連續不斷地還原來自主數據庫的事務日志。而日志傳輸中的備用數據庫則周期性地應用事務日志備份中的事務。因為bulk-logged數據被附加到事務日志備份中，因此日志傳送可以工作在bulk-logged恢復模型下。數據庫鏡像則不同，它直接將日志記錄從主數據庫傳送到鏡像數據庫中而且不能遞送bulk-logged數據。 很多情況下數據庫鏡像可以提供與日志傳送相同的數據冗余以及更高的可用性和自動故障轉移。但是，如果應用程序依賴一臺服務器上的多個數據庫，那么日志傳送是有效的方式（參閱前一部分介紹的“Multi-Database Considerations”）。 此外，某些數據庫鏡像場景中還可以通過日志傳送作為補充。例如：您可以某處配置一個高可用數據庫鏡像，然后將主數據庫日志傳送到遠程站點以提供災難恢復。圖24顯示了如何進行這種配置。
圖24：將主數據庫日志傳送到遠程服務器 這種方式的優點就是：一旦整個站點失敗了，第二個站點上的數據還繼續可用。但是，如果數據庫鏡像失敗了，從Server B到遠程備用服務器的日志傳送通常必須重新開始。 其它使用日志傳送補充數據庫鏡像的場景就是作為主服務器的本地備用，主服務器的數據庫鏡像會話用于災難恢復。此時，數據庫鏡像會話運行在高性能操作模式下，遠程站點的鏡像服務器作為遠程備用服務器。
在高性能模式中存在的數據丟失，如果主服務器失敗并且使用強制恢復服務的方式恢復了鏡像服務器。如果您正在對舊的主服務器進行日志傳送，并且如果舊的主服務器事務日志文件沒有損壞，那么可以對主數據庫進行“結尾日志”備份來獲得事務日志中最后一組記錄。如果備用日志傳輸數據庫已經應用了所有其它的事務日志備份，您就可以將結尾日志備份應用到備用服務器，這樣不會丟失舊的主服務器上的任何數據。然后可以對日志傳送備用服務器中的數據和遠程數據庫做個比較，在需要時將丟失的數據拷貝到遠程服務器。 當您對比日志傳輸和數據庫鏡像功能時，需要明確的一點就是：對主數據庫進行數據庫和日志備份很重要。將這些日志備份應用到的日志傳送服務器可以對數據庫鏡像配置起到補充作用。 閱讀原文：原文鏈接 該文章在 2025/1/10 10:51:22 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
