如何安全的将VMware vCenter Server使用的SQL Server Express数据库平滑升级到完整版
背景：
由于建设初期使用的vSphere vCenter for Windows版，其中安装自动化过程中会使用SQL Server Express的免费版数据库进行基础环境构建。而此时随着业务量的增加，虚拟机数的膨胀，产生的日志如果不被及时清理掉或者转移走的话，会导致该免费版数据库很快触发阈值而停止SQL Server服务（对于2005/2008版【vCenter Server 4.1以下版本】是mdf文件不能超过4GB，对于2008 R2版【vCenter Server 5.5以上版本】的是mdf文件不能超过10GB），这样就会导致vCenter主服务无法启动，vCenter对外服务异常。
因此最终用户方提出能否通过技术手段对免费受限版的数据库升级？
探索：
通过爬VMware的KB知识库，有发现介绍如何迁移免费版到完整版的文章KB1028601。通过仔细阅读，我了解到很多关于数据内部调用，注册表项的真实含义，以及安全迁移的必备环境等内容。
由于上文介绍的是迁移内容，再结合用户现有环境，可以借鉴迁移文章中涉及到的知识点，但是不能完全照搬完成我这次的升级，因此真正实施的过程中该文是我的重要技术保障，接下来将给各位带来如何安全平滑升级到完整版SQL Server的详细步骤。
平滑升级过程：
1. 进行环境备份
a) 虚拟化环境对该vCenter虚机进行快照即可
b) 物理环境建议做一下全镜像，可以微软自己的Windows Server Backup功能，也可以使用其他第三方的磁盘级别备份工具
2. 如果有开启DRS，请临时关闭DRS或更改成手动DRS（F该操作非必需项，有此建议的原因是实践中，当vCenter再次启动服务后，会重新计算“标准偏差”，这将可能会带来不必要的虚机迁移风暴）
3. 停止一切VMware vCenter Server服务，详细步骤可参考KB2109881
4. 准备升级材料
a) 大于等于现有免费版本号的SQL Server 英文版
b) 可供管理现有vCenter Server 内建数据库实例的“SQL Server Management Studio”工具
表格 1取自维基百科的版本与发布名成对照表
|
RTM (noSP) |
SP1 |
SP2 |
SP3 |
SP4 |
|
|
|
13.0.1601.5 |
||||
|
|
12.0.2000.8 |
12.0.4100.1 |
12.0.5000.0 |
|
|
|
|
11.0.2100.60 |
11.0.3000.0 |
11.0.5058.0 |
11.0.6020.0 |
|
|
|
10.50.1600.1 |
10.50.2500.0 |
10.50.4000.0 |
10.50.6000.34 |
|
|
|
10.0.1600.22 |
10.0.2531.0 |
10.0.4000.0 |
10.0.5500.0 |
10.0.6000.29 |
|
|
9.0.1399.06 |
||||
|
|
8.0.194 |
||||
|
|
7.0.623 |
5. 确认升级前版本
a) 使用“SQL Server Management Studio”登陆“VIM_SQLEXP”实例
b) 查看当前实例的数据库版本号，以vSphere 5.5 vCenter Server为例，它使用的是英文版v10.50.2500.0，等换成发布名称就是SQL Server 2008 R2 with SP1
图 1确认数据库实例语言和版本
6. 获取目标版本
a) 由于内建免费版使用的SQL Server相对来说有点过于久远，因此在用户购买的版本中找到了SQL Server 2012 with SP3作为目标版本使用
7. 开始升级
a) 本小节会有大量截图出现，使您更直观的了解到升级全貌
b) 
图 2选择维护项（Maintenance）的版本更新（Edition Upgrade）
c) 
图 3输入用于更新的目标版本产品密钥，我这里使用的是企业版密钥
d) 
图 4同意授权许可
e) 
图 5注意选择实例（VIM_SQLEXP）蓝色箭头，红色箭头1注意版本，红色箭头2注意版本号（这里看到11.3.6020，是因为之前做过一次基于版本号的升级，原本这里应该是10.51.2500.0的）
f) 
图 6升级规则检查，6项全部通过
g) 
图 7最后再看一下汇总，了解操作内容和目标版本信息以及实例名称
h) 
图 8升级完后，通过管理工具确认版本1和版本号2信息，同时我们注意到根目录3此时也发生了变化
i) 确认无误，至此SQL Server 这边的升级到此结束
8. 更新vSphere vCenter Server所需要用到的DSN（此操作步骤非必需，但可以确保一致性，提高兼容性）
a) 此步骤来自于VMware的迁移文档KB1028601 描述
b) 由于此次我选择的是升级而非迁移，所以SQL在服务中的启动名也没有变（依旧是MSSQL$VIM_SQLEXP），倒是DSN的版本需要更新一下，原先是10，现在是11
c) 
图 9通过查看控制面板内的管理工具，在ODBC数据源管理器（odbcad32.exe）中我们可以看到vCenter的系统DSN还是版本10
d) 如果想偷懒，可以在注册表编辑器（regedit.exe）下面先导出HKEY_LOCAL_MACHINE\SOFTWARE\ODBC这个分支下的所有内容
e) 随后我删除这个名称是VMware vCenter的系统数据源
f) 接着我开始配置一个新的VMware vCenter数据源
i. 
图 10按图选择版本11的驱动程序
ii. 
图 11使用刚刚导出的reg注册表文件，按照顺序依次填入这三个内容后下一步
iii. 
图 12保持默认，使用Windows 授权验证，随后下一步
iv. 
图 13在红字1处选择默认数据库为VIM_VCDB，红字2处选择读写，随后下一步
v. 
图 14最后一步，点击完成进行简单测试
vi. 
图 15完成测试，看到测试通过字样
vii. 
图 16最后看到系统DSN内生成了新的基于11版本的数据源
9. 最后不做任何操作的重启一下vCenter服务器，目的是一起检查系统服务自启动，vCenter服务自启动，同时也利于问题就近发现
10. 登陆vCenter，对DRS进行开启或者变更成自动
11. 最后的最后就是稳定工作一段时间后就可以删除原有的快照文件了
总结：
1．和迁移方案不同，这里我们使用的是原地升级，因此省去了很多VMware内部调动外部数据库的配置动作，唯独需要注意的是DSN版本，而这个也是为了看起来一致，非必需步骤
2．这种升级方式属于偷懒升级，但是也很安全，满足用户方在没有syslog服务器的情况下在本地更多存放日志信息到数据库内
3．请一定准备好英文版SQL Server安装介质作为目标升级版本
4．这种操作的弊端，我认为经过一段时间后随着数据库的变大，系统启动时间会变长，对去历史日志的时候也会有所变慢，可以通过迁移到更快速存储或者设置日志留存级别来控制数据库大小
5．在vSphere5.5之后6.0之前的这些版本内，使用的都是SQL Server 2008 R2 的免费版，因此可以提供10GB的免费使用数据库空间，在一定程度上满足大多数用户需求
6．各位看过之后有任何疑问欢迎留言
有用的链接：
1. https://kb.vmware.com/kb/1028601
2. http://sqlserverbuilds.blogspot.com
3. https://zh.wikipedia.org/wiki/Microsoft_SQL_Server
4. https://msdn.microsoft.com/en-us/library/mt238290.aspx
-=EOB=-
