背景
最近接手很多项目都跟数据库升级有关。感触还是颇深，写个心得，供大家参考，如果有疑问欢迎留言。
为什么升级？
你可能会因为各种各样的原因选择升级。我认为原因主要是3个方面
1.旧版本使用中遇到问题
性能问题，高可用问题，灾备问题等。当然升级并不一定能解决这些问题.
2.微软官方逐渐减少对旧版本的支持
2005 将于2016 年4月结束
3.新版本的独特功能
2012的 ALWAYS ON ,2014的内存优化表等
升级到哪个版本好？
首先，版本不是越新越好，适合自己的就是最好的。建议根据上面提到的升级的原因和需要什么样的功能来决定。
已知升级问题
1.支持的版本升级
升级前的数据库版本 ,
升级后的数据库版本 。
然后根据微软官方给出的列表来对应确认我们决定是否可以直接升级。
比如SQL 2000 就不能直接升级到 SQL 2012.如果满足直接升级就没什么问题。
2.数据库引擎的向后兼容性
1.不推荐使用的功能
2.废止的数据库功能
3.功能的重大更改
4.功能的行为更改
此处比较重要。尤其是2,3,。
升级的方式有哪些？
分为原地升级和并行升级。
1，原地升级（in-place）：安装进程覆盖以前版本的sql server程序文件，但保留以前的sql server实例中存储的所有用户数据，使DBA在执行升级的过程中不必转移或恢复现有的用户数据库。在升级之前，应当备份所有的sql server数据库以及以前的sql server实例关联的其它对象，此外，联机丛书不会升级。
2，并行升级(side by side)：需要事先在新的服务器环境安装一个升级后的数据库版本，然后手动将升级前的数据库转移到新版本的SQL SERVER 中。这个方法可以让新旧环境同时存在，从而最小化sql server环境的停机时间.
在并行迁移过程中，有很多种方法将数据库从一个sql server实例转移到另一个sql server实例：分离/附加方法，备份/还原方法，复制数据库向导，结合数据导入/导出的手动架构重建，发布订阅，Logshiping ,镜像等
这么多方式到底应该选择哪种呢？后续我会详细对比。
总结
在看完前面的几个问题后，你应该对数据库升级已经有了一个整体的思路。根据这些信息，制定一个完整的计划，以减少升级的分析和变数，使得升级更顺畅。升级成功后也一定要经过应用程序和兼容性测试。同时制定一个失败应急计划，如果直接升级失败也可以马上恢复数据库，不影响线上业务。不管升级环境简单或复杂，分析升级需求是相当重要的步骤。这通常包含SQL SERVER 软硬件需求，版本，兼容性等问题