我們首先來看一下什么是數(shù)據(jù)鏡像：

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

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

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

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

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

主體服務器：承載主體數(shù)據(jù)庫

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

鏡像服務器：承載鏡像數(shù)據(jù)庫

作為主體數(shù)據(jù)庫的執(zhí)備份 所謂熱備份是說，主體數(shù)據(jù)庫上的變化會立即反應硬驅(qū)鏡像數(shù)據(jù)庫上。

僅在故障轉(zhuǎn)移后接受用戶連接，處理事務請求

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

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

主體數(shù)據(jù)庫和鏡像數(shù)據(jù)庫互為伙伴：

主體和鏡像是可以相互轉(zhuǎn)換的

故障轉(zhuǎn)移后伙伴角色發(fā)生變化

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

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

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

總結(jié)一下數(shù)據(jù)庫鏡像工作過程：

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

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

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

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

高可用性：最常用的。

高級別保護

高性能

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

高可用性模式：

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

應用場景：

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

要求實現(xiàn)自動故障轉(zhuǎn)移

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

高級別保護模式：

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

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

應用場景：

高的數(shù)據(jù)完整性要求

不要求自動故障轉(zhuǎn)移

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

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

高性能模式：

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

應用場景：

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

通訊鏈路有明顯的延遲

對性能的要求高于數(shù)據(jù)的完整性

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

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

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

事務安全性：

FULL 主體和鏡像數(shù)據(jù)庫同步傳輸?shù)哪Ｊ剑?/p>

主體在發(fā)送日志后等待鏡像的確認

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

OFF

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

主體失敗時在鏡像上可能丟失部分數(shù)據(jù)

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

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

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

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

準備鏡像數(shù)據(jù)庫 在鏡像服務器上準備鏡像數(shù)據(jù)庫

創(chuàng)建數(shù)據(jù)庫鏡像端點 在各個服務器上配置鏡像端點

配置安全性

啟動數(shù)據(jù)庫鏡像

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

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

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