概述

本篇我们将利用DMA一步一步实现SQL Server 的迁移。帮助大家理解现在的SQL Server与新版本的融合问题，同时需要我们做哪些操作来实现新版本的升级或者迁移。

SQL Server 迁移

一定要有一个准备好的计划，我下面列出了所有的迁移过程需要做的工作，如下列表：

步骤列表

序号

SQL Server迁移步骤

1

必要环境的准备（比如高版本的服务器操作系统）

2

研究弃用和停用的功能、特性

3

运行数据迁移助手（DMA）了解哪些改变不被允许或者会影响迁移。

4

确认SQL Server 服务，数据引擎，SSIS,SSAS，SSRS等等可用

5

排序规则注意一致或者有变更的仔细核对

6

确保应用程序的连接需求

7

日志、聚集、数据库镜像、复制、全文索引、分布式服务等服务类的都需要有计划的去管理迁移。

8

管理有效的连接服务器，迁移

9

备份策略和计划的完整迁移，包含了完整、差别、事务日志备份。

10

规划需要的磁盘空间

11

管理迁移各个服务的账号

12

检查数据一致性

13

预升级--升级前后比较性能指标

14

评估宕机时间及影响

15

定稿升级流程

16

制定升级、迁移的验收标准

17

最终验收

18

回滚计划以及测试

19

务必通知所有涉及和影响的负责人

20

向所有负责人发送升级、迁移的步骤

21

准备新的、或者迁移旧的数据库维护计划

以上的列表就是我的迁移计划中的主要步骤，仅供参考。当然根据不同的环境和使用者的情况，可以调整出一套更适合自己的文档来满足需求，比如升级时的顺序，

手把手教你使用DMA

经过上面，我们直奔主题，讨论如何使用DMA帮助我们初始评估迁移，在正式迁移之前需要一个预估。首先，请到微软的下载中心（），下载最新版本的DMA。然后安装，无论是服务器还是客户机，当你运行DMA后画面如下，当你是第一次打开这个向导时，需要创建一个项目。点击左侧的“+”号

开始屏幕

下一个屏幕中将会有两个选项:

1) Assessment

2) Migration

这里我们选择assessment，因为这时我们是评估并不是真的要迁移。在开始实际迁移之前，我们要评估所有的事实并分析报告。发现潜在的问题。

在选择后，你需要制定一个项目名称，比如我这边是从2014升级到2017，SQL2K14toSQL2K17。

在剩下的部分，你需要选择自己的源和目标服务器选择类型:

源数据库类型即你计划迁移、升级的数据源类型，我这里选择的是SQL Server，当然也是支持其他类型数据源的。

目标服务器类型只能选择SQL Server 或者Azure DataBase。我选择的是SQL Server。

完成所有选型后，点击创建按钮

这里将会创建你的评估项目，并且打开一个新的屏幕。新屏幕上将给你一个选项来选择目标数据库版本。我选的是2017。这里版本基于你的目标服务器类型。如果选择Azure服务器将会是Azure的版本，

让我们继续，选择多选框，这里选中兼容性问题和新特性推荐。Check feature parity不能选择是因为这个选项是专门为Linux 上的数据库准备的。

接下来，需要连接源数据库的信息和权限。在屏幕下方，看到实例有关权限集的信息。点击Connect按钮连接数据库。

一旦，成功连接，下面就会真是给你可用的数据库。选择数据库评估迁移。这时你已经能够灵活的选择一个还是多个数据库进行迁移。

这里我选择了两个数据库，执行对它们的迁移评估。在点击ADD按钮后，下个界面将会开启迁移评估。

评估时间取决于你的数据库大小，在下个界面，你会看到评估进度。

最后DMA完成所有评估，下图展示界面会展示评估结果。这个界面提供了情报信息帮助了解当前迁移的状况。包含了很多实际迁移中会触发的信息。

DMA提供了一个选项导出评估报告，两种格式; 1. JSON 2. CSV。这也简化了我们制作评估的难度，方便给其他人看。

保存结果。迁移与评估操作基本类似这里就不在重复操作了。

总结

DMA是一个强大的工具，能够评估SQL Server 升级和迁移到更高版本，从而满足公司和业务的需要。这个工具帮助迁移SQL Server到本地服务器或者是Azure上服务器。本篇我们一起一步一步的执行了整个SQL Server 2014 到 SQL Server 2017的迁移。按照我之前所列的步骤将其他任务依次完成，最后我这边完整升级了整个系统并没有出现其他问题。希望大家也能完美升级，不出bug。