原文:
SQLServer 服务器架构迁移
最近服务器架构迁移，将原来的服务器架构迁移到新的服务器，新的服务器在硬件方面比之前更好！原来服务器使用双向同步，并且为水平划分到多个数据库服务器。迁移过程中，数据库方面涉及到数据一致性，帐号，重新划更多分区，规范索引，分布式查询，删除无效触发器等等。程序方面重新修改配置文件，SQL等。
原架构如图：
![]()
现在有相同的服务器，所有分库都迁移到新的服务器，再增加一台服务器作为独立的分发服务器。然而，总库已经没有多余的服务器了，怎么办？解决方法是 ，总库（DBA）中再安装一个数据库实例！这样，每台服务器都有对应了。为什么总库也要对应一个服务器？因为总库与分库有数据差异，用户使用的都是分库，所以原总库数据不能要！但是数据库名称仍然不变，所以只有新增一个实例了！总库不能要，怎么将分库数据汇总成一个完整的总库？过去使用过的方法，现在完整备份各分库还原到总库服务器并使用不同名称，停机维护时，将分库日志备份并还原到总库服务器中的各个分库，此时再使用merge与原总库对比，则原总库将会三一个完整的数据库。 但是，对比时间太长了！当前的方案是，将在各个分库建立事物发布，汇总到一个新实例中！（参考：SQL Server 中心订阅模型（多发布单订阅））
那么，整个迁移方案中，可以分为5个阶段：
第一阶段：前期阶段，计划方案，确定步骤，预先执行部分耗时操作；
第二阶段：停机前一两小时，预先准备，将步骤看清一边，预先执行可执行的操作；
第三阶段：停机维护中，更改分布式脚本；切换用户对数据库的访问；访问测试；
第四阶段：停机时间到，开启访问，重要的部分工作先完成；
第五阶段：接下来这一两天完成所有后续工作；并且观察数据库方面的性能；
切换架构如图：
![]()
上图中，上半部分是原架构，下半部分是新架构。考虑的问题较多！！同样分几个阶段处理：
第一阶段：
新服务器的和数据库的安装升级配置不必说了；
将总库备份还原到新实例，设置简单模式，并将里面的数据全部清空（truncate）并收缩数据库；
删除所有索引，批量创建主键；
添加文件及文件组，设置文件增长率；
重新划分更多分区，设置LOCK_ESCALATION ；
更改默认值约束，去掉无用触发器；
迁移登录帐号；
备份当前的空数据库，留着还原到新的分库中；
设置分发数据库；
原来的分库（db1~dbn）创建事物发布到新的总库中，只对表发布；（参考：SQL Server 中心订阅模型（多发布单订阅））
授予权限；
（新分库还原上面的空库并参考上面的一些步骤）
新总库创建发布到新分库中；
新分库设置完整模式并设置备份计划；
第二阶段：
链接服务器的更改；
停掉以前的复制；
禁止备份作业及其他相关作业；
检查同步情况；
对比没有汇总的一些参数表；
第三阶段：
停机维护启动；
检查同步情况及新旧数据库是否有差异（sysindexes）
更改sql脚本；
升级web配置文件
第四阶段：
授予开发人员权限；
部分权限修改；
观察系统运行情况；
第五阶段：
原总库数据库删除，新总库迁移到SSD盘；
辛苦备份计划创建；
作业转移或重建；
删除原分库到新总库的复制；
观察系统运行情况；
整个过程，方便的，几乎都用脚本来执行，因为脚本可以提前写好，可以计划好顺序。实际上，不出问题的话，停机维护时间可以不到半小时。总之，能其他做的先做，能往后做的后做，减少停机维护时间。
