在資料庫鏡像會話中，主體與鏡像角色通常可以在稱為角色切換的過程中互換。 在角色切換中，鏡像伺服器會做為主體伺服器的 故障轉移夥伴 ，接管主體角色、復原其資料庫複本，並將其上線作為新的主體資料庫。 當可用時，前主體伺服器會擔任鏡像角色，而其資料庫會變成新的鏡像資料庫。 這些角色有可能來回切換，用來應對多次故障或滿足管理需求。
備註
本主題假設您已熟悉資料庫鏡像作業模式。 如需詳細資訊，請參閱 Database Mirroring Operating Modes。
下圖顯示鏡像合作夥伴 Partner_A 和 Partner_B 如何在一系列自動或手動故障轉移中切換主控和鏡像角色。
這很重要
在角色切換之後，必須先將原先在主體資料庫上執行的作業重新建立到新的主伺服器上，才能在該處執行。 如需詳細資訊，請參閱角色切換后登入和作業的管理（SQL Server）。
有三種類型的角色切換存在：自動故障轉移、手動故障轉移和強制服務（可能遺失數據）。 每個表單的支援取決於會話的作業模式。
備註
如果您不熟悉這些作業模式，請參閱 資料庫鏡像作業模式。
手動故障轉移
高安全性模式支援手動故障轉移。 每當資料庫同步時，資料庫擁有者就可以啟動手動故障轉移。
手動故障轉移僅供系統管理之用。 如需詳細資訊，請參閱本主題稍後的手動故障轉移內容。
自動容錯移轉
在見證存在的情況下，高安全性模式支援自動故障轉移。 只有在見證和鏡像伺服器仍然彼此連線且資料庫已經同步處理時，才會在主體伺服器上發生自動故障轉移。 如需詳細資訊，請參閱本主題稍後的 自動故障轉移。
強制服務 （可能遺失資料）
強制服務在未設定見證的高安全性模式以及高效能模式下均受支持。 在主要伺服器失去功能時，資料庫擁有者可以藉由強制將服務移轉至鏡像伺服器（這可能會導致數據遺失）來提供資料庫。
備註
我們建議在高效能模式中將 WITNESS 屬性設定為 OFF。 否則，若要讓資料庫上線，鏡像伺服器必須連線到見證。
如需詳細資訊，請參閱本主題稍後的強制服務（可能遺失數據）。
下表摘要說明每個作業模式下支援哪些形式的故障轉移。
| 高效能 | 沒有見證的高安全性模式 | 具有見證的高安全性模式 | |
|---|---|---|---|
| 自動故障轉移 | 否 | 否 | 是的 |
| 手動切換 | 否 | 是的 | 是的 |
| 強制服務 | 是的 | 是的 | 否 |
角色切換之後，這兩個夥伴都必須有特定元數據，以確保所有資料庫使用者都可以存取新的主體資料庫。 此外，必須在新的主體伺服器上建立備份作業，以確保資料庫會依定期排程繼續備份。 如需詳細資訊，請參閱角色切換后登入和作業的管理（SQL Server）。
在角色切換期間，資料庫鏡像服務逾期的時間量取決於角色切換的類型和原因。 如需詳細資訊，請參閱 估計角色切換期間服務中斷 （資料庫鏡像） 。
手動故障轉移
手動故障轉移會中斷用戶端與資料庫的連線，並反轉夥伴角色的分工。 只有高安全性模式支援手動故障轉移。
在升級期間維護可用性
資料庫管理員可以使用手動故障轉移來升級硬體或軟體，而不會犧牲可用性。 若要使用資料庫鏡像進行軟體升級，鏡像伺服器和/或系統必須已經收到升級。
備註
資料庫鏡像應該能夠進行滾動升級，但這不保證，因為未來的變更未知。 如需詳細資訊，請參閱 在升級伺服器實例時將鏡像資料庫的停機時間降到最低。
下圖說明當您升級資料庫伺服器實例時，使用手動故障轉移來維護資料庫可用性的 實例。 升級完成時，系統管理員可以選擇性地切換回原始伺服器實例。 當系統管理員想要停止鏡像會話並使用其他地方的鏡像伺服器時，這會很有用。 如此一來，在更新一系列資料庫伺服器實例時，可以重複使用單一伺服器實例。
手動故障轉移的必要條件
手動故障轉移需要將交易安全性設定為 FULL（也就是高安全性模式）。 當夥伴已連接而且資料庫已經同步處理後，就會支援手動容錯移轉。
手動故障轉移的運作方式
手動故障轉移會起始下列動作順序：
主體伺服器會中斷用戶端與主體資料庫的連線、將記錄的尾端傳送至鏡像伺服器，以及在準備切換至鏡像角色時，將鏡像狀態設定為SYNCHRONIZING。
鏡像伺服器會將從主體收到的最後一筆記錄的記錄序號（LSN）記錄為故障轉移 LSN。
備註
若要檢視此 LSN，請從 sys.database_mirroring （Transact-SQL） 選取 [mirroring_failover_lsn] 資料行。
如果重做佇列中有記錄檔在等候，鏡像伺服器將完成鏡像資料庫的向前復原。 所需的時間量取決於系統的速度、最近的工作負載，以及重做佇列中的記錄數量。 針對同步作業模式，故障轉移時間可以藉由限制重做佇列的大小來調節。 不過，這可能會導致主體伺服器變慢，以允許鏡像伺服器跟上。
備註
若要瞭解重做佇列的目前大小，請在資料庫鏡像性能物件中使用 Redo Queue 性能計數器（如需詳細資訊，請參閱 監視資料庫鏡像 （SQL Server） 。
鏡像伺服器會變成新的主體伺服器，而先前的主體伺服器會變成新的鏡像伺服器。
新的主體伺服器會復原任何未認可的交易，並將其資料庫複本聯機為主體資料庫。
先前的校長會擔任鏡像角色，而先前的校長資料庫會變成鏡像資料庫。 新的鏡像伺服器會將新的鏡像資料庫快速重新同步至新的主體資料庫。
備註
一旦新的鏡像伺服器重新同步處理資料庫，故障轉移就會再次發生，但方向相反。
故障轉移之後，用戶端必須重新連線到目前主要的資料庫。 如需詳細資訊，請參閱將用戶端連線到資料庫鏡像會話（SQL Server）。
若要起始手動故障轉移
自動故障轉移
只有在使用具有見證的高安全性模式執行的資料庫鏡像會話中，才支援自動故障轉移（高安全性模式與自動故障轉移）。 在具有自動故障轉移的高安全性模式中，當資料庫同步處理後，如果主資料庫無法使用，就會發生自動故障轉移。 自動故障轉移會導致鏡像伺服器接管主體伺服器的角色，並將其資料庫複本上線為主體資料庫。 要求資料庫同步可防止在故障轉移期間資料遺失，因為主資料庫上提交的每筆交易也會在鏡像資料庫上提交。
這很重要
若要透過自動容錯移轉提升可靠性，鏡像資料庫和主體資料庫必須位於不同的電腦上。
自動故障轉移所需的條件
自動容錯移轉必須符合下列條件：
資料庫鏡像會話必須以高安全性模式執行，而且必須擁有見證。 如需詳細資訊，請參閱 Database Mirroring Operating Modes。
鏡像資料庫必須已經同步。 這可確保傳送至鏡像伺服器的所有記錄都已寫入磁碟。
主要伺服器已失去與其他資料庫鏡像配置的通訊，而鏡像和見證則保持仲裁記錄。 不過，如果所有伺服器都失去通訊，而且見證伺服器和鏡像伺服器稍後再次恢復通訊，則不會發生自動故障轉移。
備註
如需詳細資訊，請參閱仲裁：見證影響資料庫可用性的方式 (資料庫鏡像)。
鏡像伺服器偵測到主體伺服器的遺失。
鏡像伺服器如何偵測主體伺服器的失敗，取決於它是硬式或軟式失敗。 如需詳細資訊，請參閱 資料庫鏡像期間可能發生的失敗。
自動故障轉移的運作方式
在上述情況下，自動故障轉移會起始下列動作順序：
如果主體伺服器仍在執行中，它會將主體資料庫的狀態變更為 DISCONNECTED，並將所有客戶端與主體資料庫中斷連線。
見證和鏡像伺服器記錄主伺服器不可用。
如果有任何記錄檔在重做佇列中等候，鏡像伺服器就會進行鏡像資料庫的前滾。
備註
套用記錄所需的時間量取決於系統的速度、最近的工作負載，以及重做佇列中的記錄數量。
先前的鏡像資料庫將作為新的主體資料庫投入使用，復原程序會儘快回滾以清除所有未認可的交易。 鎖定機制將這些交易隔離開來。
當先前的主要伺服器重新加入會話時，它會辨識其故障轉移夥伴現已擁有主要角色。 先前的主伺服器會擔任鏡像伺服器的角色，使其資料庫成為鏡像資料庫。 新的鏡像伺服器會儘快同步處理新的鏡像資料庫與主體資料庫。 一旦新的鏡像伺服器重新同步處理資料庫，故障轉移就會再次發生，但方向相反。
下圖顯示自動故障轉移的單一實例。
最初，所有三部伺服器都已連線（會話具備完全仲裁權）。 Partner_A 是主體伺服器， Partner_B 是鏡像伺服器。 Partner_A （或 Partner_A上的主體資料庫） 變成無法使用。 見證人和Partner_B都承認，即使委託人已不在場，會議仍保有法定人數。 Partner_B 會成為主體伺服器，並將其資料庫複本當做新的主體資料庫使用。 最後， Partner_A 重新連線到會話，並發現 Partner_B 現在擁有主體角色。 Partner_A 然後擔任鏡像角色。
故障轉移之後，客戶端必須重新連線到當前的主資料庫。 如需詳細資訊，請參閱將用戶端連線到資料庫鏡像會話（SQL Server）。
備註
使用Microsoft分散式交易協調器準備但在故障轉移發生時尚未提交的交易，將在資料庫故障轉移之後被視為中止。
停用自動故障轉移（SQL Server Management Studio）
開啟 [ 資料庫屬性][Mirroring ] 頁面，然後選取下列其中一個選項來變更作業模式：
高安全性，無自動故障轉移機制（同步）
在此模式中，資料庫會持續同步化，而且仍然可以手動故障切換。
高效能（非同步）
在此模式中，鏡像資料庫可能會稍微落後主體資料庫，而且無法再進行手動故障轉移。
停用自動故障轉移 （使用 Transact-SQL）
在資料庫鏡像會話的任何時間點，資料庫擁有者可以關閉見證來停用自動故障轉移。
關閉見證功能
-
備註
在保留完整交易安全性的同時關閉見證，讓會話進入高安全性模式，而不需要自動故障轉移。
強制服務 （可能遺失資料）
資料庫鏡像提供強制服務（可能會導致資料遺失）作為災害復原的方法，使您可以使用鏡像伺服器作為熱備援伺服器。 在主伺服器與鏡像伺服器在鏡像會話中中斷連線時，才能強制啟用服務。 因為強制服務可能會遺失數據，所以應該謹慎謹慎使用。
強制服務的支持取決於作業模式和會話的狀態，如下所示：
一般而言，每當主體伺服器中斷連線時，高效能模式支持強制服務。 不過，雖然沒有必要，高效能模式的會話仍然可以有一名見證人。 在此情況下，強制服務會要求鏡像伺服器和見證彼此連線。
在沒有自動故障切換的情況下，高安全性模式支援在主伺服器斷線時強制提供服務。
具有自動故障轉移的高安全性模式支援在鏡像伺服器和見證彼此連線時強制服務，而且兩者都未連線到主體伺服器（只要鏡像伺服器在上次連線至主體時未回復鏡像資料庫）。
只有當您必須立即將服務還原至資料庫，並且願意有遺失數據的風險時，才建議強制服務。 強制服務的效果類似於移除鏡像，但不同之處在於強制服務有助於在恢復鏡像時重新同步資料庫，但代價可能是資料遺失的風險。 強制執行服務會將主要角色順暢地轉移至鏡像資料庫。 鏡像伺服器會擔任主體伺服器的角色，並立即將其資料庫複本傳送給用戶端。 新的主資料庫在沒有鏡像的情況下執行（也就是說，它在外露的情況下執行）。
這很重要
如果主體伺服器只是與資料庫鏡像會話中斷連線，而且仍在執行中，某些用戶端可能會繼續存取原始主體資料庫。 強制服務之前，請務必防止用戶端存取原始主體伺服器。 否則的話，強制服務後，原始主資料庫和當前主資料庫可能會互不相干地進行更新。
強制服務的典型案例
下圖說明強制服務的典型案例（可能遺失數據）。
在此圖中，原本的主伺服器 Partner_A對鏡像伺服器 Partner_B變得無法使用，導致鏡像資料庫中斷連線。 確保客戶端無法使用 Partner_A 之後，資料庫管理員會在 Partner_B上強制服務，並可能遺失數據。 Partner_B 會成為主體伺服器，並使用 未鏡像 的資料庫執行（也就是不具備鏡像）。 此時，用戶端可以重新連線至 Partner_B。
當Partner_A可供使用時，它會重新連線到新的主體伺服器，重新加入會話並假設鏡像角色。 鏡像會話會立即暫停，而新的鏡像資料庫尚未完成同步化。 暫停會話可讓資料庫管理員決定是否要繼續會話，或在極端情況下移除鏡像，並嘗試從先前的主體資料庫打撈數據。 在此情況下，資料庫管理員會選擇繼續資料庫鏡像。 此時， Partner_A 接管鏡像伺服器的角色，並將先前的主體資料庫復原至上次成功同步處理交易的時間點：如果在強制服務之前，未將任何認可的交易寫入鏡像伺服器上的磁碟，它們就會遺失。 Partner_A 然後將新的鏡像資料庫向前移動，應用自從前鏡像伺服器成為新主體伺服器以來，在新主體資料庫上所做的任何變更。
備註
雖然高效能模式不需要見證，但如果已設定見證，則只有在見證目前連線到鏡像伺服器時，才能強制服務。
強制服務的風險
請務必了解強制服務可能會導致數據遺失。 可能會遺失數據，因為鏡像伺服器無法與主體伺服器通訊，因此無法保證兩個資料庫已同步處理。 強制啟動服務會產生新的復原分支。 由於原始主體資料庫和鏡像資料庫位於不同的復原分支上，每個資料庫現在都會包含其他資料庫沒有的數據：原始主體資料庫包含尚未從傳送佇列傳送至先前鏡像資料庫的任何變更（未傳送的記錄檔）：先前的鏡像資料庫包含強制服務之後發生的任何變更。
如果服務因為主體伺服器失敗而強制運作，則潛在的數據遺失取決於失敗前是否未將任何事務歷史記錄傳送到鏡像伺服器。 在高安全性模式下，只有在鏡像資料庫同步處理之前，才可能這樣做。 在高效能模式下，累積的未傳送記錄始終有可能發生。
強制服務的影響部分取決於會話是否有見證：
在沒有見證的情況下，如果合作夥伴之間的連線中斷，可能會強制服務，例如網路連線出現故障而中斷。 如果原始主體伺服器仍在執行中，則兩個夥伴都擁有主體角色。 線上到新主體伺服器的用戶端將會存取目前版本的資料庫，而連接到原始主體伺服器的用戶端將會存取原始主體資料庫。 這種情況會增加數據遺失的可能性。 如果允許夥伴重新連線，原始主體伺服器將變為鏡像角色，並在鏡像暫停之前將其資料庫的狀態變更為「正在復原」。 如果會話繼續，在最近中斷連線時，記錄檔在傳送佇列中的原始主體資料庫上的交易會遺失。 此外，在強制服務之後發生的任何交易也會遺失。
在見證伺服器存在的情況下，如果鏡像伺服器與主伺服器和見證伺服器斷開連線，只要主伺服器和見證伺服器彼此保持連線，主伺服器就會暴露。 如果主體伺服器接著與見證中斷連線，就會停止為資料庫提供服務。 之後，若鏡像伺服器與見證伺服器重新連線，便可以進行強制服務。 如果強制服務，如果原始主體伺服器重新連線，在原始主體伺服器執行時所做的所有變更都會遺失。
如需詳細資訊，請參閱本主題稍後的管理潛在資料遺失。
管理潛在的數據遺失
強制服務之後，一旦前主體伺服器可供使用，假設其資料庫未受損，您就可以嘗試管理潛在的數據遺失。 管理潛在數據遺失的可用方法取決於原始主體伺服器是否已重新連線到其夥伴，並重新加入鏡像會話。 假設原始主體伺服器可以存取新的主體實例，則會自動且透明地重新連線。
原始主體伺服器已重新連線
一般而言，在失敗之後，當原始主體伺服器重新啟動時，它會快速重新連線到其夥伴。 在重新連線時，原始主體伺服器會變成鏡像伺服器。 其資料庫會變成鏡像資料庫，並在會話暫停之前進入復原狀態。 除非您恢復資料庫鏡像，否則鏡像資料庫不會回復。
不過，正在復原的資料庫無法存取中，因此，您不能檢查它以評估若恢復鏡像會遺失哪些數據。 因此，決定是否要繼續或移除鏡像，取決於您是否願意接受任何數據遺失。
如果遺失任何數據是無法接受的，您應該移除鏡像來打撈它們。
拿掉鏡像可讓資料庫管理員復原原始主體資料庫，並嘗試復原遺失的數據。 不過，當先前的鏡像資料庫上線時，先前的合作夥伴將會以相同名稱管理不同的資料庫。 資料庫管理員必須讓其中一個資料庫無法存取用戶端，以避免資料庫進一步分歧，以及防止用戶端故障轉移問題。
如果可以接受任何數據遺失，您可以繼續同步。
繼續進行鏡像操作會導致新的鏡像資料庫回滾，作為同步資料庫的第一步。 如果在失敗時，任何日誌記錄正在傳送佇列中等待，即使交易已認可，對應的交易也會遺失。
原始主體伺服器尚未重新連線
如果您可以暫時防止原始主體伺服器透過網路重新連線到新的主體伺服器，您可以檢查原始主體資料庫，以評估鏡像恢復時會遺失的數據。
如果可能的數據遺失是可接受的
允許原始主體伺服器重新連線到其夥伴。 重新連接會導致鏡像暫停。 若要繼續進行鏡像，只要恢復會話即可。 先前的主伺服器會轉為擔任鏡像角色。 新的鏡像伺服器會卸除原始復原分支，遺失先前鏡像伺服器從未傳送或接收的任何交易。
如果數據遺失是無法接受的
如果原始主體資料庫包含在繼續會話時遺失的重要數據，您可以移除鏡像來保留原始主體伺服器上的數據。 我們建議您此時嘗試備份主體記錄的尾端。 然後，您可以匯出您想要從原始主體資料庫進行打撈的數據，並將其匯入目前的主體資料庫，以更新目前的主體資料庫（先前的鏡像資料庫）。 建議您儘快建立更新資料庫的完整資料庫備份。
若要將更新的資料庫重新設定為初始主體資料庫的鏡像，請利用此備份（以及至少一個後續的日志備份）來建立新的鏡像資料庫。 拿掉鏡像之後所建立的每個記錄備份都必須套用。 因此，建議您延遲主體資料庫的其他記錄備份，直到新的鏡像會話開始為止。
管理強制故障轉移的相關工作
強制要求服務
若要恢復資料庫鏡像
建立新的鏡像資料庫
啟動資料庫鏡像
另請參閱
估計角色切換期間的服務中斷 （資料庫鏡像）
資料庫鏡像期間可能發生的失敗
將用戶端連線到資料庫鏡像工作階段 （SQL Server）
資料庫鏡像見證
完整的資料庫還原 (完整復原模式)
資料庫鏡像運作模式
鏡像狀態 （SQL Server）