最近，和一個朋友談論各自公司對如何提高SQLServer數據庫的保護和數據庫可用性以及提高性能方面所采用的技術時，發現SQLServer有不少技術可用，而且有很多可以互補的地方，SQLServer 雖沒有Oracle的RAC，但如果把它現有的技術充分發揮下，還是足以應付絕大部分的情況的（遺憾的是有些技術在性能和可靠性方面還是有些不成熟,出現問題很難搞定）。

   很多公司保護數據，最先用到的基本都是備份（這個是必不可少，也是最節約成本的方法了），基本的備份有三種，全備、差異和日志（當然還有基于文件、文件組、Page等的備份方案，不做討論），如何合理的安排這些備份計劃，需要根據應用系統的業務要求和特點來定，還得考慮備份文件的保留時間、備份頻率等。

本地備份

    但是隨著數據量的增加，同時考慮一些安全性的原因，將數據都保存到本機硬盤的方案變得不可取，于是考慮購買一臺磁帶機，將備份的數據從本地磁盤，轉移到磁帶機上，本地磁盤只保留一份最新的全套備份；一方面可以解決磁盤空間問題，同時還將數據備份到了其他設備中，增強了數據的安全性。

磁帶機備份

    有了完善的數據庫備份方案，視乎我們的數據得到了有效的保護，但是想象下，如果我們的服務器真出現故障，服務器起不來了，該怎么做呢？當然是按我們的備份計劃，將數據從最新的全備份開始，然后差異，然后再日志還原過來；假定我們的備份文件100%的可用（不可用的情況也經常發生哦），如果數據庫小，那不久就可以還原好，但是如果是個幾百G的數據庫，要按這樣一步步還原，而此時后面一堆人都掛著等你的數據庫恢復，boss過兩分鐘過來問下情況，手里的電話被各個需要使用的部門打爆…，這時候沒有強悍的心理素質，估計早就崩潰了；并且備份還有時間選擇，比方你一個小時備份一個日志文件，但是如果數據庫某天運行到1：50分左右突然掛掉了，此時如果備份不到最后50分鐘的日志信息，那你這50分鐘所產生的數據就找不回了。

    正因為這樣的備份恢復方案無法達到我們及時恢復數據庫和最大限度保障數據的要求，于是我們不得不考慮其他更快恢復數據并減少數據丟失的方案，我們先考慮SQLServer給我們提供的方案（硬件方案后面討論），數據庫里面有兩種技術方案可以使用，一種是Mirroring，另一種是Log shipping（兩種技術的細節這里不討論）。

Mirroring/Logshipping

    有了mirroring和log shipping（稱備機），我們不但縮短了數據庫恢復的時間，減少了數據丟失的可能，還可以將某些不需要完全實時的操作放到備機上（如：BI抽取數據，做報表等），真是一舉兩得；不過，采取Mirroring和Logshipping會增加服務器的負擔（不過一般都可以接受），Mirroring技術的高安全性可以最大限度保護數據不丟失，但對主服務器影響較大（需要等待備服務器響應和回傳信息），高可用性能提高恢復數據庫上線的速度，但是需要增加一臺見證機，高可用性對數據的保護要稍微差點（主要取決于服務器性能和網絡帶寬），但對主服務器性能影響較?。欢鳯og shipping是定期備份日志，然后傳到備機上還原，數據丟失多少取決于備份和傳送的頻率，同時這兩項技術還增加了部分硬件投入（需要備機）。

    這樣做之后，對一些普通的系統基本都可以應付了，但是對那些需要7×24小時不間斷提供服務的應用還是有所不足；例如：如果我們數據庫服務器一塊網卡壞了，或者操作系統崩潰了（但數據庫本身沒問題），那我們不得不停止業務來進行更換網卡或者啟用備機來提供服務，影響了業務的進行；想象一下，淘寶這類的在線交易購物網站，一天的交易筆數有多少，當機一分鐘都可能有上千萬的損失（個人估計，沒實際調研，淘寶也不用SQLServer，呵呵），為應對這些在線時間要求高的情況，我們的Cluster就應運而生了。

     Cluster通過用兩臺服務器來連接一個數據庫（形式有多種），也就是說兩套硬件服務器和兩套操作系統來支持一個數據庫系統的運行，數據都存放到磁盤陣列中，磁盤陣列可以采用Raid技術來提供磁盤的冗余；這樣相當于為SQLServer提供了兩套訪問設備，一套壞了，另一套立馬可以頂替過來，這大大縮短了故障恢復的時間，差不多只相當于重啟了一次數據庫而已，（當然還有資源轉移的時間，但一般不會太長），不過這樣設備投入就更多了。

Cluster

     通過這些技術后，數據保護和在線能力都有了很大的提高，但是這么多的操作都集中到了存儲上，當訪問量很大時，存儲就成了數據庫系統的瓶頸，那該如何處理呢？有兩種思路，一提高存儲系統的性能，使用轉速更快，性能更好的磁盤，所以現在出現了很火的SSD；二拆分業務或者是使用讀寫分離，將對一臺數據庫的訪問分散到多臺機器上，減輕單臺的壓力。

SSD磁盤

讀寫分離

業務拆分

     這樣就足夠了嗎？知道911嗎？像911那樣的事故，可能我們都不會遇到，但是，電信機房起火事件發生的概率還是有的（里面機器多呀），如果這樣的情況發生，如果我們沒有提前做好應對方案的話，一切就都over了；于是異地容災就被提出來了，主要有異地備份和異地機房方案（異地備份就不講啦）；如果建了異地機房，那怎么樣同步數據就是個頭大的問題，目前大部分硬件提供商提供的方案是磁盤同步的方案，兩地機房之間用光纖相連（成本呀），當A機房的某個磁盤寫數據時，通過光纖將這些數據傳到B機房對應的磁盤上，這樣就完成了兩個磁盤數據的同步（至于這個同步有多大的延時，就不好說啦）；A、B機房采用同樣的架構，正常情況下只有A機房的磁盤對外提供服務，B機房的磁盤不提供對外訪問(起碼不能寫),一旦A機房真的被毀了，那B機房的這些設備就可以開啟，用來提供對外的服務。

異地容災（磁盤同步技術）

以上只是目前個人根據自己的經歷對SQLServer在高保護、高可用性和高性能方面的一些觀點，如果大家有其他更好的建議，希望能拿來一起分享。