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