这里为什么要在升级前就作这样的优化工作而不是升级后系统运行时在针对慢的语句进行分析呢? 这个道理很简单,如果上线了才发现如果变慢的功能很多,或变慢的是频繁的功能那么上线的效果就是俩个字"失败"。虽然有的看官知道可以使用提示或降低兼容级别解决这个问题，但是这只是特殊场景下的极端手段，而并不是解决的根本。所以建议如果你有升级到2014的需要，那么这样的优化手段一定要提前做！

升级到2014

　　升级数据库完全可以写成好几篇博客，甚至写本小书都可以了！这里只做简单介绍，和一些要重点注意的问题！

　　升级方式

　　升级方式有2种：in place 和side by side，这里采用的是side by side！ 通俗地说就是准备新的服务器，安装对应版本的数据库，然后把数据还原上去。side by side的好处就是升级不会影响原有的环境，即使失败也能修改程序指向回退到原环境！

　　

 

　　升级2014 最大的一个问题

　　2014 的新特性 “参数估计” ！这个让人兴奋又苦恼的新功能会导致很多语句在升级到2014 后变慢，因为前面的优化阶段已经对这部分重点关注了，所以这部分的问题基本已经消灭！但是万恶的分区表（200多个分区）依然导致了批处理的性能严重问题！

集群搭建

　　集群搭建可能没有过多的可说支出，正常创建故障转移集群，搭建AlwaysOn等，但这其中的细节还是很多的，比如仲裁的方式？异地节点的虚拟IP设置？节点个数与业务的配合？等等等的问题，这里也就不一一细说了。

　　详细步骤请按照 桦仔非常详细的三篇博文:从0开始搭建SQL Server AlwaysOn 第三篇（配置AlwaysOn）

第一篇

第二篇

第三篇

程序修改

　　这个架构的修改也必然导致程序上的变化，这也是前文中提到的为什么客户最倾向的架构，因为复杂度低而使成本大大提升。原始系统中的关联性无法通过发布订阅实现本地化访问，又不能使用性能非常差的链接服务器。那么路只有一条，那就是修改程序访问方式，简单理解为在程序中分别在各自的数据库中查出相应的数据，然后通过程序在内存中操作处理。

细节问题处理

　　总体的实施步骤可以说就是这样了，但是在这个整体步骤中充斥着无数的细节，每一个细节可能都决定着方案的可行性，升级、架构变更的成败。限于篇幅这里只举几个可能常见的问题说明一下！

 

　　遇到的问题真的是各种多，这也是为什么说当你的常规技术手段都掌握的时候，踩过的坑就是你的成长了！

 

--------------博客地址---------------------------------------------------------------------------------------

原文地址: 

如有转载请保留原文地址! 

 

-----------------------------------------------------------------------------------------------------

 

　　总结 ： 文章只是简单分享了一个较为复杂的08到14的升级并搭建高可用的工作,真正的实战项目和自己搭建的测试系统还是有很大的差别。项目整个工期持续了3个月，所以本文只是简单的说明思路和步骤，另外介绍了几个常见的大坑。项目中的主要步骤，个人认为这也是在数据库高可用方案搭建过程中的必要步骤：

 

 　　此项目可以说是比较严格的遵循了相关管理的标准，在三个月的实施中，我们秉承这“稳定大于效率”的思想，工作细化到每一步，每一步都有详细的说明，最终保证了三套系统的上线运行零故障！

　　

 文章用到的 Expert FOR SQLSERVER 工具下载链接：

 ----------------------------------------------------------------------------------------------------

注：此文章为原创，欢迎转载，请在文章页面明显位置给出此文链接！
若您觉得这篇文章还不错请点击下右下角的推荐，非常感谢！