SQL SERVER 2005資料庫鏡像（3）

　　因為Server A無法看見見證伺服器Server W或者原先的鏡像夥伴Server B，因此必須進入disconnected狀態並使資料庫不可用。

　　Server B和Server W可以組成quorum。Server B無法看見Server A，因此Server B試圖成為主伺服器並使其資料庫聯機。因為Server W也看不到Server A，因此同意了Server B。 Server B現在有了quorum，擔當起會話的主伺服器角色，然後還原其資料庫。

　　如果恢複通訊連路，Server A能夠看到Server B如今成為主伺服器，並檢測到見證伺服器Server W也認可Server B為主伺服器。Server A將其角色轉換為鏡像伺服器，然後嘗試與新主伺服器同步。同步之後的配置結果如圖15所示。

　　圖15：該情境通訊連路恢複後的版本，資料庫鏡像按反方向進行

　　總結：見證伺服器位於鏡像伺服器的遠端站台上，如果網站間的通訊鏈路中斷，自動的容錯移轉產生。

　　情境 HACL5：兩個網站，見證伺服器位於主伺服器網站

　　在這個高可用情境中，假設將見證伺服器放置在主伺服器所在的同一網站上，如圖16所示，然後兩個網站間的通訊中斷了。

　　圖16：主伺服器/見證伺服器和鏡像伺服器之間的通訊中斷

　　在這種情況下，負責鏡像資料庫的Server B被主伺服器和見證伺服器孤立。

　　Server A和Server W繼續組成quorum，因此Server A保持其資料庫為主要資料庫。

　　但是，Server A同時將資料庫設定成disconnected狀態，因為它無法看到Server B也不可能進行資料轉送。Server B也無法看到Server A，因此也進入disconnected狀態。配置結果如圖17所示。

　　圖17：該情境中通訊失敗導致兩個夥伴為disconnected狀態

　　Server A繼續接受事務但無法截斷交易記錄記錄。如果迅速恢複了鏈路，鏡像會話還可以重新同步並返回到初始操作狀態。

　　總結：見證伺服器和主伺服器位於同一網站，鏡像伺服器位於遠端站台，網站之間的通訊中斷不會產生自動的容錯移轉。

　　總結：高可用情境中通訊連路中斷

　　在使用三台獨立伺服器的高可用配置中，有三條獨立的通訊連路。

　　◆主伺服器/鏡像伺服器出現通訊失敗，沒有自動的容錯移轉會發生。

　　◆主伺服器/見證伺服器首先出現通訊失敗，隨後主伺服器/鏡像伺服器通訊中斷 ，自動的容錯移轉將發生。恢複鏈路將繼續反方向的資料庫鏡像。

　　◆鏡像伺服器/見證伺服器通訊失敗，沒有自動的容錯移轉會發生。

　　在只有一條通訊連路的高可用配置模式中，見證伺服器駐留在主伺服器或者鏡像伺服器所在網站上。

　　◆見證伺服器駐留在鏡像伺服器的遠端站台上，如果網站之間的通訊鏈路中斷，那麼自動的容錯移轉將發生。

　　◆見證伺服器和主伺服器位於同一網站上，鏡像伺服器在遠端站台，網站之間的通訊中斷不會導致自動的容錯移轉發生。

　　高保護方案

　　高保護模式配合safety FULL一起工作，但沒有見證伺服器。因為鏡像配置中只包括主要資料庫伺服器和鏡像資料庫伺服器，因此只有一條通訊連路。這使情境數量大大降低。

　　情境1：高保護操作模式只包括兩個SERVER執行個體，主伺服器和鏡像伺服器。由於沒有見證伺服器，自動的容錯移轉師不可能的。伺服器之間僅有一條通訊連路會中斷，導致配置結果如圖18所示。

　　圖19：高保護情境中如果鏡像伺服器不可用 ，那麼主要資料庫不受影響

　　情境3：高保護情境中如果主要資料庫不可用，那麼鏡像資料庫必須繼續擔任鏡像，但進入disconnected狀態，如圖20所示。

　　圖20：高保護情境中如果主要資料庫不可用，那麼鏡像資料庫進入disconnected狀態

　　因為高保護操作模式使用safety FULL，因此任何破壞都導致主要資料庫比可用，而鏡像資料庫繼續維持recovering狀態：沒有資料庫是聯機的。其結果是：該模式對於高可用性需求而言不是一個好的解決方案，因此更適合作為一種臨時方案，如必須將見證伺服器移除一小段時間。

　　高效能方案

　　高效能操作模式配合safety OFF一起工作。 沒有見證伺服器角色。因為鏡像配置中只包括主要資料庫伺服器和鏡像資料庫伺服器，因此只有一條通訊連路。儘管類似於高保護模式，但由於safety設定為OFF，因此其行為與高保護模式並不相同。

　　情境1：在高效能操作模式中使用兩個SQL SERVER執行個體。一個負責主要資料庫另一個負責鏡像資料庫。因此伺服器之間只有一條通訊連路並且可能中斷，導致如圖21所示的配置結果。

　　圖21：高效能情境中通訊失敗，兩個夥伴均進入disconnected狀態，但是主要資料庫依然可用

　　由於safety設定為OFF， Server A不需要quorum就可以使資料庫保持為可用狀態。因此儘管已經進入disconnected狀態，主伺服器還可以繼續接受使用者活動。如果通訊恢複，那麼鏡像資料庫將嘗試追趕主要資料庫但無法做到，或者出現redo錯誤，如果它不能找回所有丟失的事務。

　　情境2：在高效能情境中，如果鏡像資料庫不可用，那麼主要資料庫結果顯示在圖22中。

　　圖22：如果在高效能模式下鏡像伺服器不可用，主要資料庫不受影響

　　由於safety設定為OFF，因此主要資料庫依然可用。

　　情境 3：如果在高保護模式下主要資料庫不可用，那麼鏡像資料庫依然作為鏡像，但將被斷開，如圖23所示。

　　圖23：如果主伺服器不可用，那麼Server B不會受到影響，但是進入disconnected狀態

　　高效能操作模式和高保護模式一樣，沒有自動的容錯移轉。由於safety設定為OFF，當鏡像伺服器不可用時，主伺服器將保持其資料庫為可用。同樣由於safety設定為OFF，不保證事務一定到達鏡像資料庫。如果強制容錯移轉到鏡像伺服器，那麼有些事務可能會因此丟失。

　　實現資料庫鏡像

　　可以在SQL SERVER 2005 Books Online，資料庫鏡像主題的“How To”中找到實現資料庫鏡像的基本資料。在白皮書的這一部分，我們來研究實現資料庫鏡像的一個特殊樣本以及最佳實務。

　　監視資料庫鏡像

　　通過在SQL SERVER 2005 Management Studio的Object Explorer中檢查主要資料庫和鏡像資料庫，可以查明每個資料庫鏡像夥伴的狀態。如果主要資料庫和鏡像資料庫是同步的，那麼Object Explorer就在主要資料庫名稱的後面附加一個（Principal， Synchronized）訊息，在鏡像伺服器名稱的旁邊附加一個（Mirror， Synchronized）。可以在主伺服器上彈出的資料庫 Properties對話方塊中觀察Mirroring頁面下方的狀態框，從而檢查資料庫鏡像會話的狀態。（資料庫 Properties對話方塊不會在鏡像伺服器上開啟）。

　　還可以查詢資料庫鏡像目錄檢視sys.database_mirroring和sys.database_mirroring_witnesses（更多關於使用目錄檢視檢查鏡像會話中資料庫狀態的資訊，請參閱該白皮書前面資料庫動態部分的“Database Mirroring Catalog View Metadata”。SQL SERVER Books Online中也包含了目錄檢視的完整文檔。）

　　資料庫鏡像效能計數器

　　可以使用效能計數器監視資料庫鏡像會話中鏡像夥伴之間的網路流量。 SQL Server Database Mirroring對象包含了大量有用的效能計數器來監視主伺服器和見證伺服器。（參閱SQL Server Books Online中的"Monitoring Database Mirroring"）

　　可以在每個資料庫上設定Database Mirroring對象。如果需要在一台伺服器上監視不止一個資料庫，那麼既可以單獨監視某個資料庫的活動，也可以監視所有資料庫的全部活動。

　　對於主伺服器，Log Bytes Sent/sec 計數器指示主伺服器發送日誌資料到鏡像伺服器的速率，而Log Send Queue指示在某個給定時間點交易記錄緩衝區中有多少位元組要發送到鏡像伺服器。隨著交易記錄記錄從主伺服器發送到鏡像伺服器，主伺服器的發送隊列將逐漸縮小，但也會隨著新的日誌記錄進入日誌緩衝區而增長。主伺服器上的Transaction Delay 計數器指示主伺服器由於等待鏡像伺服器關於日誌接收的確認訊息導致的延遲。主伺服器上的Sent/sec計數器與主伺服器給鏡像伺服器發送的資料頁面有關。

　　在鏡像伺服器上，Log Bytes Received/sec指示鏡像伺服器和主伺服器之間相差多少。（見上面Log Bytes Sent/sec 計數器）。Redo Queue 計數器指示redo隊列的大小。鏡像伺服器在redo階段使用redo隊列重新執行來自主伺服器的事務。Redo Bytes/sec指示鏡像伺服器執行redo隊列中事務的速率。

　　對於每個夥伴伺服器，Sends/sec和Receives/sec 計數器指示有多少個發送和接收動作Bytes Sent/sec和Bytes Received/sec 計數器指示在每個夥伴伺服器上那些發送和接收動作包含的位元組數。

　　估計Redo和Catch-up時間

　　如果出現容錯移轉，可以使用Redo Queue和Redo Bytes/sec來估算鏡像資料庫完成redo並成為可用狀態需要花費的時間。使用下面的簡單公式進行計算：

　　估計的redo時間（秒） =

　　(Redo Queue)/(Redo Bytes/sec)

　　類似的，如果主伺服器上的活動領先於鏡像伺服器，可以使用Log Send Queue和Log Bytes Received/sec 計數器估算鏡像伺服器追趕上主伺服器需要花費的時間。 下面給出了計算公式：

　　估計的catch up時間（秒） =

　　(Log Send Queue)/( Log Bytes Received /sec)

　　Profiler事件

　　SQL Server 2005 Profiler包含了一個資料庫鏡像事件類別。Database:Database Mirroring State Change事件將記錄被監視伺服器是否發生了狀態改變。（參見SQL Server Books Online主題“Database Mirroring State Change Event Class”）。當使用這個事件類別時包含Database Name和State來會對您大有協助。可以使用該事件通知您資料庫鏡像會話中的任何狀態改變。

　　資料庫鏡像排錯

　　資料庫鏡像最容易出錯的地方就是配置過程和運行過程。

　　排除設定錯誤

　　如果已經設定了資料庫鏡像但是無法啟動，那麼重新開始所有配置步驟。

　　1.確認鏡像伺服器儘可能接近主要資料庫。如果嘗試啟動資料庫鏡像時收到了以下的錯誤訊息：

　　遠程“AdventureWorks”資料庫沒有前滾到本機資料庫日誌副本中包含的一個時間點。（Microsoft SQL SERVER， 錯誤：1412）

　　說明鏡像資料庫滯後於主要資料庫。需要將主要資料庫的交易記錄備份應用到鏡像資料庫（使用NORECOVERY），從而使鏡像資料庫恢複到某個時間點，並可以從此時間點開始接收來自主要資料庫的日誌記錄。

　　2.確認每個伺服器的SQL SERVER Windows服務帳戶彼此相互信任。如果伺服器所在的域沒有建立信任關係，那麼確保認證是正確的。

　　3.通過查詢sys.database_mirroring_endpoints目錄檢視，確認不僅定義而且啟動了endpoint：

SELECT * FROM sys.database_mirroring_endpoints;

　　確認使用了正確的完全限定電腦名稱以及正確的連接埠號碼。如果在一台物理伺服器的多個執行個體之間配置鏡像，那麼連接埠號碼就必須是唯一的。SQL SERVER服務登陸帳號需要CONNECT到endpoint的存取權限。

　　最後，確認為伺服器定義了正確的endpoint角色。

　　4.確認在ALTER DATABASE命令中指定了正確的鏡像夥伴名稱。可以在主伺服器和鏡像伺服器的sys.database_mirroring目錄檢視中（以及高可用模式下的sys.database_mirroring_witnesses witnesses）檢查鏡像夥伴名稱。

　　排除執行階段錯誤

　　如果資料庫鏡像設定正確，然後在運行過程中出現了錯誤，請檢查會話的目前狀態。如果由於錯誤而使鏡像處於SUSPENDED狀態，就可能在鏡像伺服器上產生redo錯誤。檢查並確認鏡像伺服器上有足夠的磁碟空間用於redo（資料檔案所在分區的剩餘空間）和日誌hardening（記錄檔所在分區的剩餘空間）。當您準備重新啟動會話時，使用ALTER DATABASE來重新開始會話。

　　如果無法串連到主要資料庫，最可能的原因就是safety設定為FULL並且主伺服器無法組成quorum。這種情況能夠發生，例如，如果系統在高保護模式下運行（safety為FULL但沒有見證伺服器），鏡像伺服器又斷開了和舊的主伺服器的聯絡。可以在鏡像伺服器上使用下面的命令強制鏡像伺服器進行恢複：

ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

　　問題就在於一旦恢複了鏡像資料庫，鏡像伺服器將成為主伺服器但卻無法形成quorum，因此無法服務於資料庫。如果那樣的話，只要把safety設定為OFF就可以允許它服務於資料庫了。

　　安全性與效能

　　資料庫鏡像的效能是關於活動類型和事務安全性的一個函數。

　　傳輸日誌到鏡像伺服器會影響主伺服器效能。資料庫鏡像給主伺服器帶來的開銷是關於活動類型的一個函數。資料庫鏡像在多使用者以及大量長事務的系統上操作效能最好，因為資料庫伺服器正常的事務活動會掩蓋傳輸日誌記錄到鏡像伺服器的引起的開銷。如果單個使用者順序執行大量短事務，那麼資料庫鏡像給每個事務造成的開銷將十分顯著。

　　主伺服器效能同樣受Safety設定的影響。當safety設定為FULL時，主伺服器必須等待鏡像伺服器表示已經收到日誌記錄的確認資訊，才可以將事務提交訊息返回給用戶端。如果有大量的使用者和大量的長事務，那麼這種等待導致的開銷並不明顯。單線程系統和包含許多小事務的系統在safety OFF時可以啟動並執行更好。

　　因為鏡像伺服器連續不斷地重新執行從主伺服器接收的資料更新事務，鏡像伺服器的資料緩衝將變得'hot'。 換句話說，就是使用那些和主伺服器類型相同的資料更新操作所涉及的資料頁面和索引頁面來加工緩衝。為了使鏡像伺服器的緩衝更接近於主伺服器緩衝，資料庫鏡像將一個SELECT提示也傳遞給鏡像伺服器，從而可以在鏡像伺服器重建用於資料查詢的緩衝內容。這樣可以協助鏡像伺服器更接近於主伺服器，同時減少容錯移轉時剩餘的redo時間。很明顯，鏡像伺服器上任何其他活動，包括對資料庫快照集的查詢也會影響緩衝的狀態，並因此增加容錯移轉時完成日誌redo的時間。

　　測試資料庫鏡像

　　當設定自己的系統來測試資料庫鏡像時，有許多選項可用。所有資料庫鏡像都要求在資料庫鏡像會話中的伺服器必須是不同的SQL SERVER執行個體。因此可以在一台物理伺服器上配置和測試資料庫鏡像，如果您安裝了多個SQL SERVER 2005關聯式資料庫引擎。也可以在一台虛擬伺服器上測試多個執行個體，但是在物理伺服器上進行測試更加可信。

　　進行資料庫鏡像的負載和壓力測試時需要不同的物理伺服器。一台伺服器上的兩個或者三個執行個體可能會消耗不切實際的伺服器資源。此外伺服器之間的網路連接品質也同樣重要。主伺服器和鏡像伺服器之間的網路越好，日誌記錄和訊息傳送的速度就越快。

　　最逼真的測試就是在一台真正的目標伺服器或者實驗台上進行，並且和最終系統的物理屬性完全相同。當您在一台伺服器上測試多個執行個體時，只能通過停止執行個體或者關機的方式來類比資料庫鏡像中伺服器失敗的效果。使用多台物理伺服器時，就可以通過斷開網線的方式來測試網路連接失敗的效果。

　　下面的實踐能夠協助您建立測試環境：

　　◆要測試伺服器失敗，關閉SQL SERVER執行個體，通過SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。

　　◆要測試通訊失敗，拔掉伺服器上的網線。

　　◆要測試資料庫失敗，停止SQL SERVER服務，重新命名。mdf檔案，然後再重啟SQL SERVER。

　　◆要導致鏡像資料庫的redo錯誤， 為主要資料庫添加一個新檔案，將檔案存放在主伺服器存在但鏡像伺服器中不存在的分區中。

　　◆另一種導致鏡像伺服器redo錯誤的方法就是強制鏡像伺服器的資料庫檔案空間不足。

　　◆要迫使主伺服器的資料庫停工，強制主要資料庫資料檔案空間不足。

　　◆要導致主要資料庫或鏡像資料庫日誌緩衝區hardening失敗，強制記錄檔空間不足。

　　為容錯移轉準備鏡像伺服器

　　資料庫鏡像其實就是資料庫到資料庫的聯絡。只有資料庫中的資料會通過日誌記錄從主要資料庫發送到鏡像資料庫。就像記錄傳送和複製一樣，必須準備待命伺服器和鏡像資料庫，以便出現故障時可以完全接管主要資料庫的工作。當您準備鏡像伺服器時，應該從以下幾個層面進行考慮。

　　在物理伺服器層面，確保待命伺服器和主伺服器擁有相同的或者儘可能接近的物理CPU和記憶體配置，否則待命伺服器在容錯移轉後將無法勝任工作。此外可能還有一些支援應用程式、監視器、以及支援程式啟動並執行可執行檔等等，都需要在鏡像伺服器上進行配置。

　　在SQL SERVER層面，確保待命伺服器和主伺服器擁有相同的SQL SERVER配置（例如，AWE、最大並行化程度）。但最重要的就是登陸帳戶和賬戶許可權。主伺服器上所有啟用的SQL SERVER登陸帳戶都必須同時存在鏡像伺服器上，否則一旦出現容錯移轉，那麼應用程式將無法使用這些登陸帳戶串連到新的主伺服器上。可以使用SQL SERVER整合服務的Transfer Logins任務將登陸帳戶和密碼從一台伺服器拷貝到另一台伺服器，但您還必須為這些登陸帳戶設定資料庫許可權。如果將登陸帳戶傳輸到另一個不同的域，那麼可能出現不匹配色的SID，需要您去匹配它們。

　　SQL SERVER主伺服器上可能還存在大量的支援對象需要被轉移到待命伺服器上：SQL Agent作業和警報、SQL SERVER整合服務包、支援資料庫、串連伺服器的定義、備份裝置、維護計劃、SQL Mail或者資料庫設定、可能還有分散式交易協調器（MSDTC）設定，等等。

　　當SQL Agent作業被傳輸到待命伺服器後，大部分將被迫設定為禁用。一旦出現容錯移轉，需要您啟用這些作業。

　　容錯移轉後，如果應用程式使用SQL SERVER驗證，還需要將SQL SERVER新的主伺服器上的登陸帳戶解析成新的主伺服器上的資料庫使用者。完成該任務最好的工具就是預存程序sp_change_users_login。

　　多資料庫的問題

　　許多應用程式使用一台伺服器上的多個資料庫。多個資料庫可以被一個應用程式引用，也可能被多個應用程式引用。但是資料庫鏡像每次只能在一個資料庫上工作。當您設計資料庫鏡像時需要考慮這一點。

　　如果您希望高可用模式，那麼最適合的就是一個應用程式配合一個資料庫。當自動的容錯移轉發生時應用程式不再需要主伺服器上的任何資料庫。考慮如果多個資料庫在一台伺服器上並且操作在高可用模式下，那麼可能出現什麼情況呢？如果一台物理伺服器掉電了，或者一個SQL SERVER執行個體失敗了，或者網路通訊失敗了，那麼所有資料庫將自動容錯移轉到待命伺服器，而他們的鏡像將成為新的主要資料庫。如果見證伺服器可用，應用程式可以串連到新的主要資料庫。但是如果某個資料庫由於磁碟失敗而產生了分頁，因此只有這個資料庫被容錯移轉，那麼會發生什麼呢？如果那樣的話，應用程式就有可能無法串連到所有正確的資料庫。

　　因此依賴多資料庫的應用程式不適合使用資料庫鏡像的高可用模式。您可以將safety設定成OFF，實際上就是不使用自動容錯移轉，但您必需使用某種高效的方式保持和其它資料庫伺服器的同步。

　　資料庫鏡像和高可用性技術

　　SQL SERVER 2005現在至少支援四種高可用性技術，儘管不同技術相互之間有些功能重疊，但每種技術都有各自的優缺點。這些技術是：

　　◆資料庫鏡像 – 為了便於討論，我們將考慮高可用操作模式以及FULL safety和見證伺服器。

　　◆容錯移轉叢集 – 最典型的配置就是2節點的Windows容錯移轉叢集配置一個SQL SERVER執行個體。

　　◆記錄傳送 – 採用SQL SERVER內建的記錄傳送和一個獨立的監視伺服器。

　　◆事務複製 – 一台散發者和一台訂閱伺服器，如果發行伺服器失敗，訂閱伺服器作為待命伺服器。

　　在這一部分我們將比較這四種技術的準系統，然後深入探討怎樣對資料庫鏡像進行補充或者提供一個更好的解決方案。

　　下表顯示了四種技術的幾個高可用性功能。

　　表14：比較SQL SERVER 2005高可用性技術

類別	可用性功能	資料庫鏡像 (HA模式)	容錯移轉叢集	記錄傳送	事務複製
容錯移轉特性	待命伺服器類型	Hot	Hot	Warm	Hot
自動角色轉換	是	是	需要自己編寫代碼	需要自己編寫代碼
容錯移轉保留已提交的工作	是	是	否	否
容錯移轉類型	自動和手動	自動和手動
容錯移轉過程資料庫停工時間	少於10秒	30秒+ 資料庫還原	可變的	可變的
物理配置	冗餘的儲存位置	是	否（共用磁碟）	是	是
硬體需求	標準伺服器	群集驗證的伺服器和儲存	標準伺服器	標準伺服器
物理距離限制	沒有	100米	沒有	沒有
其它伺服器角色	見證伺服器	沒有	監視伺服器	散發者
管理	複雜性等級	低	高	低	中等
待命伺服器的可訪問性	通過資料庫快照集，效能可能受到影響	不可訪問	R/O但是與資料庫還原不相容	允許唯讀工作
多待命伺服器	無	無	是	是
待命伺服器載入延遲	沒有	沒有	有延遲	沒有
可用性範圍	資料庫	伺服器執行個體	資料庫	資料庫
客戶訪問	客戶重新導向	由ADO。NET和 SQL Native Client提供支援	不需要，使用虛擬IP	需要自己編寫代碼	需要自己編寫代碼

　　上表總結了所有四種高可用技術的特性。下一部分將進行更詳細的比較。

　　資料庫鏡像和群集

　　資料庫鏡像和容錯移轉叢集最主要的差異就是提供了不同層級的冗餘。資料庫鏡像提供的保護是資料庫層級的，而群集提供的保護是伺服器執行個體層級的。另一個主要差別就是在資料庫鏡像中，主伺服器和鏡像伺服器是獨立的 SQL SERVER執行個體，兩個執行個體有不同的名稱；而群集中的 SQL SERVER執行個體則使用相同的虛擬伺服器名稱和IP地址，而且無論哪個節點主持叢集執行個體，虛擬伺服器名稱和IP地址始終保持不變。

　　如果您需要在伺服器一級的資料庫保護（例如，您的應用程式需要同時訪問統一伺服器上的多個資料庫），容錯移轉叢集將是更適合的選擇。但是，如果每次只須為一個資料庫提供可用性，那麼資料庫鏡像具有更多優勢。

　　資料庫鏡像不像群集那樣需要專門的硬體，也沒有共用儲存介質失敗的潛在危險。資料庫鏡像可以在最短時間內讓備用資料庫開始提供服務，其速度快於任何其它的高可用技術。此外，資料庫鏡像能夠與ADO。NET和SQL Native Access Client很好的配合在一起，從而實現用戶端的容錯移轉。

　　不能在群集中使用資料庫鏡像，但是可以考慮使用資料庫鏡像作為一種手段來建立群集資料庫執行個體的一個熱備用份。這樣做需要特別小心，因為群集的容錯移轉時間長於資料庫鏡像的逾時值，高可用模式下的鏡像會話將對群集的容錯移轉做出反應，認為這是主伺服器失敗了，然後會將叢集節點設定為鏡像狀態。

　　資料庫鏡像和事務複製

　　資料庫鏡像和事務複製都建立在讀取原始伺服器交易記錄的基礎上，但此後採用的技術就截然不同了。（更多關於事務複製的細節，請參閱SQL SERVER Books Online中的相關主題）。事務複製多用於配置高可用性，因為它可以將發行資料庫中的使用者事務在幾秒鐘內遞送到訂閱資料庫中。資料庫鏡像的優點是速度對於甚至快於複製，但需要遞送所有的資料庫事務，而不單單是與使用者表相關的事務。

　　事務複製技術適合於將資料擴充到多個訂閱者。事務複製的訂閱資料庫通常是唯讀，如果需要近乎即時的資料訪問，那麼事務複製是理想的候選者。

　　資料庫鏡像與事務複製相容，如果需要維持發行資料庫的一個熱備份，資料庫鏡像就是非常有用的一種方式。其它用於保護複製發行商的方式，例如記錄傳送無法在發行商自己的訂閱者之前維持發行商的待命伺服器。換句話說，事務複製將交易記錄遞送給訂閱者的速度要快於交易記錄備份。正是因為資料庫鏡像速度很快，因此特別適合用於維持發行資料庫的熱備份。

　　但是如果發行伺服器失敗，就必須手動使用還原好的備用資料庫重建立立發行商，然後重新串連到散發者，， 使用日誌傳輸維護髮行商伺服器的待命伺服器所必須做的工作與此相同。

　　資料庫鏡像和日誌傳輸

　　資料庫鏡像和日誌傳輸都依賴SQL SERVER資料庫提供的恢複和還原功能。在資料庫鏡像中，鏡像資料庫始終保持recovering狀態，連續不斷地還原來自主要資料庫的交易記錄。而日誌傳輸中的備用資料庫則周期性地應用交易記錄備份中的事務。因為bulk-logged資料被附加到交易記錄備份中，因此記錄傳送可以工作在bulk-logged恢複模型下。資料庫鏡像則不同，它直接將日誌記錄從主要資料庫傳送到鏡像資料庫中而且不能遞送bulk-logged資料。

　　很多情況下資料庫鏡像可以提供與記錄傳送相同的資料冗餘以及更高的可用性和自動容錯移轉。但是，如果應用程式依賴一台伺服器上的多個資料庫，那麼記錄傳送是有效方式（參閱前一部分介紹的“Multi-Database Considerations”）。

　　此外，某些資料庫鏡像情境中還可以通過記錄傳送作為補充。例如：您可以某處配置一個高可用資料庫鏡像，然後將主要資料庫記錄傳送到遠端站台以提供災難恢複。圖24顯示了如何進行這種配置。

　　圖24：將主要資料庫記錄傳送到遠程伺服器

　　這種方式的優點就是：一旦整個網站失敗了，第二個網站上的資料還繼續可用。但是，如果資料庫鏡像失敗了，從Server B到遠程待命伺服器的記錄傳送通常必須重新開始。

　　其它使用記錄傳送補充資料庫鏡像的情境就是作為主伺服器的本地備用，主伺服器的資料庫鏡像會話用於災難恢複。此時，資料庫鏡像會話運行在高效能操作模式下，遠端站台的鏡像伺服器作為遠程待命伺服器。

　　圖25：通過主要資料庫記錄傳送的方式來保留所有的事務

　　在高效能模式中存在的資料丟失，如果主伺服器失敗並且使用強制恢複服務的方式恢複了鏡像伺服器。如果您正在對舊的主伺服器進行記錄傳送，並且如果舊的主伺服器交易記錄檔沒有損壞，那麼可以對主要資料庫進行“結尾日誌”備份來獲得交易記錄中最後一組記錄。如果備用日誌傳輸資料庫已經應用了所有其它的交易記錄備份，您就可以將結尾記錄備份應用到待命伺服器，這樣不會丟失舊的主伺服器上的任何資料。然後可以對記錄傳送待命伺服器中的資料和遠端資料庫做個比較，在需要時將丟失的資料拷貝到遠程伺服器。

　　當您對比日誌傳輸和資料庫鏡像功能時，需要明確的一點就是：對主要資料庫進行資料庫和記錄備份很重要。將這些記錄備份應用到的記錄傳送伺服器可以對資料庫鏡像配置起到補充作用。

　　結論

　　資料庫鏡像是SQL SERVER 2005中的新技術，可以實現高可用性和高效能的可資料庫冗餘解決方案。在資料庫鏡像中，當主要資料庫的交易記錄緩衝區被寫入磁碟時（硬化的），交易記錄記錄就從主要資料庫直接發送到鏡像資料庫。這種技術可以使鏡像資料庫幾乎和主要資料庫的資料保持同步，同時不會丟失提交的資料。在導可用性操作模式中，如果主伺服器失敗了，那麼鏡像伺服器將自動成為新的主伺服器並還原資料庫。使用新的ADO．NET或者SQL Native Access Client驅動程式，應用程式還可以從自己的伺服器上進行自動的容錯移轉。資料庫鏡像成為SQL SERVER 2005提供的高可用技術家族中的新成員。