sqlserver数据库迁移
本篇我们将利用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帮助我们初始评估迁移,在正式迁移之前需要一个预估。首先,请到微软的下载中心(https://www.microsoft.com/en-us/download/details.aspx?id=53595),下载最新版本的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。
<a>出自A</a>