SQLServer 高可用、高性能和高保护延伸
最近，和一个朋友谈论各自公司对如何提高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技术的高安全性可以最大限度保护数据不丢失，但对主服务器影响较大（需要等待备服务器响应和回传信息），高可用性能提高恢复数据库上线的速度，但是需要增加一台见证机，高可用性对数据的保护要稍微差点（主要取决于服务器性能和网络带宽），但对主服务器性能影响较小；而Log shipping是定期备份日志，然后传到备机上还原，数据丢失多少取决于备份和传送的频率，同时这两项技术还增加了部分硬件投入（需要备机）。
这样做之后，对一些普通的系统基本都可以应付了，但是对那些需要7×24小时不间断提供服务的应用还是有所不足；例如：如果我们数据库服务器一块网卡坏了，或者操作系统崩溃了（但数据库本身没问题），那我们不得不停止业务来进行更换网卡或者启用备机来提供服务，影响了业务的进行；想象一下，淘宝这类的在线交易购物网站，一天的交易笔数有多少，当机一分钟都可能有上千万的损失（个人估计，没实际调研，淘宝也不用SQLServer，呵呵），为应对这些在线时间要求高的情况，我们的Cluster就应运而生了。
Cluster通过用两台服务器来连接一个数据库（形式有多种），也就是说两套硬件服务器和两套操作系统来支持一个数据库系统的运行，数据都存放到磁盘阵列中，磁盘阵列可以采用Raid技术来提供磁盘的冗余；这样相当于为SQLServer提供了两套访问设备，一套坏了，另一套立马可以顶替过来，这大大缩短了故障恢复的时间，差不多只相当于重启了一次数据库而已，（当然还有资源转移的时间，但一般不会太长），不过这样设备投入就更多了。
Cluster
通过这些技术后，数据保护和在线能力都有了很大的提高，但是这么多的操作都集中到了存储上，当访问量很大时，存储就成了数据库系统的瓶颈，那该如何处理呢？有两种思路，一提高存储系统的性能，使用转速更快，性能更好的磁盘，所以现在出现了很火的SSD；二拆分业务或者是使用读写分离，将对一台数据库的访问分散到多台机器上，减轻单台的压力。
SSD磁盘
读写分离
业务拆分
这样就足够了吗？知道911吗？像911那样的事故，可能我们都不会遇到，但是，电信机房起火事件发生的概率还是有的（里面机器多呀），如果这样的情况发生，如果我们没有提前做好应对方案的话，一切就都over了；于是异地容灾就被提出来了，主要有异地备份和异地机房方案（异地备份就不讲啦）；如果建了异地机房，那怎么样同步数据就是个头大的问题，目前大部分硬件提供商提供的方案是磁盘同步的方案，两地机房之间用光纤相连（成本呀），当A机房的某个磁盘写数据时，通过光纤将这些数据传到B机房对应的磁盘上，这样就完成了两个磁盘数据的同步（至于这个同步有多大的延时，就不好说啦）；A、B机房采用同样的架构，正常情况下只有A机房的磁盘对外提供服务，B机房的磁盘不提供对外访问(起码不能写),一旦A机房真的被毁了，那B机房的这些设备就可以开启，用来提供对外的服务。
异地容灾（磁盘同步技术）
以上只是目前个人根据自己的经历对SQLServer在高保护、高可用性和高性能方面的一些观点，如果大家有其他更好的建议，希望能拿来一起分享。
