我們首先來看一下什么是數據鏡像：

現在幾乎所有的應用系統都是基于數據庫的，那么數據庫的負荷是比較大的，在一天24小時中，任何時間都有可能會有數據要保存到數據庫，或是從數據庫中讀出數據。任意時刻都會有用戶連接到我們的數據庫服務器上，幾十，幾百甚至成千上萬個用戶來連接使用我們的數據庫，那么不論是計劃內的宕機還是計劃外的故障都會造成一定的損失。給我們的用戶或是企業帶很大的損失，特別是隨著數據時代的到來，用戶對數據的使用提出了更高的要求，那么作為一個DBA，就要想怎么做才能將這個損失減少到最低，正是因為基于這種需求，數據庫鏡像技術出現了！SQL SERVER2005中首次提出了數據庫鏡像概念。特點：

基于軟件的高可用性解決方案 那是完全基于軟件的高可用性解決方案。不需要增加硬件成本，也就是低硬件成本

快速的故障轉移恢復， 最主要的一個亮點，就是快速的故障轉移恢復。3秒（對于用戶或是DBA是特別有吸引力的） 數據量大的情況一般10秒.

在這個數據庫鏡像技術中有一個數據庫服務器我們稱為主數據庫。它負責用戶的連接和數據的處理。還有一個是從服務器，確切來說，這里應該叫鏡像服務器，上面也有一個數據庫，叫鏡像數據庫，這個數據庫用于存放我們主數據庫的一個熱備份。也就是說它雖然不連接用戶機，但是它對于主服務器上的數據更改呀，變化呀，都能做一個熱備份，也就是說如果用戶更新了主數據庫中的內容，那么主數據庫會根據鏡像技術將更新傳送給鏡像服務器，這樣就能保證主服務器和從服務器之間的數據是一致的，那么假如說由于某種原因，我們的主服務器或是主數據庫不可用了，例如，網絡中斷，系統故障等等，那么客戶端會重新定向到鏡像服務器，那么客戶端仍然能讀取數據，寫入數據，他感覺不到主數據庫服務已經宕機了。所以采用數據庫鏡像技術以后，對于用戶來說這個可用性就增強了，而且對于故障恢復時間也縮短了。那么客戶仍然可以向鏡像數據庫上寫數據。讀數據，更新相關的事務，這是我們應用數據庫鏡像的一個過程。 想實現這個過程，必須要涉及到這么幾個角色：

數據庫鏡像中的服務器角色：這幾個角色剛才通過圖形介紹了一點，那么在2005中有三種服務器角色，分別是

主體服務器：承載主體數據庫

接受用戶連接和事務處理請求 也就是說主體服務器正常的情況下就是主體服務器來提供服務

鏡像服務器：承載鏡像數據庫

作為主體數據庫的執備份 所謂熱備份是說，主體數據庫上的變化會立即反應硬驅鏡像數據庫上。

僅在故障轉移后接受用戶連接，處理事務請求

見證服務器：監視服務器狀態和連接性，實現自動故障轉移 也就是說見證服務器會時刻監視兩個服務器的狀態和連接性，當主體服務器發生宕機或者不可用以后，見證服務器會立即啟用故障轉移，將鏡像服務器切換為主體服務器。繼續為用戶提供服務器

這是數據庫鏡像中的三個服務器角色，但是要注意一下就是這三個角色不是固定下來的，是可以變化的：

主體數據庫和鏡像數據庫互為伙伴：

主體和鏡像是可以相互轉換的

故障轉移后伙伴角色發生變化

當主體服務器正常的情況下，用戶所有的連接及數據的更新都是直接送到主體服務器的，只不過是主體服務器再將數據備份到鏡像服務器上，但是主體服務器不可用時，此時角色就發生了改變。鏡像服務器就變成了主體服務器。那么如果原來的主體服務器恢復正常了，那么怎么辦，它就會成為鏡像服務器。所以它們的角色就徹底變化了。那如果這個服務器又不可用了。那么又是一個轉換的過程。

那大家可能又要問一個問題就是這三個角色怎么知道到底哪一個可用，哪一個不可用：

各個服務器實例通過PING交換消息相互監視。與DOS命令的PING原理差不多，但是功能比DOS下的PING要強大的多，DOS下的PING只是檢查網絡的連通性，而此處的PING即要監視網絡的連通性，這是第一步，還要監視數據庫服務器實例的運行情況，服務器是否是正常的，還有就是這個服務器上的數據庫是否正常。

總結一下數據庫鏡像工作過程：

正常情況下，配置好數據庫鏡像以后，用戶只能連接主體數據庫，但此時鏡像數據庫是不可用的。用戶連上去也沒有用。用戶只能使用主體服務器時，主體服務器會將數據一方面寫到自己的數據庫中，另一方面通過事務日志的方式傳給鏡像服務器，寫到鏡像服務器的數據庫，此時主體服務器會進入一個等待狀態。等待鏡像服務器的確認，也就是當鏡像服務器的數據成功寫入到鏡像數據庫以后會發一個消息給主體數據庫，說我現在已經完成了數據的更新了也就是在鏡像服務器上執行了一個REDO的過程。這是一個確認。當主體服務器收到這個確認以后會給客戶端一個回應，說剛才的那個數據更新的操作已經完成了

那么為什么能實現一個快速恢復機制，這主要和2005中的一個機制是分不開的

但SQL 2005不是沒有必要等到回滾結束只要在REDO之后就可以使用了，至于UNDO的操作，在用戶使用的過程中你再繼續UNDO，所以當主體服務器發生數據更新了，鏡像服務器會以最短的時候來時間更新，以至于如果主體數據發生故障了，鏡像服務器右以在最短的時間內接替主服務器進行工作。

下面來介紹一下數據庫鏡像中的三種操作模式：

高可用性：最常用的。

高級別保護

高性能

下面咱們分別來看一下這三種模式，當然最主要的就是高可用性，這是使用比較廣的一個模式

高可用性模式：

服務器角色： 主體服務器 鏡像服務器 見證服務器

應用場景：

要求高可用性的場合 如股票交易 證券交易 銀行等。

要求實現自動故障轉移

確保數據的完整： 要求只要是用戶提交到服務器上的數據，那怕說數據剛提交上主體服務器就發生故障了，也能保證數據不會丟失。故障轉移之后的數據是不會丟失，從而保證數據庫的完整性

高級別保護模式：

我們從名稱上也能看出來，它的重點在于對數據的一種保護，而不是實現可用性

服務器角色： 主體服務器 鏡像服務器

應用場景：

高的數據完整性要求

不要求自動故障轉移

對服務的可用性要求較低 也就是說主體數據庫的宕機還是可以接受的，但是數據的丟失是不可以接受的，那么這種場合可以使用高級別保護模式

因為沒有見證服務器，所以是不能進行自動的故障轉移的。那如果主體服務器不可用，那么想實現故障轉移，只能是手工完成，所以對服務器的可用性要求較低

高性能模式：

服務器角色： 主體服務器 鏡像服務器

應用場景：

主體服務器和鏡像服務器距離很遠的時候 十幾公里或是完全兩個城市

通訊鏈路有明顯的延遲

對性能的要求高于數據的完整性

原理是：當主體服務器收到用戶的操作后，將此事務傳給鏡像服務器，因此距離遠所以有明顯的延遲，所以他不會等鏡像服務器的確認，也就是說它不管這個數據到底有沒有寫到鏡像服務器，所以這種模式就在于盡快的響應用戶的請求，也就是對用戶對性能有一個較高的要求，這個要求是高于數據的完整性。

這種模式下會存在數據的丟失，也就是說如果主體服務器宕機了，我們會把鏡像服務器作為主體服務器，但是不能保證這里面的數據就是和主體服務器上的數據是一致的，因為有可能會有丟失。

我們對幾個概念簡單的介紹一下：

事務安全性：

FULL 主體和鏡像數據庫同步傳輸的模式，

主體在發送日志后等待鏡像的確認

主體和鏡像的日志完全一致

OFF

主體和發送日志后不等待鏡像的確認，繼續處理后繼的操作。

主體失敗時在鏡像上可能丟失部分數據

仲裁：在高可用性或是高級別保護模式下需要仲裁。以決定那一個服務器是主體服務器，

仲裁的改變將導致故障轉移，如主體服務器發生故障了，則會發生仲裁的改變，將鏡像服務器定為主體服務器。

形成仲裁的形式一般有這么幾種：

下面我們就來看一下如何配置數據庫鏡像： 這應該是大家感覺很興奮的，因為聽我西里嘩拉的講了半天。終于不用再受罪了。其實配置很簡單的，只要注意幾個步驟就行了。

準備鏡像數據庫 在鏡像服務器上準備鏡像數據庫

創建數據庫鏡像端點 在各個服務器上配置鏡像端點

配置安全性

啟動數據庫鏡像

下面我們就具體看一下如何去做，有哪些需要注意：

這里需要提到的一點的就是在SQL SERVER2005剛剛發布出來的時候數據庫鏡像這個服務默認是關閉的，也是不支持的。在剛剛發布SQL SERVER2005正式版本的時候，認為數據庫鏡像這個技術還不成熟，有待完善。所以如果你使用的是正式版本則無法使用這個技術。

那么需要下載SP1或是以上的補丁。