SQL Server2005高可用性方面的不足

     在高可用方面SQL Server提供了一系列高端支持能力，并对复制和快照技术作了增强。但由于SQL Server几乎完全基于Windows平台，因此在HA方面还存在诸多不足：

 Failover Cluster是大型企业实施SQL Server 2005 HA的关键技术，该技术基于微软的MSCS（Microsoft Cluster Service），虽然在05版本中提供更方便的安装和多至8节点（企业版）的支持，但在SCSI和光线通道产品的支持上相对比较“挑剔”，尤其对于一些高端的共享裸设备虽然可以支持，但调整不够自由。

 Database Mirroring在保持持续联机可用方面作了很好的补充。不过从05版本看，还需要大力完善，包括提供更丰富的镜像过程动态性能信息、并为高端HA应用提供更简便的镜像数据验证功能。

 作为一个异步HA机制，Log Shipping提供了一个相廉价而且定制空间较大的HA方式，但配置和管理相对复杂，尤其在几个数据中心间跨库传播的管理成本相对较大。

以下是几点建议：

 微软加大与硬件、存储、嵌入式厂商的合作，依据行业存储标准专门为SQL Server提供定制化的设备认可资格，扩大用户可以选择的范围，兼容更多企业的遗留IT设备。

 另外，在实际应用中，由于Database Mirroring这个特型对硬件和配置的要求比较低，因此DBA们希望微软可以提供类似机制，但更细颗粒度的镜像能力，不仅仅是单纯的“数据库”级，最好延伸出Schema Mirroring、Db Object Group Mirroring等。

 需要更为便捷的管理工具，确保DBA在同时大型分领域数据中心或多个数据中心的时候，可以通过管理模版等方式帮助DBA梳理“千头万绪”的日志Shipping。

 SQL Server 2005虽然实现了基于策略的管理机制，但最好能提供策略的模拟验证手段，虽然很多情况下这些功能是通过一些价格不菲的第三方产品完成，但对于企业数据库市场相对弱势的SQL Server而言，如果SQL Server无法验证自己这些管理策略的有效性，而必须由用户填充数据后再来验证，恐怕用户宁可直接选择其他相对强势的HA产品。

对比Oracle数据库的强大高可用性，微软需要做哪些改进？

 系统运维过程中，SQL Server的问题更多来自于底层Windows平台，SQL Server自身的HA特性被平台的补丁更新、内存写错误等淹没了。

 另外相对ORACLE而言，SQL Server比较封闭。出现性能问题的时候，ORACLE几乎都可以通过配置参数解决或者缓解问题，但SQL Server更多依赖于Windows自己的注册表信息，还有为数不少的可调整能力完全内置，用户很难干预，这样在关键HA故障情形下总会给用户SQL Server无能为力的印象。

 另外就是用户文档方面，虽然通过全球技术支持中心大部分问题可以获得，但排查工具、排查手段往往无法从SQL Server公开发布的文档中获得，人为降低DBA的使用信心。

以下是几点建议：
 为了在用户心中树立SQL Server的Enterprise-class甚至World-class信心，首先要着力于Windows平台的持续稳定性。
 建议微软开放SQL Server的配置参数体系，虽然出于便于用户使用的目的，很多参数都可以配置默认值，但尽可能把主动权交给用户，2000到05版本去掉自动锁升级受到DBA的积极反馈就是一个非常明显的例子。

 另外，就是SQL Server的用户文档和工具体系，除了示例、教程和命令参考外，最好把全球支持中心遇到并解决的问题也筛选后对外公开，目标只有一个——“树立信心”，而不是总让下决心在大型应用中采用SQL Server的用户屡屡受挫。