日韩欧美人妻无码精品白浆,夜夜嗨AV免费入口,国产欧美官网在线看,高校回应聋哑女生因长相完美被质疑

概述

數(shù)據(jù)庫鏡像是SQL SERVER 2005 用于提高數(shù)據(jù)庫可用性的新技術(shù)。數(shù)據(jù)庫鏡像將事務(wù)日志記錄直接從一臺服務(wù)器傳輸?shù)搅硪慌_服務(wù)器，并且能夠在出現(xiàn)故障時快速轉(zhuǎn)移到備用服務(wù)器?？梢跃帉懣蛻舳顺绦蜃詣又囟ㄏ蜻B接信息，這樣一旦出現(xiàn)故障轉(zhuǎn)移就可以自動連接到備用服務(wù)器和數(shù)據(jù)庫。

自動進(jìn)行故障轉(zhuǎn)移并且使數(shù)據(jù)損失最小化通常包括昂貴的硬件和復(fù)雜的軟件。但是，數(shù)據(jù)庫鏡像可以在不丟失已提交數(shù)據(jù)的前提下進(jìn)行快速故障轉(zhuǎn)移，無須專門的硬件，并且易于配置和管理。

數(shù)據(jù)庫鏡像介紹

在數(shù)據(jù)庫鏡像中，一臺SQL Server 2005實(shí)例連續(xù)不斷的將數(shù)據(jù)庫事務(wù)日志發(fā)送到另一臺備用SQL Server實(shí)例的數(shù)據(jù)庫副本中。發(fā)送方的數(shù)據(jù)庫和服務(wù)器擔(dān)當(dāng)主角色，而接收方的數(shù)據(jù)庫和服務(wù)器擔(dān)當(dāng)鏡像角色。主服務(wù)器和鏡像服務(wù)器必須是獨(dú)立的SQL Server 2005實(shí)例。

在所有SQL Server數(shù)據(jù)庫中，在對真正的數(shù)據(jù)頁面進(jìn)行修改之前，數(shù)據(jù)改變首先都記錄在事務(wù)日志中。事務(wù)日志記錄先被放置在內(nèi)存中的數(shù)據(jù)庫日志緩沖區(qū)中，然后盡快地輸出到磁盤（或者被硬化）。在數(shù)據(jù)庫鏡像中，當(dāng)主服務(wù)器將主數(shù)據(jù)庫的日志緩沖區(qū)寫入磁盤時，也同時將這些日志記錄塊發(fā)送到鏡像實(shí)例。

當(dāng)鏡像服務(wù)器接收到日志記錄塊后，首先將日志記錄放入鏡像數(shù)據(jù)庫的日志緩沖區(qū)，然后盡快地將它們硬化到磁盤。稍后鏡像服務(wù)器會重新執(zhí)行那些日志記錄。由于鏡像數(shù)據(jù)庫重新應(yīng)用了主數(shù)據(jù)庫的事務(wù)日志記錄，因此復(fù)制了發(fā)生在主數(shù)據(jù)庫上的數(shù)據(jù)改變。

主服務(wù)器和鏡像服務(wù)器將對方視為數(shù)據(jù)庫鏡像會話中的伙伴。數(shù)據(jù)庫鏡像會話包含了鏡像伙伴服務(wù)器之間的關(guān)系。一臺給定的伙伴服務(wù)器可以同時承擔(dān)某個數(shù)據(jù)庫的主角色和另一個數(shù)據(jù)庫的鏡像角色。

除了兩臺伙伴服務(wù)器（主服務(wù)器和鏡像服務(wù)器），一個數(shù)據(jù)庫會話中可能還包含第三臺可選服務(wù)器，叫做見證服務(wù)器。見證服務(wù)器的角色就是啟動自動故障轉(zhuǎn)移。當(dāng)數(shù)據(jù)庫鏡像用于高可用性時，如果主服務(wù)器突然失敗了，如果鏡像服務(wù)器通過見證服務(wù)器確認(rèn)了主服務(wù)器的失敗，那么它就自動承擔(dān)主服務(wù)器角色，并且在幾秒鐘之內(nèi)就可以向用戶提供數(shù)據(jù)庫服務(wù)。

數(shù)據(jù)庫鏡像中需要注意的一些重要事項(xiàng)：

◆主數(shù)據(jù)庫必須為FULL還原模型。由于bulk-logged操作而導(dǎo)致的日志記錄無法發(fā)送到鏡像數(shù)據(jù)庫。
◆初始化鏡像數(shù)據(jù)庫必須首先使用NORECOVERY還原主數(shù)據(jù)庫，然后再按順序還原著數(shù)據(jù)庫事務(wù)日志備份。
◆鏡像數(shù)據(jù)庫和主數(shù)據(jù)庫名稱必須一致。
◆由于鏡像數(shù)據(jù)庫處于recovering狀態(tài)，因此不能直接訪問。通過在鏡像數(shù)據(jù)庫上創(chuàng)建數(shù)據(jù)庫快照可以間接讀取某一個時刻點(diǎn)的鏡像數(shù)據(jù)庫。（參閱該白皮書后面“數(shù)據(jù)庫鏡像和數(shù)據(jù)庫快照”部分）

注意：要想獲取更多與數(shù)據(jù)庫鏡像術(shù)語有關(guān)的信息，請參閱SQL Server 2005 Books Online中關(guān)于“Overview of Database Mirroring”。

操作模式

數(shù)據(jù)庫鏡像會話有三種可能的操作模式。根據(jù)事務(wù)安全性的設(shè)置以及鏡像會話中是否需要見證服務(wù)器來決定精確的操作模式。

表1：數(shù)據(jù)庫鏡像操作模式

如果safety設(shè)置為FULL，那么通過同步方式傳輸數(shù)據(jù)，并且需要一臺鏡像服務(wù)器才能提供數(shù)據(jù)庫服務(wù)。quorum投票表決要求至少兩臺服務(wù)器的參與才能夠決定兩個伙伴服務(wù)器各自承擔(dān)什么角色，主角色還是鏡像角色。

為了更深入研究這三種操作模式，首先來更進(jìn)一步研究一下事務(wù)安全性和quorum的角色。

事務(wù)安全性

If 事務(wù)安全性（或者'safety'）設(shè)置為FULL，那么主服務(wù)器和鏡像服務(wù)器工作在同步傳輸模式下。當(dāng)主服務(wù)器硬化其主數(shù)據(jù)庫日志記錄到磁盤時，也同時將日志發(fā)送到鏡像服務(wù)器。然后主服務(wù)器等待鏡像服務(wù)器的回答。鏡像服務(wù)器將那些相同的日志記錄硬化到鏡像日志所在磁盤后，對主服務(wù)器進(jìn)行答復(fù)。當(dāng)safety設(shè)置為OFF時，主服務(wù)器不會等待來自服務(wù)器的確認(rèn)，因此主數(shù)據(jù)庫和鏡像數(shù)據(jù)庫可能不是完全同步的（也就是，鏡像可能滯后于主數(shù)據(jù)庫）。

同步傳輸方式保證鏡像數(shù)據(jù)庫事務(wù)日志中所有事務(wù)與主數(shù)據(jù)庫事務(wù)日志中的事務(wù)同步，因此可視為事務(wù)是安全傳輸?shù)?。要將safety設(shè)置為FULL，使用

ALTER DATABASE [] SET SAFETY FULL;

當(dāng)safety設(shè)置為OFF，主服務(wù)器和鏡像服務(wù)器之間的通信是異步的。主服務(wù)器不會等待鏡像服務(wù)器已將事務(wù)記錄硬化的確認(rèn)信息。鏡像服務(wù)器通過盡快記錄事務(wù)日志的來試圖保持與主服務(wù)器同步，但是如果主服務(wù)器突然失敗同時強(qiáng)制鏡像服務(wù)器提供服務(wù)，那么某些事務(wù)還是有可能丟失（參閱SQL Server Books中的'Forced Service'）。

Quorum和見證服務(wù)器

當(dāng)safety設(shè)置為FULL，數(shù)據(jù)庫鏡像需要quorum才能提供數(shù)據(jù)庫服務(wù)。quorum是在同步數(shù)據(jù)庫鏡像會話中要求的所有連接起來的服務(wù)器之間的最小關(guān)系。由于一個quorum至少需要兩臺服務(wù)器，因此當(dāng)safety為FULL時，主服務(wù)器必須和其他某至少一臺服務(wù)器組成quorum才能夠提供數(shù)據(jù)庫服務(wù)。

見證服務(wù)器幫助主服務(wù)器或者鏡像服務(wù)器組成quorum。如果存在見證服務(wù)器，那么主數(shù)據(jù)庫或者鏡像數(shù)據(jù)庫失敗時，其余兩臺服務(wù)器還可以組成quorum。如果主服務(wù)器無法看到鏡像服務(wù)器，那么它可以和見證服務(wù)器組成quorum，并保持提供數(shù)據(jù)庫服務(wù)。類似地，如果鏡像服務(wù)器和見證服務(wù)器看不到主服務(wù)器，那么這兩臺服務(wù)器可以組成quorum，鏡像服務(wù)器擔(dān)當(dāng)新主服務(wù)器的角色。

見證服務(wù)器失敗不被視為數(shù)據(jù)庫鏡像繪畫中的單點(diǎn)失敗。因?yàn)槿绻娮C服務(wù)器失敗了，那么主服務(wù)器和鏡像服務(wù)器還可以組成quorum（更多信息請參閱SQL Server Books Online中的“Quorum in Database Mirroring Sessions”主題）。

高可用操作模式

高可用操作模式支持最大程度的數(shù)據(jù)庫可用性，如果主數(shù)據(jù)庫失敗將自動轉(zhuǎn)移到經(jīng)銷數(shù)據(jù)庫。它要求將safety設(shè)置為FULL并且定義一臺見證服務(wù)器作為數(shù)據(jù)庫鏡像會話中的一員。

高可用操作模式最適合于那些服務(wù)器之間具有高速且可靠的通信線路，同時要求在單一數(shù)據(jù)庫上實(shí)現(xiàn)自動故障轉(zhuǎn)移的場景。當(dāng)safety為FULL時，主服務(wù)器必須短暫等待來自鏡像服務(wù)器的回答，主服務(wù)器性能也因此受到鏡像服務(wù)器能力的影響。由于單數(shù)據(jù)庫失敗將導(dǎo)致自動故障轉(zhuǎn)移，因此如果有多數(shù)據(jù)庫應(yīng)用程序，那么就應(yīng)該考慮其他操作模式（參閱該白皮書中實(shí)現(xiàn)數(shù)據(jù)庫鏡像部分介紹的“多數(shù)據(jù)庫問題”）

高可用模式中數(shù)據(jù)庫鏡像是自監(jiān)視的。如果主數(shù)據(jù)庫突然不可用，或者主服務(wù)器停機(jī)，那么見證服務(wù)器和鏡像服務(wù)器將組成quorum，然后鏡像的SQL Server將進(jìn)行自動故障轉(zhuǎn)移。此時，競相服務(wù)器實(shí)例將其角色轉(zhuǎn)換為新主服務(wù)器并恢復(fù)數(shù)據(jù)庫。由于鏡像數(shù)據(jù)庫已經(jīng)重新執(zhí)行了主數(shù)據(jù)庫的事務(wù)日志并且其事務(wù)日志也與主數(shù)據(jù)庫同步，因此鏡像服務(wù)器可以快速提供數(shù)據(jù)庫服務(wù)。

此外，SQL Server 2005可以在數(shù)據(jù)庫恢復(fù)前就向用戶提供數(shù)據(jù)庫服務(wù)。SQL Server數(shù)據(jù)庫恢復(fù)包括三個階段：分析階段、redo階段、以及最后的undo階段。在SQL Server 2005中，只要redo階段完成，新恢復(fù)的數(shù)據(jù)庫就可以讓用戶訪問。因此如果數(shù)據(jù)庫鏡像故障轉(zhuǎn)移發(fā)生，新恢復(fù)的主數(shù)據(jù)庫只要完成了redo階段就可以向用戶提供服務(wù)了。因?yàn)殓R像數(shù)據(jù)庫自始至終都在重新執(zhí)行事務(wù)日志記錄，因此所有鏡像服務(wù)器只須完成redo過程就可以了，通常幾秒鐘就可以完成。

高保護(hù)操作模式

高保護(hù)操作模式中事務(wù)安全性設(shè)置為FULL，但是鏡像會話中沒有見證服務(wù)器。主服務(wù)器必須組成quorum，可是沒有見證服務(wù)器，因此只能和鏡像服務(wù)器配合在一起。這種模式下由于沒有見證服務(wù)器來擔(dān)當(dāng)平局決勝的角色，因此只能手動完成故障轉(zhuǎn)移。行自動故障轉(zhuǎn)移是不可能的，因?yàn)槿绻鞣?wù)器失敗，鏡像服務(wù)器沒有見證服務(wù)器來組成quorum。

safety設(shè)置為FULL，如果主服務(wù)器突然間失去了和鏡像服務(wù)器的quorum，那么鏡像服務(wù)器必須使其數(shù)據(jù)庫停止服務(wù)。不推薦使用高保護(hù)模式的數(shù)據(jù)庫鏡像配置，除非在高可用模式下必須臨時移除見證服務(wù)器時，可以使用該模式作為一種臨時過渡。

高性能操作模式

在高性能操作模式下，事務(wù)安全性設(shè)置為OFF，以異步方式傳輸日志記錄。主服務(wù)器無須等待鏡像服務(wù)器所有日志記錄已被硬化的確認(rèn)信息。鏡像服務(wù)器盡自己最大可能保持與主服務(wù)器數(shù)據(jù)的一致，但不能保證在任何時刻來自主數(shù)據(jù)庫的所有最新事務(wù)日志記錄都能夠被硬化到鏡像數(shù)據(jù)庫的事務(wù)日志中。

在高性能模式下，見證服務(wù)器不承擔(dān)任何角色，也不需要quorum。因此高性能模式無法啟用自動和手動的故障轉(zhuǎn)移。唯一允許的故障轉(zhuǎn)移方式就是forced service ，它同樣也是一種手工操作：

ALTER DATABASESET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

forced service故障轉(zhuǎn)移導(dǎo)致立刻恢復(fù)鏡像數(shù)據(jù)庫。如果某些主數(shù)據(jù)庫的事務(wù)日志記錄還沒有被鏡像服務(wù)器接收，那么恢復(fù)鏡像數(shù)據(jù)庫將導(dǎo)致潛在的數(shù)據(jù)丟失。高性能模式特別適合于遠(yuǎn)距離的數(shù)據(jù)傳輸（換句話說，用于遠(yuǎn)程站點(diǎn)的災(zāi)難恢復(fù)），或者對那些活動頻繁且可以容忍某種程度數(shù)據(jù)丟失的數(shù)據(jù)庫進(jìn)行鏡像。

數(shù)據(jù)庫快照和數(shù)據(jù)庫鏡像

由于鏡像數(shù)據(jù)庫處于recovering狀態(tài)，因此不可訪問也不可讀。在SQL Server 2005企業(yè)版和開發(fā)人員版中可以創(chuàng)建數(shù)據(jù)庫快照來讀取某個時點(diǎn)的鏡像數(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ù)庫當(dāng)時的數(shù)據(jù)。（更多信息請參閱SQL Server Books Online中"Using Database Snapshots with Database Mirroring"主題。）

由于數(shù)據(jù)庫快照確實(shí)增加了鏡像服務(wù)器的負(fù)擔(dān)，因此需要當(dāng)心它們對數(shù)據(jù)庫鏡像性能可能造成的影響。由于只能鏡像到一個數(shù)據(jù)庫，因此如果需要將數(shù)據(jù)擴(kuò)充到多個只讀的報(bào)表服務(wù)器上，那么事務(wù)復(fù)制是更好的選擇。（更新信息請閱讀后面實(shí)現(xiàn)數(shù)據(jù)庫鏡像部分的“數(shù)據(jù)庫鏡像和復(fù)制”）

客戶端重定向

在SQL Server 2005中，如果使用ADO.NET或者SQL Native Client連接配置了鏡像的數(shù)據(jù)庫，那么應(yīng)用程序就可以利用驅(qū)動程序的能力在發(fā)生數(shù)據(jù)庫鏡像故障轉(zhuǎn)移時自動重定向數(shù)據(jù)庫連接。必須在連接字符串中指定原始主服務(wù)器和數(shù)據(jù)庫名稱，以及可選的故障轉(zhuǎn)移伙伴服務(wù)器名稱。

連接字符串的寫法有許多種，以下只給出一個例子，指定server A作為主服務(wù)器，server B作為鏡像服務(wù)器，AdventureWorks作為數(shù)據(jù)庫名稱：

"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;　　Integrated Security=True;"

如果連接到原始主服務(wù)器失敗，那么就使用連接字符串中的failover partner作為備用服務(wù)器名稱。如果連接到原始主服務(wù)器成功，那么就不使用連接字符串中的failover partner名稱，但是會從主服務(wù)器上查詢其故障轉(zhuǎn)移伙伴的名稱并將結(jié)果存放在客戶端緩存中。

假設(shè)客戶端成功連接到主服務(wù)器，然后一個數(shù)據(jù)庫鏡像故障轉(zhuǎn)移發(fā)生（自動地、手動的、forced）。當(dāng)下一次應(yīng)用程序嘗試使用連接時，ADO.NET或者SQL Native Client驅(qū)動程序?qū)z測到與舊主服務(wù)器的連接已經(jīng)失敗，然后自動重新連接由failover partner名稱指定的新主服務(wù)器。如果連接成功并且新的鏡像服務(wù)器存在，那么驅(qū)動程序從新主服務(wù)器處獲取新的故障轉(zhuǎn)移伙伴名稱并將其存放在客戶端緩存中。如果無法連接到備用服務(wù)器，那么驅(qū)動程序?qū)⒔惶鎳L試與每個服務(wù)器的連接直道連接超時。

使用內(nèi)置在ADO.NET和SQL Native Client驅(qū)動程序中的數(shù)據(jù)庫鏡像支持的最大優(yōu)點(diǎn)就是無須重新編寫應(yīng)用程序，或者在應(yīng)用程序中編寫特殊代碼來處理數(shù)據(jù)庫鏡像的故障轉(zhuǎn)移。

如果不使用ADO.NET或者SQL Native Client自動進(jìn)行重定向，那么也可以使用其他技術(shù)使應(yīng)用程序進(jìn)行故障轉(zhuǎn)移。例如，如果客戶端連接到一臺虛擬服務(wù)器，可以使用Network Load Balancing手動重定向一臺服務(wù)器到另一臺服務(wù)器的連接。還可以編程實(shí)現(xiàn)自己的重定向代碼和連接重試邏輯。

但是，所有這些用于協(xié)調(diào)客戶端重定向和數(shù)據(jù)庫鏡像的技術(shù)都有一些重要限制。數(shù)據(jù)庫鏡像只能工作在數(shù)據(jù)庫級別，而不是服務(wù)器級別。如果應(yīng)用程序查詢一臺服務(wù)器上的多個數(shù)據(jù)庫，或者使用完全限定對象名稱進(jìn)行跨數(shù)據(jù)庫查詢，那么就需要多加小心了。如果多個數(shù)據(jù)庫位于一臺服務(wù)器并且都配置了和備用服務(wù)器的鏡像，就有可能出現(xiàn)其中一個數(shù)據(jù)庫故障轉(zhuǎn)移到備用服務(wù)器而其他數(shù)據(jù)庫依然在原始服務(wù)器的情況。如果是那樣的話，可能就要求每個數(shù)據(jù)庫查詢都使用一個單獨(dú)的連接，這樣將無法進(jìn)行跨數(shù)據(jù)庫查詢，因?yàn)樵阽R像服務(wù)器上只有一個數(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設(shè)置為OFF （異步數(shù)據(jù)傳輸）；
◆數(shù)據(jù)庫快照；
◆使用多線程在鏡像數(shù)據(jù)庫上應(yīng)用事務(wù)日志（并行REDO）。

SQL Express和工作組版本可以作為數(shù)據(jù)庫鏡像的見證服務(wù)器，但不能作為伙伴服務(wù)器。

數(shù)據(jù)庫鏡像動態(tài)

要深入理解SQL SERVER 2005 數(shù)據(jù)庫鏡像，了解數(shù)據(jù)庫鏡像會話如何變化將對您大有幫助。這一部分內(nèi)容包括數(shù)據(jù)庫鏡像會話中不同的數(shù)據(jù)庫狀態(tài)、同步和異步的日志記錄傳輸機(jī)制、以及故障轉(zhuǎn)移次序。

配置和安全性

一旦確定了主服務(wù)器、鏡像服務(wù)器、以及可選的見證服務(wù)器，設(shè)置數(shù)據(jù)庫鏡像主要包括三個步驟。

1.必須備份數(shù)據(jù)庫并使用norecovery在鏡像數(shù)據(jù)庫上還原該數(shù)據(jù)庫。

注意：在備份數(shù)據(jù)庫并還原到鏡像數(shù)據(jù)庫之前，主數(shù)據(jù)庫必須設(shè)置為FULL還原模型。如果必須在事務(wù)日志中傳輸Bulk-logged記錄，那么數(shù)據(jù)庫鏡像將無能為力。鏡像服務(wù)器必須有足夠的磁盤空間以允許和主數(shù)據(jù)庫同樣的文件增長。如果希望在鏡像服務(wù)器中創(chuàng)建數(shù)據(jù)庫快照，那么還必須為快照提供額外的磁盤空間。

如果備份、拷貝、以及還原數(shù)據(jù)庫耗費(fèi)了相當(dāng)長的時間，那么可能需要現(xiàn)在原始數(shù)據(jù)庫上進(jìn)行一次事務(wù)日志備份來控制日志的大小。但是，如果通過日志到日志的備份清理了日志記錄，數(shù)據(jù)庫鏡像將無法初始化。因此必須在初始化數(shù)據(jù)庫鏡像之前在鏡像數(shù)據(jù)庫上按順序恢復(fù)那些事務(wù)日志記錄備份。

2.參與數(shù)據(jù)庫鏡像會話的服務(wù)器必須彼此信任。對于本地通信而言，例如一個域內(nèi)的通信，信任意味著SQL Server實(shí)例登陸賬號必須有權(quán)限連接到其他鏡像服務(wù)器，也包括endpoints。首先在每個服務(wù)器上使用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ù)鏡像證書的要求都可以滿足。確認(rèn)在CREATE CERTIFICATE語句中將證書標(biāo)記為ACTIVE FOR BEGIN_DIALOG。

3.下一步是創(chuàng)建數(shù)據(jù)庫鏡像的endpoints。創(chuàng)建endpoints要求您必須具有SQL Server instance的系統(tǒng)管理員權(quán)限。必須在每臺服務(wù)器上創(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命令之前，提示您輸入正確的計(jì)算機(jī)名稱和端口號，以及可選的登陸帳號。（參閱SQL Server Books Online中 “How to: Create a Mirroring Endpoint (Transact-SQL)”） 

如果在域中設(shè)置數(shù)據(jù)庫鏡像，并且所有的SQL Server實(shí)例使用相同的服務(wù)帳號和密碼，那么就不需要在每個服務(wù)器上創(chuàng)建登陸帳號。類似的，如果在工作組中，并且所有的SQL Server實(shí)例使用相同的服務(wù)帳號和密碼，也不需要在每個服務(wù)器上創(chuàng)建登陸帳號。設(shè)置endpoints時將Configure Database Mirroring Security向?qū)е械牡顷憥ぬ柋Ａ魹榭站涂梢粤恕?/p>

每個數(shù)據(jù)庫endpoint必須指定服務(wù)器上一個唯一的端口號。如果使用不同服務(wù)器上的SQL Server實(shí)例，那么這些端口號可以是相同的。Configure Database Mirroring Security向?qū)詣咏ㄗh您使用5022作為端口號。如果任何SQL Server實(shí)例運(yùn)行在同一臺服務(wù)器上，那么每個實(shí)例的端口號必須唯一，所有的鏡像端口號也必須唯一。

假設(shè)在高可用鏡像會話中有三臺服務(wù)器。Server A是主服務(wù)器，server B是鏡像服務(wù)器，server W作為見證服務(wù)器。對于server A而言，下面的命令在5022端口創(chuàng)建endpoint：

CREATE ENDPOINT [Mirroring]  AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);

注意：角色被指定為PARTNER，這樣該服務(wù)器可以擔(dān)當(dāng)數(shù)據(jù)庫鏡像的主服務(wù)器或者鏡像服務(wù)器。在server B上執(zhí)行相同的命令。因?yàn)閟erver B是獨(dú)立物理服務(wù)器上的SQL Server實(shí)例，因此可以使用相同的端口號。然后對于server W，使用

CREATE ENDPOINT [Mirroring]  AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);

注意：對于server W，角色被指定為WITNESS。

默認(rèn)不啟動endpoint。接下來在每個服務(wù)器上使用下面的命令來啟動endpoint：

ALTER ENDPOINT [Mirroring] STATE = STARTED;

可以在CREATE ENDPOINT命令中插入可選的STATE選項(xiàng)。在每臺服務(wù)器上反復(fù)執(zhí)行該選項(xiàng)。

使用CREATE ENDPOINT創(chuàng)建endpoint時，可以通過協(xié)議特定的參數(shù)根據(jù)IP地址來限制對endpoint的訪問。結(jié)合RESTRICT_IP with ALL選項(xiàng)和EXCEPT_IP加上那些允許訪問的特殊IP地址可以對一組IP地址作限制。（參閱SQL Server Books Online中的See “CREATE ENDPOINT”）。

查詢每個服務(wù)器的sys.database_mirroring_endpoints目錄視圖來檢查數(shù)據(jù)庫鏡像的endpoints：

SELECT *FROM sys.database_mirroring_endpoints;

4. 要啟動數(shù)據(jù)庫鏡像，接下來指定指定伙伴服務(wù)器和見證服務(wù)器。必須具有數(shù)據(jù)庫管理員權(quán)限才可以啟動和管理一個給定的數(shù)據(jù)庫鏡像會話。在server A，即打算作主服務(wù)器的機(jī)器上設(shè)置主數(shù)據(jù)庫角色以及伙伴（鏡像）服務(wù)器：

-- Specify the partner from the principal serverALTER DATABASE [AdventureWorks] SET PARTNER =N'TCP://B.corp.mycompany.com:5022';

鏡像伙伴的名稱必須為完全限定計(jì)算機(jī)名。決定機(jī)器的完全限定名稱可能有些難，不過Configure Database Mirroring Security向?qū)诮ndpoint時自動找出它們。

從命令行提示中運(yùn)行下面的命令也可以找出一臺機(jī)器的完全限定名稱：

IPCONFIG /ALL

將"Host Name"和"Primary DNS Suffix"連接到一起。如果您看到的信息類似于：

Host Name . . . . . . . . . . . . : A
Primary Dns Suffix  . . . . . . . : corp.mycompany.com

那么計(jì)算機(jī)名就是A.corp.mycompany.com。加上'TCP://'前綴然后再附加':<端口號>' ，就是鏡像伙伴名稱。

在鏡像服務(wù)器上重復(fù)相同的命令，但是要指定主服務(wù)器名稱：

-- Specify the partner from the mirror serverALTER DATABASE [AdventureWorks] SET PARTNER =N'TCP://A.corp.mycompany.com:5022';

接下來在主服務(wù)器上指定見證服務(wù)器：

-- Specify the witness from the principal serverALTER DATABASE [AdventureWorks] SET WITNESS = N'TCP://W.corp.mycompany.com:5026';

執(zhí)行完CREATE ENDPOINT后見證服務(wù)器上就不需要執(zhí)行其他命令了。

最后，在主服務(wù)器上指定會話的safety級別：

-- Set the safety level from the principal serverALTER DATABASE [AdventureWorks] SET SAFETY FULL;

此時，鏡像將自動啟動，然后主服務(wù)器和鏡像服務(wù)器將進(jìn)行同步。

可以調(diào)整判定鏡像伙伴是否故障的超時值，使用ALTER DATABASE命令的TIMEOUT參數(shù)。例如將TIMEOUT值改為20秒（默認(rèn)是10），在主服務(wù)器上執(zhí)行：

-- Issue from the principal serverALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;

最后，在主服務(wù)器上使用ALTER DATABASE和REDO_QUEUE選項(xiàng)可以鏡像服務(wù)器上redo隊(duì)列的大小。下面的查詢將鏡像服務(wù)器的redo隊(duì)列設(shè)置為100兆：

-- Issue from the principal serverALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;

只要指定了鏡像伙伴，鏡像將立即啟動。

數(shù)據(jù)庫鏡像目錄視圖

數(shù)據(jù)庫鏡像會話包括組成伙伴的服務(wù)器，可能還有見證服務(wù)器之間的關(guān)聯(lián)。每臺參與鏡像的服務(wù)器都保存關(guān)于鏡像會話和當(dāng)前數(shù)據(jù)庫狀態(tài)的元數(shù)據(jù)?？梢栽谥鞣?wù)器和鏡像服務(wù)器上通過查詢sys.database_mirroring目錄視圖來檢查會話狀態(tài)。使用另一個視圖sys.database_mirroring_witnesses可是返回見證服務(wù)器的信息（要想獲得兩個目錄視圖中所有列的更完整的描述，請參閱  SQL Server Books Online的“sys.database_mirroring" and "sys.database_mirrroing_witnesses”）。

了解數(shù)據(jù)庫鏡像會話如何工作以及數(shù)據(jù)庫處于何種狀態(tài)的一種不錯的方法就是檢查目錄視圖里的數(shù)據(jù)。我們從高可用配置開始（safety設(shè)置為FULL，有一臺見證服務(wù)器）。下面的查詢返回了主服務(wù)器或者見證服務(wù)器上數(shù)據(jù)庫鏡像會話的基本描述信息。

SELECT       DB_NAME(database_id) AS 'DatabaseName' , mirroring_role_desc     , mirroring_safety_level_desc    , mirroring_state_desc    , mirroring_safety_sequence    , mirroring_role_sequence    , mirroring_partner_instance    , mirroring_witness_name    , mirroring_witness_state_desc    , mirroring_failover_lsnFROM sys.database_mirroringWHERE mirroring_guid IS NOT NULL;

在見證服務(wù)器上運(yùn)行下面類似的查詢，可以返回見證服務(wù)器的相關(guān)描述信息。

SELECT       Database_name    , safety_level_desc    , safety_sequence_number    , role_sequence_number    , is_suspended    , is_suspended_sequence_number    , principal_server_name    , mirror_server_nameFROM sys.database_mirroring_witnesses;

現(xiàn)在來比較在一個典型的數(shù)據(jù)庫鏡像會話中兩個查詢的輸出結(jié)果。假設(shè)已經(jīng)設(shè)置了server A到 server B的數(shù)據(jù)庫鏡像，使用safety為FULL。（設(shè)置以下配置的示例代碼，請參閱后面的實(shí)現(xiàn)數(shù)據(jù)庫鏡像“配置和安全性”）見證服務(wù)器是server W，對AdventureWorks數(shù)據(jù)庫做鏡像。表3顯示了兩個查詢的輸出結(jié)果：

表3：高可用鏡像會話，兩個伙伴服務(wù)器sys.database_mirroring輸出結(jié)果

注意數(shù)據(jù)庫鏡像會話中的每個伙伴保存的所有元數(shù)據(jù)從另一個伙伴的角度來看是完全相同的。每個伙伴保存其數(shù)據(jù)庫名稱、整個會話的safety設(shè)置、數(shù)據(jù)庫的鏡像狀態(tài)、以及兩個序列計(jì)數(shù)器。

◆mirroring_safety_sequence計(jì)數(shù)器保存在兩個伙伴上，只要safety設(shè)置改變時將增加該計(jì)數(shù)器的值。
◆mirroring_role_sequence計(jì)數(shù)器保存在兩個伙伴以及見證服務(wù)器上，只要發(fā)生故障轉(zhuǎn)移就增加該計(jì)數(shù)器的值。

伙伴數(shù)據(jù)庫的狀態(tài)以及見證服務(wù)器的狀態(tài)都保存在每個伙伴服務(wù)器上：

◆mirroring_state_desc顯示了會話中伙伴數(shù)據(jù)庫的狀態(tài)。
◆mirroring_witness_state_desc顯示了會話中見證服務(wù)器的狀態(tài)。

最后，每個伙伴都包含一個mirroring_failover_lsn。LSN是一個日志序列號，用于唯一標(biāo)識每條事務(wù)日志記錄。鏡像伙伴將上次硬化的最后一組日志記錄的最高LSN +1保存起來。在上表中，由于主數(shù)據(jù)庫中只有為數(shù)不多的活動，因此 鏡像轉(zhuǎn)移故障的lsn和主服務(wù)器以及見證服務(wù)器的lsn相同。當(dāng)傳輸大量數(shù)據(jù)時，可能就會發(fā)現(xiàn)主服務(wù)器的lsn值大于鏡像服務(wù)器的值，因?yàn)殓R像服務(wù)器的運(yùn)行有些滯后。

現(xiàn)在比較一下在見證服務(wù)器上找到的元數(shù)據(jù)。下表顯示了來自見證服務(wù)器元數(shù)據(jù)的一些可比較信息：

表4：見證服務(wù)器上sys.database_mirroring_witnesses的輸出，關(guān)聯(lián)了伙伴的元數(shù)據(jù)

注意見證服務(wù)器的元數(shù)據(jù)包含了safety的描述、safety的序列號、以及角色序列號。見證服務(wù)器還保存了會話是否被掛起的信息，以及主服務(wù)器和鏡像服務(wù)器的名稱。注意見證服務(wù)器的目錄視圖并沒有報(bào)告鏡像故障轉(zhuǎn)移的lsn，而且也不保存數(shù)據(jù)庫狀態(tài)。

數(shù)據(jù)庫鏡像所需的全部元數(shù)據(jù)（特別是故障轉(zhuǎn)移lsn和伙伴服務(wù)器名稱）都保存在鏡像伙伴上。見證服務(wù)器只保存在高可用模式下作為見證者必須保存的那些數(shù)據(jù)，特別是用于跟蹤會話中角色轉(zhuǎn)換數(shù)目的角色序列號。該計(jì)數(shù)器用于幫助判定何時一臺主服務(wù)器可以做角色轉(zhuǎn)換。相關(guān)知識會在下一部分介紹的場景中進(jìn)行闡述。

數(shù)據(jù)庫鏡像狀態(tài)和狀態(tài)轉(zhuǎn)換

在數(shù)據(jù)庫鏡像會話過程中，每臺伙伴服務(wù)器都對數(shù)據(jù)庫狀態(tài)作記錄和保存，可以通過sys.database_mirroring目錄視圖來查看。mirroring_state列返回狀態(tài)號，mirroring_state_desc列返回狀態(tài)的描述性名稱。（要想獲取關(guān)于數(shù)據(jù)庫狀態(tài)號和描述性名稱的完整列表，請看SQL Server Books Online中的“sys.database_mirroring”）。同樣的目錄視圖還用于報(bào)告見證服務(wù)器的狀態(tài)信息。

除了為每個數(shù)據(jù)庫報(bào)告狀態(tài)信息以外，還有三個重要術(shù)語用來對數(shù)據(jù)庫鏡像中的服務(wù)器和數(shù)據(jù)庫進(jìn)行描述。

1.主服務(wù)器上的數(shù)據(jù)是exposed ，當(dāng)它進(jìn)行事務(wù)處理但是沒有日志數(shù)據(jù)被發(fā)送到鏡像服務(wù)器。
2.不能提供數(shù)據(jù)庫服務(wù) – 當(dāng)主服務(wù)器不允許任何用戶連接到數(shù)據(jù)庫，不允許任何事務(wù)處理。
3.服務(wù)器被孤立 – 當(dāng)它無法聯(lián)系數(shù)據(jù)庫鏡像會話中任何其他服務(wù)器，同時別人也聯(lián)系不上它。

當(dāng)主數(shù)據(jù)庫是exposed，它可以接收用戶連接和進(jìn)行事務(wù)處理，但是沒有日志記錄被發(fā)送到鏡像數(shù)據(jù)庫。因此如果主數(shù)據(jù)庫失敗了，那么鏡像數(shù)據(jù)庫不包含任何自主數(shù)據(jù)庫進(jìn)入exposed狀態(tài)后主服務(wù)器上發(fā)生的事務(wù)。同樣的，也不可以清理主數(shù)據(jù)庫的事務(wù)日志，這導(dǎo)致日志文件的無限增長。

當(dāng)safety設(shè)置為FULL時，如果主服務(wù)器無法和其他服務(wù)器組成quorum，它將停止提供數(shù)據(jù)庫服務(wù)。主服務(wù)器將不允許主數(shù)據(jù)庫上的用戶連接和事務(wù)，并斷開所有當(dāng)前的用戶。只要主服務(wù)器能再次組成quorum，就立刻重新提供數(shù)據(jù)庫服務(wù)。

一臺服務(wù)器可能運(yùn)轉(zhuǎn)正常但是它和數(shù)據(jù)庫鏡下會話中的其他服務(wù)器之間的通信連路中斷了。如果那樣的話，我們稱服務(wù)器被孤立了。當(dāng)safety為FULL時，如果主服務(wù)器被孤立，那么它將無法提供數(shù)據(jù)庫服務(wù)，因?yàn)闀捴袥]有其他服務(wù)器可與之共同組成quorum。

現(xiàn)在來關(guān)注一下數(shù)據(jù)庫鏡像狀態(tài)，從主服務(wù)器和數(shù)據(jù)庫開始。

主服務(wù)器數(shù)據(jù)庫狀態(tài)

當(dāng)safety設(shè)置為FULL，主數(shù)據(jù)庫的正常操作狀態(tài)時SYNCHRONIZED狀態(tài)。當(dāng)safety設(shè)置為OFF，主數(shù)據(jù)庫的正常操作狀態(tài)是SYNCHRONZING狀態(tài)。

◆如果safety設(shè)置為FULL，主數(shù)據(jù)庫的起始狀態(tài)始終是SYNCHRONIZING，當(dāng)主數(shù)據(jù)庫和鏡像數(shù)據(jù)庫事務(wù)日志同步后，數(shù)據(jù)庫狀態(tài)就轉(zhuǎn)換成SYNCHRONIZED，
◆如果safety設(shè)置為FULL并且主服務(wù)器斷開了和見證服務(wù)器的連接但依然可以進(jìn)行事務(wù)處理，那么數(shù)據(jù)庫狀態(tài)為exposed。
◆如果safety設(shè)置為FULL并且主服務(wù)器無法和其他服務(wù)器組成quorum，那么將無法提供數(shù)據(jù)庫服務(wù)。不允許任何的用戶連接和事務(wù)處理。

下表顯示了主數(shù)據(jù)庫可能的狀態(tài)，以及導(dǎo)致狀態(tài)轉(zhuǎn)換的一些事件。

表5：主數(shù)據(jù)庫狀態(tài)，safety為FULL以及safety為OFF

當(dāng)safety設(shè)置為FULL，主數(shù)據(jù)庫首先進(jìn)入SYNCHRONIZING狀態(tài)，只要和鏡像數(shù)據(jù)庫同步，兩個伙伴都進(jìn)入SYNCHRONIZED狀態(tài)。當(dāng)safety設(shè)置為OFF，伙伴數(shù)據(jù)庫從SYNCHRONIZING狀態(tài)開始并在整個鏡像過程中保持該狀態(tài)。

對于這兩個safety設(shè)置，如果會話被掛起或者出現(xiàn)了鏡像服務(wù)器的redo錯誤，那么主數(shù)據(jù)庫進(jìn)入SUSPENDED狀態(tài)。如果鏡像服務(wù)器不可用，那么主數(shù)據(jù)庫進(jìn)入DISCONNECTED狀態(tài)。

在DISCONNECTED和SUSPENDED狀態(tài)下：

◆當(dāng)safety設(shè)置為FULL，如果主服務(wù)器無法和見證服務(wù)器或者鏡像服務(wù)器自稱quorum，那么主數(shù)據(jù)庫被視為exposed。這意味著主數(shù)據(jù)庫為活動狀態(tài)，支持用戶連接和事務(wù)處理。但是沒有日志記錄被發(fā)送到鏡像數(shù)據(jù)庫。因此如果主數(shù)據(jù)庫失敗了，那么鏡像數(shù)據(jù)庫不包含任何自主數(shù)據(jù)庫進(jìn)入exposed狀態(tài)后主服務(wù)器上發(fā)生的事務(wù)。同樣的，也不可以清理主數(shù)據(jù)庫的事務(wù)日志，這導(dǎo)致日志文件的無限增長。
◆當(dāng)safety設(shè)置為FULL，如果主服務(wù)器無法和其他服務(wù)器組成quorum，它將不能提供數(shù)據(jù)庫服務(wù)。所有用戶將被斷開連接，也不允許新的事務(wù)處理。
◆當(dāng)safety設(shè)置為OFF，朱數(shù)據(jù)庫被視為exposed，因?yàn)闆]有事務(wù)日志記錄被發(fā)送到鏡像。

注意：Management Studio's Object Explorer會在Server樹圖中數(shù)據(jù)庫名稱的旁邊報(bào)告主數(shù)據(jù)庫狀態(tài)。將主數(shù)據(jù)庫的SYNCHRONIZED狀態(tài)報(bào)告為 'Principal, Synchronizing'，DISCONNECTED狀態(tài)報(bào)告為'Principal, Disconnected.'

鏡像數(shù)據(jù)庫狀態(tài)

鏡像數(shù)據(jù)庫具有和主數(shù)據(jù)庫相同的狀態(tài)，但是由于鏡像數(shù)據(jù)庫始終處于nonrecovered狀態(tài)，因此在擔(dān)當(dāng)鏡像角色的時候不能提供數(shù)據(jù)庫服務(wù)。下表顯示了可以導(dǎo)致鏡像服務(wù)器和數(shù)據(jù)庫狀態(tài)改變的一些最常見事件。

表6：鏡像服務(wù)器狀態(tài)，safety為FULL以及safety為OFF

和主數(shù)據(jù)庫一樣，Management Studio's Object Explorer在Server樹的數(shù)據(jù)庫名稱旁邊報(bào)告鏡像數(shù)據(jù)庫狀態(tài)。鏡像數(shù)據(jù)庫的SYNCHRONIZED狀態(tài)報(bào)告為'Mirror, Synchronizing'，DISCONNECTED狀態(tài)報(bào)告為'Mirror, Disconnected.'

見證服務(wù)器狀態(tài)

在sys.database_mirroring目錄視圖中有三種見證服務(wù)器狀態(tài)，CONNECTED、 DISCONNECTED和UNKNOWN。

表7：Witness服務(wù)器狀態(tài)（記錄在伙伴服務(wù)器上）

由于見證服務(wù)器狀態(tài)真正記錄在伙伴服務(wù)器而不是見證服務(wù)器上，因此這些狀態(tài)是從有利于伙伴的角度來設(shè)置的，因此當(dāng)您看到見證服務(wù)器為DISCONNECTED狀態(tài)時，意味著伙伴和見證服務(wù)器斷開了。數(shù)據(jù)庫鏡像啟動后，如果鏡像服務(wù)器無法與主服務(wù)器進(jìn)行初始化，那么見證服務(wù)器進(jìn)入U(xiǎn)NKNOWN狀態(tài)。

傳輸事務(wù)日志記錄

SQL Server主服務(wù)器和鏡像服務(wù)器傳輸消息和日志記錄的次序根據(jù)事務(wù)安全性的設(shè)置而不同。我們先研究同步傳輸，然后再研究異步傳輸。

當(dāng)SQL Server將事務(wù)事件記錄在事務(wù)日志中時，日志記錄被寫入磁盤前暫時存放在日志緩沖區(qū)中。數(shù)據(jù)庫鏡像時，每次日志緩沖區(qū)被輸出到硬盤時（硬化），主服務(wù)器也將相同的日志記錄塊發(fā)送到鏡像服務(wù)器。

1. 當(dāng)safety設(shè)置為FULL，只要SQL Server主服務(wù)器硬化它的日志記錄塊，就同時將相同的日志記錄塊發(fā)送到鏡像服務(wù)器，并認(rèn)為本地的日志I/O和遠(yuǎn)程鏡像服務(wù)器的日志I/O從本質(zhì)上來說是一樣 的。這種傳輸稱為同步的，因?yàn)樵谝粋€事務(wù)提交之前，主服務(wù)器既要等待本地的I/O（硬化）還要等待等待鏡像服務(wù)器有關(guān)完成I/O（硬化）的答復(fù)。

每次主服務(wù)器或者鏡像服務(wù)器硬化日志緩沖區(qū)時，都會將緩沖區(qū)中最高的日志序列號（LSN）+ 1作為mirroring_failover_lsn記錄在元數(shù)據(jù)中。

mirroring_failover_lsn 用于協(xié)商事務(wù)日志最后的保障點(diǎn)，這樣兩個伙伴數(shù)據(jù)庫就可以在初始化時保持同步，在故障轉(zhuǎn)移后也保持同步。

當(dāng)主服務(wù)器發(fā)送日志記錄給鏡像服務(wù)器時，主服務(wù)器上的mirroring_failover_lsn通常會提前一些。鏡像服務(wù)器硬化日志記錄時會記錄其mirroring_failover_lsn，然后回復(fù)主服務(wù)器。但是等主服務(wù)器接收到來自鏡像的確認(rèn)信息時，主服務(wù)器可能已經(jīng)開始硬化新的一組日志記錄了。

表8顯示了主服務(wù)器和鏡像服務(wù)器safety為FULL時的一個事件序列示例。

表8：Safety為FULL （同步傳輸）事件序列的示例

以上事件序列中關(guān)鍵的一點(diǎn)就是：當(dāng) safety設(shè)置為FULL時，主服務(wù)器硬化日志緩沖區(qū)以及將日志緩沖區(qū)中日志記錄的副本發(fā)送到鏡像服務(wù)器，二者是同時進(jìn)行的。然后主服務(wù)器開始等待自己的I/O以及鏡像服務(wù)器的I/O，兩個I/O都完成后才認(rèn)為事務(wù)完成了。當(dāng)主服務(wù)器接收到來自鏡像的答復(fù)后，再開始處理下一次硬化。

當(dāng)safety設(shè)置為FULL時，盡管主服務(wù)器和鏡像服務(wù)器之間協(xié)調(diào)緊密，但是數(shù)據(jù)庫鏡像不是分布式事務(wù)，也不使用兩階段提交協(xié)議。

◆在數(shù)據(jù)庫鏡像中，兩個事務(wù)分別在兩臺服務(wù)器上執(zhí)行，并不是一個跨服務(wù)器的分布式事務(wù)。
◆數(shù)據(jù)庫鏡像不使用伙伴服務(wù)器作為分布式事務(wù)中的資源管理器。
◆數(shù)據(jù)庫鏡像事務(wù)不經(jīng)歷準(zhǔn)備和提交階段。
◆最重要的是，鏡像服務(wù)器上事務(wù)提交失敗不會導(dǎo)致主服務(wù)器上的事務(wù)會滾，這一點(diǎn)與分布式事務(wù)不同。

2. 當(dāng)safety設(shè)置為OFF時，主服務(wù)器不等待來自鏡像服務(wù)器的確認(rèn)消息，因此主服務(wù)器上已提交事務(wù)數(shù)量可能多于鏡像服務(wù)器，如圖9所示：

表9：Safety為OFF （異步傳輸）事件序列的示例

數(shù)據(jù)庫鏡像角色轉(zhuǎn)換

可以從數(shù)據(jù)庫鏡像服務(wù)器或者應(yīng)用程序的角度來思考數(shù)據(jù)庫鏡像故障轉(zhuǎn)移問題。從數(shù)據(jù)庫鏡像服務(wù)器角度，故障轉(zhuǎn)移就是將鏡像服務(wù)器轉(zhuǎn)換為主服務(wù)器，以及使用新恢復(fù)的數(shù)據(jù)庫作為主數(shù)據(jù)庫。故障轉(zhuǎn)移可以是自動的、手動的、或者forced service。

◆自動的 – 只有高可用模式下才會產(chǎn)生（safety設(shè)置為FULL以及見證服務(wù)器的參與）
◆手動的 -  只有高可用和高保護(hù)操作模式下才會產(chǎn)生（safety設(shè)置為FULL），兩個伙伴數(shù)據(jù)庫都是SYNCHRONIZED。
◆Forced service （允許數(shù)據(jù)丟失） - 主要是在高性能模式下（safety OFF）用于立刻和手動的恢復(fù)鏡像數(shù)據(jù)庫

當(dāng)safety設(shè)置為FULL時，用于互換服務(wù)器角色的最好的方式是使用手動故障轉(zhuǎn)移，而不是forced service。

自動故障轉(zhuǎn)移

自動故障轉(zhuǎn)移是高可用模式下（safety為FULL使用見證服務(wù)器）數(shù)據(jù)庫鏡像的功能。大多數(shù)情況下，SQL Server可以在幾秒鐘內(nèi)完成自動故障轉(zhuǎn)移。SQL Server可以進(jìn)行局部自動故障轉(zhuǎn)移，因?yàn)榘跀?shù)據(jù)庫鏡像會話中的SQL服務(wù)器會彼此測試對方的存在。該過程稱為“ping”，但包含的操作遠(yuǎn)不止一個普通的 IP地址ping。鏡像服務(wù)器和見證服務(wù)器聯(lián)系主服務(wù)器以檢查主物理服務(wù)器是否存在、SQL Server是否存在、以及主數(shù)據(jù)庫是否可用。類似的， 主服務(wù)器和見證服務(wù)器ping鏡像服務(wù)器以檢查鏡像物理服務(wù)器和SQL Server實(shí)例的可用性，以及鏡像數(shù)據(jù)庫的還原狀態(tài)。

假設(shè)使用safety FULL和見證服務(wù)器配置了數(shù)據(jù)庫鏡像。鏡像服務(wù)器即Server B通過ping發(fā)現(xiàn)主服務(wù)Server A不可用。Server B與見證服務(wù)器通信并收到見證服務(wù)器也看不到Server A的確認(rèn)消息。那么Server B將和見證服務(wù)器組成quorum并將自己提升為主服務(wù)器角色。它將恢復(fù)它的數(shù)據(jù)庫并且通知見證服務(wù)器如今自己擔(dān)當(dāng)了主服務(wù)器的角色（盡管數(shù)據(jù)庫處于disconnected狀態(tài)，新主數(shù)據(jù)庫的事務(wù)日志也不能被截?cái)啵?/p>

Server B的新主數(shù)據(jù)庫繼續(xù)重新執(zhí)行事務(wù)日志中的活動，但是它將持續(xù)redo狀態(tài)而且大多數(shù)情況下只有很少的工作需要完成。在所有SQL Server版本中，新主數(shù)據(jù)庫只要完成redo過程就立刻可用了。當(dāng)數(shù)據(jù)庫進(jìn)入undo狀態(tài)時將可以接收用戶連接了。完成redo通常只需幾秒鐘，盡管余下的undo階段時間可能很長。在數(shù)據(jù)庫鏡像中，新的主數(shù)據(jù)庫只要redo階段完成就可以為用戶連接提供服務(wù)。新主服務(wù)器B的數(shù)據(jù)庫處于DISCONNECTED狀態(tài)而且是exposed，但是只要redo過程完成就可以提供數(shù)據(jù)庫服務(wù)。

通常將整個應(yīng)用程序從主服務(wù)器重新定向到新主服務(wù)器花費(fèi)的時間要多于數(shù)據(jù)庫鏡像的自動故障轉(zhuǎn)移。應(yīng)用程序必須檢測和重試連接，這樣也會增加該過程的整體時間。此外，如果將新的SQL Server驗(yàn)證登陸賬號添加到服務(wù)器，還需要使用系統(tǒng)存儲過程sp_change_users_login將這些登陸賬戶映射到新主數(shù)據(jù)庫的用戶賬戶。如果舊的主服務(wù)器上一些關(guān)鍵對象，如SQL Agent作業(yè)還沒有拷貝到新主服務(wù)器上，也會耽誤應(yīng)用程序故障轉(zhuǎn)移的完成。（更多信息請閱讀該白皮書實(shí)現(xiàn)數(shù)據(jù)庫鏡像部分的“為故障轉(zhuǎn)移準(zhǔn)備鏡像服務(wù)器”）

現(xiàn)在假設(shè)舊的主服務(wù)器聯(lián)機(jī)了。如果是手動故障轉(zhuǎn)移，或者舊的主服務(wù)器被快速修復(fù)的自動故障轉(zhuǎn)移場景，兩臺服務(wù)器需要進(jìn)行角色互換，那么就必須進(jìn)行一個協(xié)商過程。在數(shù)據(jù)庫鏡像重新開始之前，兩臺伙伴服務(wù)器需要決定彼此怎樣進(jìn)行同步。鏡像故障轉(zhuǎn)移lsn這個過程中扮演了一個關(guān)鍵角色。

Server A （新鏡像服務(wù)器）落后了，但它并不清楚自己落后了多少。Server A向server B（新主服務(wù)器）報(bào)告它從server B接收的最后的鏡像故障轉(zhuǎn)移lsn。另一方面，Server B由于某些提交的工作而導(dǎo)致它有最新的鏡像故障轉(zhuǎn)移lsn，server A必須要追趕上server B。Server B將足夠數(shù)量的事務(wù)日志發(fā)送給server A，使server A通過重新這些執(zhí)行事務(wù)并與Server B同步。

手動故障轉(zhuǎn)移

手動故障轉(zhuǎn)移就是依次交換兩個伙伴服務(wù)器的角色。它要求safety設(shè)置為FULL，并且主服務(wù)器和鏡像服務(wù)器處于SYNCHRONIZED狀態(tài)。

在主服務(wù)器上使用下面的ALTER DATABASE命令進(jìn)行手動故障轉(zhuǎn)移：

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;

或者在Management Studio的Database Properties/Mirroring對話框中單擊Failover按鈕。手動故障轉(zhuǎn)移在舊的主數(shù)據(jù)庫上斷開所有用戶連接并回滾所有未完成的事務(wù)。通過完成所有redo隊(duì)列中已提交的事務(wù)，回滾所有未完成的事務(wù)（在undo階段）來恢復(fù)鏡像數(shù)據(jù)庫。舊的舊的鏡像數(shù)據(jù)庫被分配了主數(shù)據(jù)庫角色，而舊的主數(shù)據(jù)庫則擔(dān)當(dāng)新的鏡像數(shù)據(jù)庫角色。兩臺服務(wù)器根據(jù)它們的鏡像故障轉(zhuǎn)移lsn協(xié)商數(shù)據(jù)庫鏡像的新起點(diǎn)，然后處理角色互換。

可以使用手動故障轉(zhuǎn)移作為實(shí)現(xiàn)操作系統(tǒng)或者SQL SERVER實(shí)例的‘滾動升級’的一種方式來，假如您在初始化鏡像服務(wù)器之前首先升級鏡像服務(wù)器。更多信息請參閱SQL Server Books Online中'Manual Failover' 主題。

Forced Service

在鏡像服務(wù)器上使用ALTER DATABASE命令進(jìn)行forced Service：

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

通常只有當(dāng)safety為OFF并且主服務(wù)器再也無法運(yùn)轉(zhuǎn)時才使用這種方式。也可以在safety為FULL使使用該命令，但是如果恢復(fù)的鏡像服務(wù)器無法組成quorum，它也不能提供數(shù)據(jù)庫服務(wù)。因此最好在safety為OFF（高性能操作模式）是使用該命令。由于異步的數(shù)據(jù)傳輸無法保證鏡像數(shù)據(jù)庫包含所有主服務(wù)器上提交的最新事務(wù)，因此有些數(shù)據(jù)可能會丟失。

數(shù)據(jù)庫鏡像可用性場景

在這一部分，您將根據(jù)以下兩類事件對數(shù)據(jù)庫鏡像預(yù)期的可用性結(jié)果進(jìn)行研究：

◆一個或多個服務(wù)器或者數(shù)據(jù)庫失敗
◆服務(wù)器之間一條或多條通信連路失敗

服務(wù)器失敗可能是由于某個鏡像伙伴數(shù)據(jù)庫、或者某個SQL SERVER實(shí)例不可用。此外，即使服務(wù)器本身可以繼續(xù)運(yùn)轉(zhuǎn)，但是數(shù)據(jù)庫鏡像伙伴服務(wù)器之間的通信連路可能中斷。

以下場景中，兩個組件的同時失敗被視為一個組件緊接著另一個組件的順序失敗。例如，Server A和B出現(xiàn)了同時失敗，鏡像系統(tǒng)將該事件視為一個順序事件：Server A失敗然后Server B失敗，或者反過來。

使用下面的規(guī)則來判定一個不可用事件的預(yù)期結(jié)果：

1.當(dāng)safety設(shè)置為FULL時，主服務(wù)器需要至少一臺其他服務(wù)器才能形成quorum來保持?jǐn)?shù)據(jù)庫可用。

如果主服務(wù)器無法組成quorum，也就無法再提供數(shù)據(jù)庫服務(wù)了。

2.當(dāng)safety設(shè)置為FULL，如果鏡像服務(wù)器和見證服務(wù)器都無法聯(lián)系到主服務(wù)器，那么鏡像服務(wù)器可以和見證服務(wù)器組成quorum并且改變其角色，使之成為新的主服務(wù)器。

這就是自動的故障轉(zhuǎn)移。

3.當(dāng)safety設(shè)置為FULL，如果主服務(wù)器和見證服務(wù)器合作組成quorum，但是斷開了和鏡像服務(wù)器的連接，那么主服務(wù)器失敗將不允許鏡像服務(wù)器和見證服務(wù)器組成quorum，也不允許鏡像服務(wù)器承擔(dān)主服務(wù)器的角色。

這樣可以防止所做的工作由于會話中斷而丟失。

4.當(dāng)safety設(shè)置為FULL，如果失敗的主服務(wù)器在停機(jī)或者孤立后重新加入會話，同時舊的鏡像服務(wù)器已經(jīng)承擔(dān)了主服務(wù)器的角色（和見證服務(wù)器組成quorum），那么舊的主服務(wù)器將在此次會話中承擔(dān)新鏡像服務(wù)器角色。

在故障轉(zhuǎn)移過程中，鏡像服務(wù)器和見證服務(wù)器會增加鏡像角色順序計(jì)數(shù)器。因?yàn)橹鞣?wù)器的鏡像角色順序計(jì)數(shù)器 小于另一個伙伴服務(wù)器和見證服務(wù)器的順序計(jì)數(shù)器，因此那兩臺服務(wù)器會在舊的主服務(wù)器重新加入會話之前組成quorum并開始工作。舊的主服務(wù)器擔(dān)當(dāng)起鏡像的角色。

5.當(dāng)safety設(shè)置為FULL并且會話中沒有見證服務(wù)器，或者見證不知何故退出了會話，鏡像伙伴服務(wù)器的失敗將導(dǎo)致無法組成quorum，主服務(wù)器也因此不再保持主數(shù)據(jù)庫可以使用。

無法組成quorum，因此不可能進(jìn)行自動的故障轉(zhuǎn)移，如果見證服務(wù)器不包含在safety為FULL的會話中。

高可用場景中服務(wù)器失敗

高可用操作模式下的數(shù)據(jù)庫鏡像其目的就是盡可能增加數(shù)據(jù)庫的可用性。在這種模式下，如果主數(shù)據(jù)庫無法訪問，那么數(shù)據(jù)庫鏡像將迅速使鏡像數(shù)據(jù)庫可以接受訪問。在下面的一組場景中，我們的討論將從高可用配置加上三臺獨(dú)立的服務(wù)器開始。

在下面的高可用場景中，Server A作為主服務(wù)器啟動，Server B是鏡像服務(wù)器，而Server W是見證服務(wù)器，如圖1所示：

圖1：示例數(shù)據(jù)庫鏡像會話在高可用操作模式下啟動

所有這三臺服務(wù)器可以在同一個站點(diǎn)使用局域網(wǎng)連接，也可以在不同的站點(diǎn)使用WAN進(jìn)行連接。Server A和Server B可以互換角色，但是Server W始終作為見證服務(wù)器。

現(xiàn)在來考慮如果其中一臺服務(wù)器出現(xiàn)故障時產(chǎn)生的結(jié)果。

場景 HASL1.1：主服務(wù)器失敗

下面的場景分析了在高可用模式下主服務(wù)器失敗時會發(fā)生什么。圖 2顯示了不同的角色，以及鏡像伙伴之間如何做角色轉(zhuǎn)換。

圖2：在高可用模式下，當(dāng)主服務(wù)器Server A失敗，故障轉(zhuǎn)移發(fā)生

主服務(wù)器Server A失敗后，鏡像和見證服務(wù)器組成quorum，自動的故障轉(zhuǎn)移產(chǎn)生。如果重新恢復(fù)了原始的主服務(wù)器，它將擔(dān)當(dāng)起鏡像服務(wù)器的角色。

注意：要導(dǎo)致高可用模式下的故障轉(zhuǎn)移，失敗可以發(fā)生在不同的級別上：服務(wù)服務(wù)器可能停機(jī)、主服務(wù)器上的SQL SERVER實(shí)例可能停止或者失敗、服務(wù)器上的主數(shù)據(jù)庫可能不可用或狀態(tài)可疑。在下面場景中，主服務(wù)器失敗可能由這些事件中的任何一個引起。

因?yàn)镾erver B和W可以組成quorum，并且二者均無法聯(lián)系Server A，那么Server B可以將自己提升為新的主服務(wù)器。但是如果沒有鏡像服務(wù)器，鏡像會話就被認(rèn)為是exposed。

Server A恢復(fù)后，它成為新的主服務(wù)器，鏡像會話也不再是exposed。

單服務(wù)器失敗事件并不多見，兩臺服務(wù)器失敗就更少見了，因此研究在這種情況下出現(xiàn)的結(jié)果十分有用。

兩臺服務(wù)器可以同時或者幾乎同時失敗，但從數(shù)據(jù)庫鏡像的角度來看，其結(jié)果被視為一臺服務(wù)器失敗緊接著另一臺也失敗了。因此這些場景只考慮當(dāng)多臺服務(wù)器順序失敗時的后果。

接下來的兩個場景分析主服務(wù)器 Server A失敗，緊接著其他兩臺服務(wù)器也失敗時會產(chǎn)生的結(jié)果。

◆新的主服務(wù)器 Server B失?。?br>◆見證服務(wù)器 Server W失??；

場景 HASL1.2：主服務(wù)器失敗，隨后新的主服務(wù)器失敗

同前面的場景一樣，在高可用操作模式下，如果主服務(wù)器首先失敗，那么故障轉(zhuǎn)移發(fā)生。圖3顯示了如果新的主服務(wù)器接下來也失敗了，那么無論怎樣恢復(fù)這些服務(wù)器，新的主服務(wù)器（Server B）始終保持其主服務(wù)器的角色。

圖3：由于主服務(wù)器失敗，接著新主服務(wù)器也失敗而導(dǎo)致角色轉(zhuǎn)換

Server A失敗后，Server B成為新的主服務(wù)器，但是無法將數(shù)據(jù)發(fā)送給鏡像服務(wù)器，因此主服務(wù)器處于exposed，即使它仍然提供數(shù)據(jù)庫服務(wù)。當(dāng)Server A失敗緊接著Server B也失敗，那么就不存在數(shù)據(jù)庫鏡像了，因?yàn)镾erver B已經(jīng)停工了。

如果Server A首先恢復(fù)，它從見證服務(wù)器的mirroring_role_sequence號中檢測到見證服務(wù)器已經(jīng)組成了新的quorum。

Server A接納了鏡像服務(wù)器的角色，然后等待Server B恢復(fù)。Server B一旦恢復(fù)，立刻開始了和Server A的數(shù)據(jù)庫鏡像過程。如果Server B先恢復(fù)，那么就重新回到了在HASL1。1中顯示的初始場景。

注意：如果Server W在Server A和Server B相繼失敗后也宣告失敗，導(dǎo)致所有三臺服務(wù)器均停工，那么無論以什么次序恢復(fù)見證服務(wù)器，已經(jīng)轉(zhuǎn)換完成的Server A和Server B的角色將保持不變。

場景 HASL1.3：主服務(wù)器失敗，隨后見證服務(wù)器失敗

主服務(wù)器失敗后發(fā)生故障轉(zhuǎn)移。見證服務(wù)器可能接下來也失敗，如圖4所示：

圖4：見證服務(wù)器緊隨原始主服務(wù)器出現(xiàn)失敗，那么新主服務(wù)器無法提供數(shù)據(jù)庫服務(wù)

當(dāng)見證服務(wù)器 Server W主服務(wù)器 Server A失敗后也出現(xiàn)失敗，那么新主服務(wù)器 Server B依然為主服務(wù)器但被孤立，無法組成quorum，也不能提供數(shù)據(jù)庫服務(wù)。

如果Server A首先恢復(fù)，Server B的mirroring_role_sequence號將比Server A的大1，因?yàn)楫a(chǎn)生了故障轉(zhuǎn)移。這些信息指示Server A如今Server B在Server A只有擔(dān)當(dāng)了主服務(wù)器的角色。Server A和Server B組成quorum 并成為一對鏡像，此后兩臺服務(wù)器保持同步。除非Server W恢復(fù)，否則不會產(chǎn)生自動故障轉(zhuǎn)移。

注意：如果Server W在Server A和Server B相繼之后也宣告失敗，那么無論以什么次序恢復(fù)見證服務(wù)器，已經(jīng)轉(zhuǎn)換完成的Server A和Server B的角色將保持不變。

場景 HASL2.1：鏡像服務(wù)器失敗

如果鏡像服務(wù)器首先失敗，那么主服務(wù)器被視為exposed，因?yàn)樗鼰o法發(fā)送數(shù)據(jù)給鏡像服務(wù)器。圖 5顯示了Server B，即鏡像服務(wù)器失敗時的行為。

圖5：在高可用模式下，當(dāng)鏡像服務(wù)器Server B失敗時不產(chǎn)生故障轉(zhuǎn)移

沒有自動故障轉(zhuǎn)移發(fā)生，鏡像伙伴也不會交換角色。當(dāng)Server B恢復(fù)時，所有三臺服務(wù)器還原到其初始角色和狀態(tài)。

下表顯示了鏡像服務(wù)器Server B失敗以及恢復(fù)時數(shù)據(jù)庫狀態(tài)。

由于沒有鏡像服務(wù)器，數(shù)據(jù)無法存放在冗余數(shù)據(jù)庫中，因此會話處于exposed。

Server B一旦恢復(fù)立刻重新?lián)?dāng)起它的鏡像服務(wù)器角色。只要兩臺服務(wù)器同步，鏡像會話就不再被視為exposed。

接下來的兩個場景考慮鏡像服務(wù)器Server B失敗，緊接著主服務(wù)器Server A或者見證服務(wù)器Server W失敗時產(chǎn)生的結(jié)果。

場景 HASL2.2：鏡像服務(wù)器失敗，隨后主服務(wù)器失敗

緊隨鏡像服務(wù)器之后主服務(wù)器也失敗了，鏡像伙伴服務(wù)器的角色保持不變。圖6顯示了采用不同方式還原服務(wù)器時角色將如何轉(zhuǎn)換。

圖6：鏡像服務(wù)器失敗隨后主服務(wù)器主失敗，那么見證服務(wù)器被孤立

在Server B和Server A都失敗后，各服務(wù)器狀態(tài)顯示在圖中的右上角處。
如果Server B首先恢復(fù)，它將從見證服務(wù)器Server W處檢測到Server A依然為主服務(wù)器并且還沒有產(chǎn)生故障轉(zhuǎn)移，mirroring_failover_lsn也沒有增加。其結(jié)果為，Server B依然為鏡像服務(wù)器。Server W恢復(fù)后將會話還原到初始狀態(tài)。

注意：如果Server W在Server B和Server A相繼失敗之后也宣告失敗了，那么以任何順序還原這些服務(wù)器將導(dǎo)致相同結(jié)果。

場景 HASL2.3：鏡像服務(wù)器失敗，隨后見證服務(wù)器失敗

鏡像服務(wù)器失敗，隨后見證服務(wù)器也失敗，那么主服務(wù)器被孤立并且無法和任何其他服務(wù)器組成quorum。因此它必須停止數(shù)據(jù)庫的工作，如圖7右上角所示。

圖7：A鏡像服務(wù)器失敗，隨后見證服務(wù)器失敗，導(dǎo)致主服務(wù)器無法提供數(shù)據(jù)庫服務(wù)

由于鏡像服務(wù)器故障以及隨后的見證服務(wù)器失敗，主服務(wù)器 Server A保持其主服務(wù)器角色，由于無法和任何其他服務(wù)器組成quorum，而safety又被設(shè)置成FULL，因此不再為數(shù)據(jù)庫提供服務(wù)，并斷開所有的用戶連接。

如果Server B首先恢復(fù)，那么數(shù)據(jù)庫鏡像將重新開始工作，盡管由于缺失見證服務(wù)器而不會產(chǎn)生自動故障轉(zhuǎn)移。

如果Server W首先恢復(fù)，那么情況與圖5中顯示的一樣。

注意：如果Server A在Server B和Server W相繼失敗之后也宣告失敗，那么以任何次序還原這些服務(wù)器其最終結(jié)果保持不變。

場景 HASL3.1：見證服務(wù)器失敗

見證服務(wù)器失敗時，數(shù)據(jù)庫鏡像繼續(xù)進(jìn)行但是不可能產(chǎn)生自動的故障轉(zhuǎn)移。如果再有一臺或多臺服務(wù)器失敗，就意味著沒法組成quorum，那么主服務(wù)器上的數(shù)據(jù)庫也不再服務(wù)于數(shù)據(jù)庫用戶。

圖8：在高可用模式下，見證服務(wù)器Server W首先失敗，那么數(shù)據(jù)庫鏡像繼續(xù)

Server W恢復(fù)后，兩個伙伴服務(wù)器Server A和Server B維持它們的初始角色。

下表顯示了見證服務(wù)器失敗以及恢復(fù)后，數(shù)據(jù)庫狀態(tài)以及quorum的變化。

下面的兩個場景考慮見證服務(wù)器Server W失敗，緊接著主服務(wù)器 Server A或者鏡像服務(wù)器Server B失敗時產(chǎn)生的結(jié)果。

場景 HASL3.2：見證服務(wù)器失敗，隨后主服務(wù)器失敗

見證服務(wù)器首先失敗，那么數(shù)據(jù)庫鏡像將繼續(xù)進(jìn)行，但是不可能產(chǎn)生自動的故障轉(zhuǎn)移。其余兩臺服務(wù)器中任何一臺失敗將導(dǎo)致無法組成quorum，余下的那臺服務(wù)器將被孤立。

圖9：原始見證服務(wù)器失敗，隨后主服務(wù)器失敗，鏡像伙伴角色保持不變

如果Server W首先恢復(fù)，那么Server B將從見證服務(wù)器那里檢測到最后的主服務(wù)器是Server A，同時Server B依然是鏡像服務(wù)器。最終Server A恢復(fù)時，它將保持其主服務(wù)器角色。

注意：如果Server B在Server W和Server A相繼失敗后也宣告失敗了，那么以任意次序還原這些服務(wù)器都不會影響最終結(jié)果。

場景 HASL3.3：見證服務(wù)器失敗，隨后鏡像服務(wù)器失敗

如果見證服務(wù)器失敗，隨后鏡像服務(wù)器也失敗，那么主服務(wù)器被孤立。由于safety設(shè)置為FULL并且主服務(wù)器無法組成quorum，它將不再提供數(shù)據(jù)庫服務(wù)，如圖10所示。

圖10：見證服務(wù)器失敗，隨后鏡像服務(wù)器失敗，主服務(wù)器必須停止其數(shù)據(jù)庫服務(wù)

注意：如果Server A在Server W和Server B相繼失敗之后也宣告失敗， 那么以任意次序還原這些服務(wù)器都不會影響最終結(jié)果。

總結(jié)：高可用場景中服務(wù)器失敗

從這些場景中可以得出幾個結(jié)論。在高可用操作模式下：

1.如果主服務(wù)器首先不可用，那么產(chǎn)生自動的故障轉(zhuǎn)移，原先的鏡像服務(wù)器將擔(dān)當(dāng)主服務(wù)器角色，并使其數(shù)據(jù)庫服務(wù)于用戶活動。后續(xù)的服務(wù)器失敗和恢復(fù)不會影響使用新主服務(wù)器的數(shù)據(jù)庫鏡像的整體配置。數(shù)據(jù)庫鏡像將以相反的方向繼續(xù)進(jìn)行。

2.如果鏡像首先不可用，那么產(chǎn)生自動的故障轉(zhuǎn)移 。后續(xù)的服務(wù)器失敗以及恢復(fù)次序都不會影響鏡像伙伴角色。

3.如果見證服務(wù)器首先不可用，那么不可能產(chǎn)生自動的故障轉(zhuǎn)移，鏡像伙伴服務(wù)器將保持其初始角色。后續(xù)的服務(wù)器失敗以及恢復(fù)都不會影響鏡像伙伴角色。

下表總結(jié)了在高可用場景中出現(xiàn)一臺或兩臺服務(wù)器失敗時產(chǎn)生的結(jié)果。表中假設(shè)的條件是safety設(shè)置為FULL并且鏡像會話中的服務(wù)器滿足下列條件：

A：主服務(wù)器， SYNCHRONIZED
B：鏡像服務(wù)器，SYNCHRONIZED
W：見證服務(wù)器，CONNECTED

表中使用灰色加亮顯示故障轉(zhuǎn)移場景。

表10：總結(jié)：單服務(wù)器或者雙服務(wù)器失敗，顯示伙伴服務(wù)器角色和數(shù)據(jù)庫狀態(tài)

高可用場景中通信失敗

高可用操作模式需要三個SQL Sever實(shí)例。如果這些服務(wù)器位于兩個或三個獨(dú)立的物理站點(diǎn)并且相距很遠(yuǎn)，那么這些站點(diǎn)間的通信就很可能出現(xiàn)問題。換句話說，服務(wù)器依然運(yùn)轉(zhuǎn)但是彼此間的通信連路中斷了。這種情況比前面的那些場景要復(fù)雜一些，但原理是一樣的。

下面高可用操作場景中通信失敗的研究將通過兩組來完成。第一組是基于三個來自不同站點(diǎn)的SQL SERVER實(shí)例，因此有三條獨(dú)立的通信連路。第二組是基于兩個獨(dú)立站點(diǎn)上的服務(wù)器，第一個站點(diǎn)上的一對服務(wù)器和第二個站點(diǎn)上的第三臺服務(wù)器之間有一條通信連路。

先從第一組開始，假設(shè)一個數(shù)據(jù)庫會話中所有三臺服務(wù)器之間有三條獨(dú)立的通信連路。例如，主服務(wù)器、鏡像服務(wù)器和見證服務(wù)器位于三個獨(dú)立的協(xié)作站點(diǎn)上（也有可能三臺服務(wù)器位于同一個站點(diǎn)，但使用私有網(wǎng)絡(luò)連接）

初始條件是Server A上運(yùn)行主數(shù)據(jù)庫并且與其鏡像伙伴Server B保持同步。

Server B上是鏡像數(shù)據(jù)庫Safety設(shè)置為FULL，見證服務(wù)器 (Server W)也包含在數(shù)據(jù)庫鏡像會話中。圖11顯示了初始配置。

圖11：高可用配置中三臺獨(dú)立服務(wù)器、三條獨(dú)立通信連路的初始狀態(tài)

注意：要獲得頁面上圖表的解釋，請參閱前面介紹的“高可用場景中服務(wù)器失敗”

根據(jù)圖11，三條鏈路可能首先中斷：A/B， A/W和B/W。注意當(dāng)某條通信連路中斷時，所有三臺服務(wù)器依然運(yùn)轉(zhuǎn)正常。只有主服務(wù)器和鏡像服務(wù)器之間的通信連路有一些影響，如表11所示。

表11：總結(jié)：單條通信連路中斷

 只有主服務(wù)器/鏡像服務(wù)器的連接中斷會對鏡像造成影響。其他的連路中斷，例如主服務(wù)器/見證服務(wù)器或者鏡像服務(wù)器/見證服務(wù)器之間的通信中斷不會改變數(shù)據(jù)庫鏡像會話的行為。 總之，表HACL1顯示出： ◆所有單條鏈路中斷場景中只有主服務(wù)器/鏡像服務(wù)器鏈路中斷會影響數(shù)據(jù)庫鏡像，主服務(wù)器運(yùn)行 狀態(tài)為exposed，因?yàn)闆]有日志記錄發(fā)送到鏡像。 現(xiàn)在考慮如果第二條連路中斷產(chǎn)生的結(jié)果。兩條連路可以同時中斷，也可以相繼中斷。 如果兩條連路同時中斷，其最終結(jié)果與兩條連路相繼中斷是一樣的。但是無法事先預(yù)料中斷的先后順序；只有知道了先后次序才能夠據(jù)此分析鏈路同時中斷的結(jié)果。 

由于這個原因，我們只考慮鏈路順序中斷的情形。表12列出了高可用模式中通信鏈路中斷的一些基本場景。

表12：大部分雙-通信鏈路中斷的結(jié)果與服務(wù)器故障場景中單機(jī)故障是一樣的 

 表HACL2顯示所有順序的雙-通信鏈路失敗都等價于前一部分介紹的單服務(wù)器故障場景，因此我們不再這里對它們作重復(fù)分析了。 

值得注意的一點(diǎn)是： ◆兩條鏈路中斷時只有一個場景會產(chǎn)生故障轉(zhuǎn)移：主服務(wù)器/見證服務(wù)器鏈路中斷，隨后主服務(wù)器/鏡像服務(wù)器鏈路中斷。 如果主服務(wù)器/鏡像服務(wù)器鏈路中斷，隨后主服務(wù)器/見證服務(wù)器也出現(xiàn)鏈路中斷，那么不會產(chǎn)生故障轉(zhuǎn)移，即使主服務(wù)器被孤立而且鏡像服務(wù)器和見證服務(wù)器無法聯(lián)系上它。 我們再仔細(xì)研究一下場景 HACL1.2。 

場景 HACL1.2：主服務(wù)器/鏡像服務(wù)器連路中斷，隨后主服務(wù)器/見證服務(wù)器鏈路中段 如果主服務(wù)器/鏡像服務(wù)器鏈路中段，隨后主服務(wù)器和見證服務(wù)器之間的鏈路也中斷了，那么主服務(wù)器被孤立。它看不到其他服務(wù)器并且失去了它的quorum。同時，鏡像服務(wù)器和見證服務(wù)器無法知道主服務(wù)器是否依然健在，因此Server B擔(dān)當(dāng)起主服務(wù)器，然后自動的故障轉(zhuǎn)移產(chǎn)生。圖12顯示了這些事件。

圖12：在高可用模式下， 主服務(wù)器/鏡像服務(wù)器鏈路中段，隨后主服務(wù)器/見證服務(wù)器鏈路中段，不產(chǎn)生故障轉(zhuǎn)移 

當(dāng)主服務(wù)器/鏡像服務(wù)器以及主服務(wù)器/見證服務(wù)器之間的通信鏈路相繼中斷有，Server A被孤立并使其數(shù)據(jù)庫停止服務(wù)。Server B和W無法形成quorum，因?yàn)镾erver A可能執(zhí)行了一些Server B上沒有的工作。 如果主服務(wù)器/見證服務(wù)器 (A/W) 鏈路中斷首先修復(fù)，那么Server A繼續(xù)擔(dān)當(dāng)其主服務(wù)器角色，狀態(tài)為DISCONNECTED。但是不會進(jìn)行數(shù)據(jù)庫鏡像，因?yàn)橹鞣?wù)器和鏡像服務(wù)器之間的連接還沒有修復(fù)。 如果主服務(wù)器/鏡像服務(wù)器 (A/B) 鏈路中斷首先修復(fù)，那么Server A將繼續(xù)與Server B的數(shù)據(jù)庫競相，即使沒有見證服務(wù)器，因此該會話是exposed。除非主服務(wù)器/見證服務(wù)器連接最終被修復(fù)，否則不會產(chǎn)生自動的故障轉(zhuǎn)移。  

總結(jié)：高可用場景中通信失?。喝齻€站點(diǎn) 下表總結(jié)了使用三臺獨(dú)立物理服務(wù)器時單鏈路和雙-鏈路中斷的行為。 表中的初始條件是Safety設(shè)置為FULL，服務(wù)器分別是：A：主服務(wù)器， SYNCHRONIZED
B：鏡像服務(wù)器， SYNCHRONIZED
W：見證服務(wù)器， CONNECTED 使用灰色加亮顯示故障轉(zhuǎn)移路徑。 

表13：總結(jié)：單條鏈路中斷和雙-鏈路中斷，高可用模式，三臺獨(dú)立服務(wù)器，Safety設(shè)置為FULL

場景 HACL4：兩個站點(diǎn)，見證服務(wù)器位于鏡像服務(wù)器站點(diǎn) 

如果所有服務(wù)器之間僅有一條通信連路，那么必須選擇見證服務(wù)器的位置。首先，假設(shè)見證服務(wù)器和鏡像數(shù)據(jù)庫服務(wù)器放置在一起。兩組服務(wù)器之間僅有一條通信連路，該鏈路可能中斷，如圖13所示。 

圖13：主服務(wù)器和鏡像服務(wù)器/見證服務(wù)器站點(diǎn)之間的通信連路中斷了

Server A看不到見證服務(wù)器Server W或者鏡像數(shù)據(jù)庫服務(wù)器Server B，因此無法組成quorum。Server B和Server W可以組成quorum，但二者均無法看見主服務(wù)器Server A。鏈路中斷的結(jié)果顯示在圖14。 

圖14：通信連路中斷并且見證服務(wù)器位于鏡像服務(wù)器站點(diǎn)，產(chǎn)生故障轉(zhuǎn)移

因?yàn)镾erver A無法看見見證服務(wù)器Server W或者原先的鏡像伙伴Server B，因此必須進(jìn)入disconnected狀態(tài)并使數(shù)據(jù)庫不可用。Server B和Server W可以組成quorum。Server B無法看見Server A，因此Server B試圖成為主服務(wù)器并使其數(shù)據(jù)庫聯(lián)機(jī)。因?yàn)镾erver W也看不到Server A，因此同意了Server B。Server B現(xiàn)在有了quorum，擔(dān)當(dāng)起會話的主服務(wù)器角色，然后還原其數(shù)據(jù)庫。 如果恢復(fù)通信連路，Server A能夠看到Server B如今成為主服務(wù)器，并檢測到見證服務(wù)器Server W也認(rèn)可Server B為主服務(wù)器。Server A將其角色轉(zhuǎn)換為鏡像服務(wù)器，然后嘗試與新主服務(wù)器同步。同步之后的配置結(jié)果如圖15所示。 

圖15：該場景通信連路恢復(fù)后的版本，數(shù)據(jù)庫鏡像按反方向進(jìn)行 

總結(jié)：見證服務(wù)器位于鏡像服務(wù)器的遠(yuǎn)程站點(diǎn)上，如果站點(diǎn)間的通信鏈路中斷，自動的故障轉(zhuǎn)移產(chǎn)生。

場景 HACL5：兩個站點(diǎn)，見證服務(wù)器位于主服務(wù)器站點(diǎn) 在這個高可用場景中，假設(shè)將見證服務(wù)器放置在主服務(wù)器所在的同一站點(diǎn)上，如圖16所示，然后兩個站點(diǎn)間的通信中斷了。

 圖16：主服務(wù)器/見證服務(wù)器和鏡像服務(wù)器之間的通信中斷 

在這種情況下，負(fù)責(zé)鏡像數(shù)據(jù)庫的Server B被主服務(wù)器和見證服務(wù)器孤立。Server A和Server W繼續(xù)組成quorum，因此Server A保持其數(shù)據(jù)庫為主數(shù)據(jù)庫。 但是，Server A同時將數(shù)據(jù)庫設(shè)置成disconnected狀態(tài)，因?yàn)樗鼰o法看到Server B也不可能進(jìn)行數(shù)據(jù)傳輸。Server B也無法看到Server A，因此也進(jìn)入disconnected狀態(tài)。配置結(jié)果如圖17所示。

圖17：該場景中通信失敗導(dǎo)致兩個伙伴為disconnected狀態(tài)

Server A繼續(xù)接受事務(wù)但無法截?cái)嗍聞?wù)日志記錄。如果迅速恢復(fù)了鏈路，鏡像會話還可以重新同步并返回到初始操作狀態(tài)。 總結(jié)：見證服務(wù)器和主服務(wù)器位于同一站點(diǎn)，鏡像服務(wù)器位于遠(yuǎn)程站點(diǎn)，站點(diǎn)之間的通信中斷不會產(chǎn)生自動的故障轉(zhuǎn)移。

總結(jié)：高可用場景中通信連路中斷 在使用三臺獨(dú)立服務(wù)器的高可用配置中，有三條獨(dú)立的通信連路。 

◆主服務(wù)器/鏡像服務(wù)器出現(xiàn)通信失敗，沒有自動的故障轉(zhuǎn)移會發(fā)生。
◆主服務(wù)器/見證服務(wù)器首先出現(xiàn)通信失敗，隨后主服務(wù)器/鏡像服務(wù)器通信中斷 ，自動的故障轉(zhuǎn)移將發(fā)生?；謴?fù)鏈路將繼續(xù)反方向的數(shù)據(jù)庫鏡像。
◆鏡像服務(wù)器/見證服務(wù)器通信失敗，沒有自動的故障轉(zhuǎn)移會發(fā)生。
在只有一條通信連路的高可用配置模式中，見證服務(wù)器駐留在主服務(wù)器或者鏡像服務(wù)器所在站點(diǎn)上。
◆見證服務(wù)器駐留在鏡像服務(wù)器的遠(yuǎn)程站點(diǎn)上，如果站點(diǎn)之間的通信鏈路中斷，那么自動的故障轉(zhuǎn)移將發(fā)生。
◆見證服務(wù)器和主服務(wù)器位于同一站點(diǎn)上，鏡像服務(wù)器在遠(yuǎn)程站點(diǎn)，站點(diǎn)之間的通信中斷不會導(dǎo)致自動的故障轉(zhuǎn)移發(fā)生。 高保護(hù)方案 高保護(hù)模式配合safety FULL一起工作，但沒有見證服務(wù)器。因?yàn)殓R像配置中只包括主數(shù)據(jù)庫服務(wù)器和鏡像數(shù)據(jù)庫服務(wù)器，因此只有一條通信連路。這使場景數(shù)量大大降低。 場景1：高保護(hù)操作模式只包括兩個SERVER實(shí)例，主服務(wù)器和鏡像服務(wù)器。由于沒有見證服務(wù)器，自動的故障轉(zhuǎn)移師不可能的。服務(wù)器之間僅有一條通信連路會中斷，導(dǎo)致配置結(jié)果如圖18所示。 

圖19：高保護(hù)場景中如果鏡像服務(wù)器不可用 ，那么主數(shù)據(jù)庫不受影響 

場景3：高保護(hù)場景中如果主數(shù)據(jù)庫不可用，那么鏡像數(shù)據(jù)庫必須繼續(xù)擔(dān)任鏡像，但進(jìn)入disconnected狀態(tài)，如圖20所示。

圖20：高保護(hù)場景中如果主數(shù)據(jù)庫不可用，那么鏡像數(shù)據(jù)庫進(jìn)入disconnected狀態(tài) 

因?yàn)楦弑Ｗo(hù)操作模式使用safety FULL，因此任何破壞都導(dǎo)致主數(shù)據(jù)庫比可用，而鏡像數(shù)據(jù)庫繼續(xù)維持recovering狀態(tài)：沒有數(shù)據(jù)庫是聯(lián)機(jī)的。其結(jié)果是：該模式對于高可用性需求而言不是一個好的解決方案，因此更適合作為一種臨時方案，如必須將見證服務(wù)器移除一小段時間。 高性能方案 高性能操作模式配合safety OFF一起工作。沒有見證服務(wù)器角色。因?yàn)殓R像配置中只包括主數(shù)據(jù)庫服務(wù)器和鏡像數(shù)據(jù)庫服務(wù)器，因此只有一條通信連路。盡管類似于高保護(hù)模式，但由于safety設(shè)置為OFF，因此其行為與高保護(hù)模式并不相同。 場景1：在高性能操作模式中使用兩個SQL SERVER實(shí)例。一個負(fù)責(zé)主數(shù)據(jù)庫另一個負(fù)責(zé)鏡像數(shù)據(jù)庫。因此服務(wù)器之間只有一條通信連路并且可能中斷，導(dǎo)致如圖21所示的配置結(jié)果。

圖21：高性能場景中通信失敗，兩個伙伴均進(jìn)入disconnected狀態(tài)，但是主數(shù)據(jù)庫依然可用 

由于safety設(shè)置為OFF， Server A不需要quorum就可以使數(shù)據(jù)庫保持為可用狀態(tài)。因此盡管已經(jīng)進(jìn)入disconnected狀態(tài)，主服務(wù)器還可以繼續(xù)接受用戶活動。如果通信恢復(fù)，那么鏡像數(shù)據(jù)庫將嘗試追趕主數(shù)據(jù)庫但無法做到，或者出現(xiàn)redo錯誤，如果它不能找回所有丟失的事務(wù)。 場景2：在高性能場景中，如果鏡像數(shù)據(jù)庫不可用，那么主數(shù)據(jù)庫結(jié)果顯示在圖22中。

圖22：如果在高性能模式下鏡像服務(wù)器不可用，主數(shù)據(jù)庫不受影響

由于safety設(shè)置為OFF，因此主數(shù)據(jù)庫依然可用。 場景 3：如果在高保護(hù)模式下主數(shù)據(jù)庫不可用，那么鏡像數(shù)據(jù)庫依然作為鏡像，但將被斷開，如圖23所示。 

圖23：如果主服務(wù)器不可用，那么Server B不會受到影響，但是進(jìn)入disconnected狀態(tài) 高性能操作模式和高保護(hù)模式一樣，沒有自動的故障轉(zhuǎn)移。由于safety設(shè)置為OFF，當(dāng)鏡像服務(wù)器不可用時，主服務(wù)器將保持其數(shù)據(jù)庫為可用。同樣由于safety設(shè)置為OFF，不保證事務(wù)一定到達(dá)鏡像數(shù)據(jù)庫。如果強(qiáng)制故障轉(zhuǎn)移到鏡像服務(wù)器，那么有些事務(wù)可能會因此丟失。 

實(shí)現(xiàn)數(shù)據(jù)庫鏡像 可以在SQL SERVER 2005 Books Online，數(shù)據(jù)庫鏡像主題的“How To”中找到實(shí)現(xiàn)數(shù)據(jù)庫鏡像的基本信息。在白皮書的這一部分，我們來研究實(shí)現(xiàn)數(shù)據(jù)庫鏡像的一個特殊示例以及最佳實(shí)踐。 

監(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）消息，在鏡像服務(wù)器名稱的旁邊附加一個（Mirror， Synchronized）。可以在主服務(wù)器上彈出的數(shù)據(jù)庫 Properties對話框中觀察Mirroring頁面下方的狀態(tài)框，從而檢查數(shù)據(jù)庫鏡像會話的狀態(tài)。（數(shù)據(jù)庫 Properties對話框不會在鏡像服務(wù)器上打開）。 還可以查詢數(shù)據(jù)庫鏡像目錄視圖sys.database_mirroring和sys.database_mirroring_witnesses（更多關(guān)于使用目錄視圖檢查鏡像會話中數(shù)據(jù)庫狀態(tài)的信息，請參閱該白皮書前面數(shù)據(jù)庫動態(tài)部分的“Database Mirroring Catalog View Metadata”。SQL SERVER Books Online中也包含了目錄視圖的完整文檔。） 

數(shù)據(jù)庫鏡像性能計(jì)數(shù)器 可以使用性能計(jì)數(shù)器監(jiān)視數(shù)據(jù)庫鏡像會話中鏡像伙伴之間的網(wǎng)絡(luò)流量。SQL Server Database Mirroring對象包含了大量有用的性能計(jì)數(shù)器來監(jiān)視主服務(wù)器和見證服務(wù)器。（參閱SQL Server Books Online中的"Monitoring Database Mirroring"） 可以在每個數(shù)據(jù)庫上設(shè)置Database Mirroring對象。如果需要在一臺服務(wù)器上監(jiān)視不止一個數(shù)據(jù)庫，那么既可以單獨(dú)監(jiān)視某個數(shù)據(jù)庫的活動，也可以監(jiān)視所有數(shù)據(jù)庫的全部活動。 對于主服務(wù)器，Log Bytes Sent/sec 計(jì)數(shù)器指示主服務(wù)器發(fā)送日志數(shù)據(jù)到鏡像服務(wù)器的速率，而Log Send Queue指示在某個給定時間點(diǎn)事務(wù)日志緩沖區(qū)中有多少字節(jié)要發(fā)送到鏡像服務(wù)器。隨著事務(wù)日志記錄從主服務(wù)器發(fā)送到鏡像服務(wù)器，主服務(wù)器的發(fā)送隊(duì)列將逐漸縮小，但也會隨著新的日志記錄進(jìn)入日志緩沖區(qū)而增長。主服務(wù)器上的Transaction Delay 計(jì)數(shù)器指示主服務(wù)器由于等待鏡像服務(wù)器關(guān)于日志接收的確認(rèn)消息導(dǎo)致的延遲。主服務(wù)器上的Sent/sec計(jì)數(shù)器與主服務(wù)器給鏡像服務(wù)器發(fā)送的數(shù)據(jù)頁面有關(guān)。 在鏡像服務(wù)器上，Log Bytes Received/sec指示鏡像服務(wù)器和主服務(wù)器之間相差多少。（見上面Log Bytes Sent/sec 計(jì)數(shù)器）。Redo Queue 計(jì)數(shù)器指示redo隊(duì)列的大小。鏡像服務(wù)器在redo階段使用redo隊(duì)列重新執(zhí)行來自主服務(wù)器的事務(wù)。Redo Bytes/sec指示鏡像服務(wù)器執(zhí)行redo隊(duì)列中事務(wù)的速率。 對于每個伙伴服務(wù)器，Sends/sec和Receives/sec 計(jì)數(shù)器指示有多少個發(fā)送和接收動作Bytes Sent/sec和Bytes Received/sec 計(jì)數(shù)器指示在每個伙伴服務(wù)器上那些發(fā)送和接收動作包含的字節(jié)數(shù)。 

估計(jì)Redo和Catch-up時間 如果出現(xiàn)故障轉(zhuǎn)移，可以使用Redo Queue和Redo Bytes/sec來估算鏡像數(shù)據(jù)庫完成redo并成為可用狀態(tài)需要花費(fèi)的時間。使用下面的簡單公式進(jìn)行計(jì)算： 估計(jì)的redo時間（秒） =
(Redo Queue)/(Redo Bytes/sec) 類似的，如果主服務(wù)器上的活動領(lǐng)先于鏡像服務(wù)器，可以使用Log Send Queue和Log Bytes Received/sec 計(jì)數(shù)器估算鏡像服務(wù)器追趕上主服務(wù)器需要花費(fèi)的時間。下面給出了計(jì)算公式： 估計(jì)的catch up時間（秒） =
(Log Send Queue)/( Log Bytes Received /sec) 

Profiler事件 SQL Server 2005 Profiler包含了一個數(shù)據(jù)庫鏡像事件類。Database:Database Mirroring State Change事件將記錄被監(jiān)視服務(wù)器是否發(fā)生了狀態(tài)改變。（參見SQL Server Books Online主題“Database Mirroring State Change Event Class”）。當(dāng)使用這個事件類時包含Database Name和State來會對您大有幫助?？梢允褂迷撌录ㄖ鷶?shù)據(jù)庫鏡像會話中的任何狀態(tài)改變。 

數(shù)據(jù)庫鏡像排錯 數(shù)據(jù)庫鏡像最容易出錯的地方就是配置過程和運(yùn)行過程。 

排除設(shè)置錯誤 如果已經(jīng)設(shè)置了數(shù)據(jù)庫鏡像但是無法啟動，那么重新開始所有配置步驟。 

1.確認(rèn)鏡像服務(wù)器盡可能接近主數(shù)據(jù)庫。如果嘗試啟動數(shù)據(jù)庫鏡像時收到了以下的錯誤消息： 遠(yuǎn)程“AdventureWorks”數(shù)據(jù)庫沒有前滾到本地?cái)?shù)據(jù)庫日志副本中包含的一個時間點(diǎn)。（Microsoft SQL SERVER， 錯誤：1412） 說明鏡像數(shù)據(jù)庫滯后于主數(shù)據(jù)庫。需要將主數(shù)據(jù)庫的事務(wù)日志備份應(yīng)用到鏡像數(shù)據(jù)庫（使用NORECOVERY），從而使鏡像數(shù)據(jù)庫恢復(fù)到某個時間點(diǎn)，并可以從此時間點(diǎn)開始接收來自主數(shù)據(jù)庫的日志記錄。 

2.確認(rèn)每個服務(wù)器的SQL SERVER Windows服務(wù)帳戶彼此相互信任。如果服務(wù)器所在的域沒有建立信任關(guān)系，那么確保證書是正確的。 

3.通過查詢sys.database_mirroring_endpoints目錄視圖，確認(rèn)不僅定義而且啟動了endpoint： 

SELECT * FROM sys.database_mirroring_endpoints;

 確認(rèn)使用了正確的完全限定計(jì)算機(jī)名稱以及正確的端口號。如果在一臺物理服務(wù)器的多個實(shí)例之間配置鏡像，那么端口號就必須是唯一的。SQL SERVER服務(wù)登陸帳號需要CONNECT到endpoint的訪問權(quán)限。 最后，確認(rèn)為服務(wù)器定義了正確的endpoint角色。 

4.確認(rèn)在ALTER DATABASE命令中指定了正確的鏡像伙伴名稱?？梢栽谥鞣?wù)器和鏡像服務(wù)器的sys.database_mirroring目錄視圖中（以及高可用模式下的sys.database_mirroring_witnesses witnesses）檢查鏡像伙伴名稱。 

排除運(yùn)行時錯誤 如果數(shù)據(jù)庫鏡像設(shè)置正確，然后在運(yùn)行過程中出現(xiàn)了錯誤，請檢查會話的當(dāng)前狀態(tài)。如果由于錯誤而使鏡像處于SUSPENDED狀態(tài)，就可能在鏡像服務(wù)器上產(chǎn)生redo錯誤。檢查并確認(rèn)鏡像服務(wù)器上有足夠的磁盤空間用于redo（數(shù)據(jù)文件所在分區(qū)的剩余空間）和日志hardening（日志文件所在分區(qū)的剩余空間）。當(dāng)您準(zhǔn)備重新啟動會話時，使用ALTER DATABASE來重新開始會話。 如果無法連接到主數(shù)據(jù)庫，最可能的原因就是safety設(shè)置為FULL并且主服務(wù)器無法組成quorum。這種情況能夠發(fā)生，例如，如果系統(tǒng)在高保護(hù)模式下運(yùn)行（safety為FULL但沒有見證服務(wù)器），鏡像服務(wù)器又?jǐn)嚅_了和舊的主服務(wù)器的聯(lián)系。可以在鏡像服務(wù)器上使用下面的命令強(qiáng)制鏡像服務(wù)器進(jìn)行恢復(fù)： 

ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

 問題就在于一旦恢復(fù)了鏡像數(shù)據(jù)庫，鏡像服務(wù)器將成為主服務(wù)器但卻無法形成quorum，因此無法服務(wù)于數(shù)據(jù)庫。如果那樣的話，只要把safety設(shè)置為OFF就可以允許它服務(wù)于數(shù)據(jù)庫了。 

安全性與性能 數(shù)據(jù)庫鏡像的性能是關(guān)于活動類型和事務(wù)安全性的一個函數(shù)。 傳輸日志到鏡像服務(wù)器會影響主服務(wù)器性能。數(shù)據(jù)庫鏡像給主服務(wù)器帶來的開銷是關(guān)于活動類型的一個函數(shù)。數(shù)據(jù)庫鏡像在多用戶以及大量長事務(wù)的系統(tǒng)上操作性能最好，因?yàn)閿?shù)據(jù)庫服務(wù)器正常的事務(wù)活動會掩蓋傳輸日志記錄到鏡像服務(wù)器的引起的開銷。如果單個用戶順序執(zhí)行大量短事務(wù)，那么數(shù)據(jù)庫鏡像給每個事務(wù)造成的開銷將十分顯著。 主服務(wù)器性能同樣受Safety設(shè)置的影響。當(dāng)safety設(shè)置為FULL時，主服務(wù)器必須等待鏡像服務(wù)器表示已經(jīng)收到日志記錄的確認(rèn)信息，才可以將事務(wù)提交消息返回給客戶端。如果有大量的用戶和大量的長事務(wù)，那么這種等待導(dǎo)致的開銷并不明顯。單線程系統(tǒng)和包含許多小事務(wù)的系統(tǒng)在safety OFF時可以運(yùn)行的更好。 因?yàn)殓R像服務(wù)器連續(xù)不斷地重新執(zhí)行從主服務(wù)器接收的數(shù)據(jù)更新事務(wù)，鏡像服務(wù)器的數(shù)據(jù)緩存將變得'hot'。換句話說，就是使用那些和主服務(wù)器類型相同的數(shù)據(jù)更新操作所涉及的數(shù)據(jù)頁面和索引頁面來加工緩存。為了使鏡像服務(wù)器的緩存更接近于主服務(wù)器緩存，數(shù)據(jù)庫鏡像將一個SELECT提示也傳遞給鏡像服務(wù)器，從而可以在鏡像服務(wù)器重新生成用于數(shù)據(jù)查詢的緩存內(nèi)容。這樣可以幫助鏡像服務(wù)器更接近于主服務(wù)器，同時減少故障轉(zhuǎn)移時剩余的redo時間。很明顯，鏡像服務(wù)器上任何其他活動，包括對數(shù)據(jù)庫快照的查詢也會影響緩存的狀態(tài)，并因此增加故障轉(zhuǎn)移時完成日志redo的時間。 

測試數(shù)據(jù)庫鏡像 當(dāng)設(shè)置自己的系統(tǒng)來測試數(shù)據(jù)庫鏡像時，有許多選項(xiàng)可用。所有數(shù)據(jù)庫鏡像都要求在數(shù)據(jù)庫鏡像會話中的服務(wù)器必須是不同的SQL SERVER實(shí)例。因此可以在一臺物理服務(wù)器上配置和測試數(shù)據(jù)庫鏡像，如果您安裝了多個SQL SERVER 2005關(guān)系數(shù)據(jù)庫引擎。也可以在一臺虛擬服務(wù)器上測試多個實(shí)例，但是在物理服務(wù)器上進(jìn)行測試更加可信。 進(jìn)行數(shù)據(jù)庫鏡像的負(fù)載和壓力測試時需要不同的物理服務(wù)器。一臺服務(wù)器上的兩個或者三個實(shí)例可能會消耗不切實(shí)際的服務(wù)器資源。此外服務(wù)器之間的網(wǎng)絡(luò)連接質(zhì)量也同樣重要。主服務(wù)器和鏡像服務(wù)器之間的網(wǎng)絡(luò)越好，日志記錄和消息傳送的速度就越快。 最逼真的測試就是在一臺真正的目標(biāo)服務(wù)器或者試驗(yàn)臺上進(jìn)行，并且和最終系統(tǒng)的物理屬性完全相同。當(dāng)您在一臺服務(wù)器上測試多個實(shí)例時，只能通過停止實(shí)例或者關(guān)機(jī)的方式來模擬數(shù)據(jù)庫鏡像中服務(wù)器失敗的效果。使用多臺物理服務(wù)器時，就可以通過斷開網(wǎng)線的方式來測試網(wǎng)絡(luò)連接失敗的效果。 

下面的實(shí)踐能夠幫助您創(chuàng)建測試環(huán)境： 

◆要測試服務(wù)器失敗，關(guān)閉SQL SERVER實(shí)例，通過SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。
◆要測試通信失敗，拔掉服務(wù)器上的網(wǎng)線。
◆要測試數(shù)據(jù)庫失敗，停止SQL SERVER服務(wù)，重新命名。mdf文件，然后再重啟SQL SERVER。
◆要導(dǎo)致鏡像數(shù)據(jù)庫的redo錯誤， 為主數(shù)據(jù)庫添加一個新文件，將文件存放在主服務(wù)器存在但鏡像服務(wù)器中不存在的分區(qū)中。
◆另一種導(dǎo)致鏡像服務(wù)器redo錯誤的方法就是強(qiáng)制鏡像服務(wù)器的數(shù)據(jù)庫文件空間不足。
◆要迫使主服務(wù)器的數(shù)據(jù)庫停工，強(qiáng)制主數(shù)據(jù)庫數(shù)據(jù)文件空間不足。
◆要導(dǎo)致主數(shù)據(jù)庫或鏡像數(shù)據(jù)庫日志緩沖區(qū)hardening失敗，強(qiáng)制日志文件空間不足。

為故障轉(zhuǎn)移準(zhǔn)備鏡像服務(wù)器 數(shù)據(jù)庫鏡像其實(shí)就是數(shù)據(jù)庫到數(shù)據(jù)庫的聯(lián)系。只有數(shù)據(jù)庫中的數(shù)據(jù)會通過日志記錄從主數(shù)據(jù)庫發(fā)送到鏡像數(shù)據(jù)庫。就像日志傳送和復(fù)制一樣，必須準(zhǔn)備備用服務(wù)器和鏡像數(shù)據(jù)庫，以便出現(xiàn)故障時可以完全接管主數(shù)據(jù)庫的工作。當(dāng)您準(zhǔn)備鏡像服務(wù)器時，應(yīng)該從以下幾個層面進(jìn)行考慮。 在物理服務(wù)器層面，確保備用服務(wù)器和主服務(wù)器擁有相同的或者盡可能接近的物理CPU和內(nèi)存配置，否則備用服務(wù)器在故障轉(zhuǎn)移后將無法勝任工作。此外可能還有一些支持應(yīng)用程序、監(jiān)視器、以及支持程序運(yùn)行的可執(zhí)行文件等等，都需要在鏡像服務(wù)器上進(jìn)行配置。 在SQL SERVER層面，確保備用服務(wù)器和主服務(wù)器擁有相同的SQL SERVER配置（例如，AWE、最大并行化程度）。但最重要的就是登陸帳戶和賬戶權(quán)限。主服務(wù)器上所有激活的SQL SERVER登陸帳戶都必須同時存在鏡像服務(wù)器上，否則一旦出現(xiàn)故障轉(zhuǎn)移，那么應(yīng)用程序?qū)o法使用這些登陸帳戶連接到新的主服務(wù)器上?？梢允褂肧QL SERVER集成服務(wù)的Transfer Logins任務(wù)將登陸帳戶和密碼從一臺服務(wù)器拷貝到另一臺服務(wù)器，但您還必須為這些登陸帳戶設(shè)置數(shù)據(jù)庫權(quán)限。如果將登陸帳戶傳輸?shù)搅硪粋€不同的域，那么可能出現(xiàn)不匹配色的SID，需要您去匹配它們。SQL SERVER主服務(wù)器上可能還存在大量的支持對象需要被轉(zhuǎn)移到備用服務(wù)器上：SQL Agent作業(yè)和警報(bào)、SQL SERVER集成服務(wù)包、支持?jǐn)?shù)據(jù)庫、連接服務(wù)器的定義、備份設(shè)備、維護(hù)計(jì)劃、SQL Mail或者數(shù)據(jù)庫設(shè)置、可能還有分布式事務(wù)協(xié)調(diào)器（MSDTC）設(shè)置，等等。 當(dāng)SQL Agent作業(yè)被傳輸?shù)絺溆梅?wù)器后，大部分將被迫設(shè)置為禁用。一旦出現(xiàn)故障轉(zhuǎn)移，需要您啟用這些作業(yè)。故障轉(zhuǎn)移后，如果應(yīng)用程序使用SQL SERVER驗(yàn)證，還需要將SQL SERVER新的主服務(wù)器上的登陸帳戶解析成新的主服務(wù)器上的數(shù)據(jù)庫用戶。完成該任務(wù)最好的工具就是存儲過程sp_change_users_login。 

多數(shù)據(jù)庫的問題 許多應(yīng)用程序使用一臺服務(wù)器上的多個數(shù)據(jù)庫。多個數(shù)據(jù)庫可以被一個應(yīng)用程序引用，也可能被多個應(yīng)用程序引用。但是數(shù)據(jù)庫鏡像每次只能在一個數(shù)據(jù)庫上工作。當(dāng)您設(shè)計(jì)數(shù)據(jù)庫鏡像時需要考慮這一點(diǎn)。 如果您希望高可用模式，那么最適合的就是一個應(yīng)用程序配合一個數(shù)據(jù)庫。當(dāng)自動的故障轉(zhuǎn)移發(fā)生時應(yīng)用程序不再需要主服務(wù)器上的任何數(shù)據(jù)庫?？紤]如果多個數(shù)據(jù)庫在一臺服務(wù)器上并且操作在高可用模式下，那么可能出現(xiàn)什么情況呢？如果一臺物理服務(wù)器掉電了，或者一個SQL SERVER實(shí)例失敗了，或者網(wǎng)絡(luò)通信失敗了，那么所有數(shù)據(jù)庫將自動故障轉(zhuǎn)移到備用服務(wù)器，而他們的鏡像將成為新的主數(shù)據(jù)庫。如果見證服務(wù)器可用，應(yīng)用程序可以連接到新的主數(shù)據(jù)庫。但是如果某個數(shù)據(jù)庫由于磁盤失敗而產(chǎn)生了分頁，因此只有這個數(shù)據(jù)庫被故障轉(zhuǎn)移，那么會發(fā)生什么呢？如果那樣的話，應(yīng)用程序就有可能無法連接到所有正確的數(shù)據(jù)庫。
因此依賴多數(shù)據(jù)庫的應(yīng)用程序不適合使用數(shù)據(jù)庫鏡像的高可用模式。您可以將safety設(shè)置成OFF，實(shí)際上就是不使用自動故障轉(zhuǎn)移，但您必需使用某種高效的方式保持和其它數(shù)據(jù)庫服務(wù)器的同步。 

數(shù)據(jù)庫鏡像和高可用性技術(shù) SQL SERVER 2005現(xiàn)在至少支持四種高可用性技術(shù)，盡管不同技術(shù)相互之間有些功能重疊，但每種技術(shù)都有各自的優(yōu)缺點(diǎn)。

這些技術(shù)是： 

◆數(shù)據(jù)庫鏡像 – 為了便于討論，我們將考慮高可用操作模式以及FULL safety和見證服務(wù)器。
◆故障轉(zhuǎn)移群集 – 最典型的配置就是2節(jié)點(diǎn)的Windows故障轉(zhuǎn)移群集配置一個SQL SERVER實(shí)例。
◆日志傳送 – 采用SQL SERVER內(nèi)置的日志傳送和一個獨(dú)立的監(jiān)視服務(wù)器。
◆事務(wù)復(fù)制 – 一臺分發(fā)服務(wù)器和一臺訂閱服務(wù)器，如果發(fā)行服務(wù)器失敗，訂閱服務(wù)器作為備用服務(wù)器。 在這一部分我們將比較這四種技術(shù)的基本功能，然后深入探討怎樣對數(shù)據(jù)庫鏡像進(jìn)行補(bǔ)充或者提供一個更好的解決方案。 下表顯示了四種技術(shù)的幾個高可用性功能。 

表14：比較SQL SERVER 2005高可用性技術(shù) 

數(shù)據(jù)庫鏡像和群集 數(shù)據(jù)庫鏡像和故障轉(zhuǎn)移群集最主要的差異就是提供了不同級別的冗余。數(shù)據(jù)庫鏡像提供的保護(hù)是數(shù)據(jù)庫級別的，而群集提供的保護(hù)是服務(wù)器實(shí)例級別的。另一個主要差別就是在數(shù)據(jù)庫鏡像中，主服務(wù)器和鏡像服務(wù)器是獨(dú)立的 SQL SERVER實(shí)例，兩個實(shí)例有不同的名稱；而群集中的 SQL SERVER實(shí)例則使用相同的虛擬服務(wù)器名稱和IP地址，而且無論哪個節(jié)點(diǎn)主持群集實(shí)例，虛擬服務(wù)器名稱和IP地址始終保持不變。 如果您需要在服務(wù)器一級的數(shù)據(jù)庫保護(hù)（例如，您的應(yīng)用程序需要同時訪問統(tǒng)一服務(wù)器上的多個數(shù)據(jù)庫），故障轉(zhuǎn)移群集將是更適合的選擇。但是，如果每次只須為一個數(shù)據(jù)庫提供可用性，那么數(shù)據(jù)庫鏡像具有更多優(yōu)勢。 數(shù)據(jù)庫鏡像不像群集那樣需要專門的硬件，也沒有共享存儲介質(zhì)失敗的潛在危險(xiǎn)。數(shù)據(jù)庫鏡像可以在最短時間內(nèi)讓備用數(shù)據(jù)庫開始提供服務(wù)，其速度快于任何其它的高可用技術(shù)。此外，數(shù)據(jù)庫鏡像能夠與ADO。NET和SQL Native Access Client很好的配合在一起，從而實(shí)現(xiàn)客戶端的故障轉(zhuǎn)移。 不能在群集中使用數(shù)據(jù)庫鏡像，但是可以考慮使用數(shù)據(jù)庫鏡像作為一種手段來創(chuàng)建群集數(shù)據(jù)庫實(shí)例的一個熱備用份。這樣做需要特別小心，因?yàn)槿杭墓收限D(zhuǎn)移時間長于數(shù)據(jù)庫鏡像的超時值，高可用模式下的鏡像會話將對群集的故障轉(zhuǎn)移做出反應(yīng)，認(rèn)為這是主服務(wù)器失敗了，然后會將群集節(jié)點(diǎn)設(shè)置為鏡像狀態(tài)。 

數(shù)據(jù)庫鏡像和事務(wù)復(fù)制 數(shù)據(jù)庫鏡像和事務(wù)復(fù)制都建立在讀取原始服務(wù)器事務(wù)日志的基礎(chǔ)上，但此后采用的技術(shù)就截然不同了。（更多關(guān)于事務(wù)復(fù)制的細(xì)節(jié)，請參閱SQL SERVER Books Online中的相關(guān)主題）。事務(wù)復(fù)制多用于配置高可用性，因?yàn)樗梢詫l(fā)行數(shù)據(jù)庫中的用戶事務(wù)在幾秒鐘內(nèi)遞送到訂閱數(shù)據(jù)庫中。數(shù)據(jù)庫鏡像的優(yōu)點(diǎn)是速度對于甚至快于復(fù)制，但需要遞送所有的數(shù)據(jù)庫事務(wù)，而不單單是與用戶表相關(guān)的事務(wù)。 事務(wù)復(fù)制技術(shù)適合于將數(shù)據(jù)擴(kuò)充到多個訂閱者。事務(wù)復(fù)制的訂閱數(shù)據(jù)庫通常是只讀的，如果需要近乎實(shí)時的數(shù)據(jù)訪問，那么事務(wù)復(fù)制是理想的候選者。 數(shù)據(jù)庫鏡像與事務(wù)復(fù)制兼容，如果需要維持發(fā)行數(shù)據(jù)庫的一個熱備份，數(shù)據(jù)庫鏡像就是非常有用的一種方式。其它用于保護(hù)復(fù)制發(fā)行商的方式，例如日志傳送無法在發(fā)行商自己的訂閱者之前維持發(fā)行商的備用服務(wù)器。換句話說，事務(wù)復(fù)制將事務(wù)日志遞送給訂閱者的速度要快于事務(wù)日志備份。正是因?yàn)閿?shù)據(jù)庫鏡像速度很快，因此特別適合用于維持發(fā)行數(shù)據(jù)庫的熱備份。 但是如果發(fā)行服務(wù)器失敗，就必須手動使用還原好的備用數(shù)據(jù)庫重新建立發(fā)行商，然后重新連接到分發(fā)服務(wù)器，， 使用日志傳輸維護(hù)發(fā)行商服務(wù)器的備用服務(wù)器所必須做的工作與此相同。 

數(shù)據(jù)庫鏡像和日志傳輸 數(shù)據(jù)庫鏡像和日志傳輸都依賴SQL SERVER數(shù)據(jù)庫提供的恢復(fù)和還原功能。在數(shù)據(jù)庫鏡像中，鏡像數(shù)據(jù)庫始終保持recovering狀態(tài)，連續(xù)不斷地還原來自主數(shù)據(jù)庫的事務(wù)日志。而日志傳輸中的備用數(shù)據(jù)庫則周期性地應(yīng)用事務(wù)日志備份中的事務(wù)。因?yàn)閎ulk-logged數(shù)據(jù)被附加到事務(wù)日志備份中，因此日志傳送可以工作在bulk-logged恢復(fù)模型下。數(shù)據(jù)庫鏡像則不同，它直接將日志記錄從主數(shù)據(jù)庫傳送到鏡像數(shù)據(jù)庫中而且不能遞送bulk-logged數(shù)據(jù)。 很多情況下數(shù)據(jù)庫鏡像可以提供與日志傳送相同的數(shù)據(jù)冗余以及更高的可用性和自動故障轉(zhuǎn)移。但是，如果應(yīng)用程序依賴一臺服務(wù)器上的多個數(shù)據(jù)庫，那么日志傳送是有效的方式（參閱前一部分介紹的“Multi-Database Considerations”）。 此外，某些數(shù)據(jù)庫鏡像場景中還可以通過日志傳送作為補(bǔ)充。例如：您可以某處配置一個高可用數(shù)據(jù)庫鏡像，然后將主數(shù)據(jù)庫日志傳送到遠(yuǎn)程站點(diǎn)以提供災(zāi)難恢復(fù)。圖24顯示了如何進(jìn)行這種配置。 

圖24：將主數(shù)據(jù)庫日志傳送到遠(yuǎn)程服務(wù)器 

這種方式的優(yōu)點(diǎn)就是：一旦整個站點(diǎn)失敗了，第二個站點(diǎn)上的數(shù)據(jù)還繼續(xù)可用。但是，如果數(shù)據(jù)庫鏡像失敗了，從Server B到遠(yuǎn)程備用服務(wù)器的日志傳送通常必須重新開始。 其它使用日志傳送補(bǔ)充數(shù)據(jù)庫鏡像的場景就是作為主服務(wù)器的本地備用，主服務(wù)器的數(shù)據(jù)庫鏡像會話用于災(zāi)難恢復(fù)。此時，數(shù)據(jù)庫鏡像會話運(yùn)行在高性能操作模式下，遠(yuǎn)程站點(diǎn)的鏡像服務(wù)器作為遠(yuǎn)程備用服務(wù)器。 

 
圖25：通過主數(shù)據(jù)庫日志傳送的方式來保留所有的事務(wù) 

在高性能模式中存在的數(shù)據(jù)丟失，如果主服務(wù)器失敗并且使用強(qiáng)制恢復(fù)服務(wù)的方式恢復(fù)了鏡像服務(wù)器。如果您正在對舊的主服務(wù)器進(jìn)行日志傳送，并且如果舊的主服務(wù)器事務(wù)日志文件沒有損壞，那么可以對主數(shù)據(jù)庫進(jìn)行“結(jié)尾日志”備份來獲得事務(wù)日志中最后一組記錄。如果備用日志傳輸數(shù)據(jù)庫已經(jīng)應(yīng)用了所有其它的事務(wù)日志備份，您就可以將結(jié)尾日志備份應(yīng)用到備用服務(wù)器，這樣不會丟失舊的主服務(wù)器上的任何數(shù)據(jù)。然后可以對日志傳送備用服務(wù)器中的數(shù)據(jù)和遠(yuǎn)程數(shù)據(jù)庫做個比較，在需要時將丟失的數(shù)據(jù)拷貝到遠(yuǎn)程服務(wù)器。 當(dāng)您對比日志傳輸和數(shù)據(jù)庫鏡像功能時，需要明確的一點(diǎn)就是：對主數(shù)據(jù)庫進(jìn)行數(shù)據(jù)庫和日志備份很重要。將這些日志備份應(yīng)用到的日志傳送服務(wù)器可以對數(shù)據(jù)庫鏡像配置起到補(bǔ)充作用。 

閱讀原文：原文鏈接