SQL Server 2008至金仓数据库的迁移实践及经验分享
SQL Server 2008至金仓数据库的迁移实践及经验分享
一、项目背景
由于国产化趋势,某医疗单位采购了一套金仓数据库v8的生产数据库系统,此次升级的核心目标是将现有的HERP系统所使用的SQL Server数据库平稳迁移至金仓数据库V8平台。
作为原厂技术支持团队的一员,我全程深度参与了这一复杂而精细的迁移过程,并详细记录了迁移的关键步骤与经验,以供业界同仁参考与借鉴。
二、迁移计划
为确保迁移适配工作的安全顺利进行,我们会在前期实施二次模拟测试,并确保后续生产环境的迁移方式、步骤与测试环境保持完全一致。
|
HERP系统迁移计划明细表 |
||||
|
序号 |
工作 |
步骤 |
处理方 |
预计时常 |
|
1 |
旧环境准备 |
Sqlserver打开tcp链接 |
Xx |
这部分工作为准备工作,不计入停机时间。 |
|
2 |
数据库对象统计 |
xx |
||
|
3 |
兼容性列表对比 |
Xx |
||
|
5 |
新环境准备 |
安装金仓数据库v8系统 |
xx |
|
|
6 |
迁移工具准备 |
Xx |
||
|
第一次模拟迁移 |
配合应用方调整数据库相关对象、测试业务系统的稳定性,并记录和处理过程中的问题。 |
Xx |
||
|
16 |
第二次模拟迁移 |
配合应用方调整数据库相关对象、测试业务系统的稳定性,并记录和处理过程中的问题。 |
xx |
|
|
正式切割 |
停掉应用,然后进行迁移。 |
Xx |
10分钟 |
|
|
迁移到金仓数据库预计总时长:10分钟,失败回退6分钟; |
||||
|
20 |
完善备份 |
xx |
不停机做 |
|
通过前期第一次和第二次模拟测试,将问题处理完成后,已具备迁移条件,整个数据迁移时间大概10分钟就可以完成。
三、迁移前所需的环境准备
迁移工具采用金仓数据库数据迁移工具(KDTS), KDTS支持结构迁移、支持全量数据迁移、支持列名映射,支持数据迁移过滤,在配置数据任务时,可以对迁移的表配置where条件、通过匹配的where条件过滤需要迁移的数据。
使用KDTS迁移异构数据库的主要步骤包括:迁移前准备和数据迁移。

1、获取SqlServer数据库的相关信息
迁移前,应获取源数据库SqlServer服务名及迁移的数据规模信息。用于工具的登录操作。
(1)SqlServer数据库基本信息
获取源SqlServer数据库的:
1.IP地址;
2.实例名;
3.网络服务端口号;
4.用户名/密码。
5.大小写是否敏感
6.数据库编码方式
7.查看有哪些表为分区表
(2)在目标KingbaseES 上:
1.创建与源SqlServer用户同名的用户;
2.创建与源SqlServer同名的数据库;
3.创建与源SqlServer(与用户名相同)同名的模式,属主为相同;
4.大小写是否敏感与SqlServer匹配(sql server默认不区分大小写,但是用户可以自己定义大小写是否区分);
5.查看表数据量大小;
6.分区表信息与SqlServer一致;
7.配置kingbaseES的SqlServer兼容开关。
(3)移植数据库、用户和模式
在目的数据库KingbaseES上创建与源数据库SqlServer同名的用户、数据库和模式,并且授予新建用户具有使用该数据库和新建模式的所有或适当的权限。另外,所创建数据库的字符集应与SqlServer数据库字符集一致。如果KingbaseES已有同名数据库,则登录该数据库后,只需创建同名用户和属主为该用户的同名模式。
(4) 配置JDBC数据源
配置KingbaseES和SqlServer的JDBC/ODBC数据源,并设置相关的连接信息。
(5)配置目的库KingbaseES性能参数
为了提高迁移速度,应对目的库KingbaseES进行性能优化配置。例如:
1.根据迁移数据规模的大小,迁移前可预先创建适当大小的数据和日志文件。开始迁移之前根据待迁移数据库的大小,保证KingbaseES数据目录所在位置有足够的空间。
2.根据KingbaseES服务器硬件配置的实际情况调整shared_buffers大小,默认是128M,建议调整为内存的1/4大小。
四、预迁移准备
1、启动KDTS迁移工具
KDTS迁移工具有两个版本选择,SHELL版本和BS版本,支持各种关系型数据库和非关系型数据库之间的数据迁移和转换。它默认不需要单独安装,是和金仓数据库软件一起被安装到了服务器上,我们只需要找到对应的位置,手工运行起来即可。
WEB版本和SHELL版本的区别:WEB更直观,SHELL可操作性、可定制性更强,这里我主要是使用的WEB版本来进行迁移的准备。
端口:启动完成后,默认会打开两个端口:54523、54524,前面是http服务,后面是https服务的端口。



2、打开KDTS迁移工具
--账号和密码默认为kingbase/kingbase

3、源数据配置

--选择“源数据库”,然后选择“新建”,根据实际情况进行填写。



--如上,填写源服务器相关配置后,测试并确定保存即可。
4、目标数据库配置

--新服务器ip
kingbase=# create database herp_import;
CREATE DATABASE
kingbase=# create user sa with password '123qwe,./' superuser;
CREATE ROLE
kingbase=# create schema dbo;
CREATE SCHEMA
kingbase=# alter role sa set search_path=dbo,"$user",public;
ALTER ROLE
kingbase=# alter database herp_import set search_path=dbo,"$user",public;
ALTER DATABASE
kingbase=# grant usage on schema dbo to public;
GRANT
kingbase=# grant select on all tables in schema dbo to public;
GRANT
--准备新服务器数据库环境(用户、schema、权限相关设置)
目标端使用同样步骤添加“源数据库”,进行配置。此处“数据库类型”选择“KINGBASE”,“KES兼容模式“选择SqlServer,连接名称自定义。


5、第一次和第二次模拟迁移测试
(1)创建迁移任务
新建任务包含四步:“选择数据源”、“选择模式”、“选择迁移对象”、“配置参数”。
选择“迁移任务”,然后选择“新建”

(2)选择数据源
--原数据库连接名和目标数据库连接名均为数据源配置管理中创建的,这里直接选择即可。

(3)选择模式
--选择迁移的模式,还有过去后这些对象的属主;
--这里特别注意,不同数据库的过程函数等是不同的,为了确保顺利,一般都得开发或者实施人员提前进行修改,这里排除掉,迁移完成后手工创建这部分内容。

(4)选择迁移对象
通过已选模式选择您需要迁移数据的表,模式较多时可在已选模式搜索框内输入模式名关键字进行快速检索。

(5)配置参数
--迁移的参数配置(这部分主要是加快提取和恢复到目标库的时间),根据自己的情况进行设置。

--数据映射就是不同库之间的数据字段,目标库用什么来存放,这里要确认下:

(6)保存迁移任务
将此任务作为预迁移任务点击“保存”,等待正式迁移。

五、正式切割
按照上面的操作,创建完成迁移任务后,即可开始迁移。




--迁移完成后数据对比



六、问题与总结
在这次迁移测试过程中,我们确实遇到了一些需要应用适配修改的问题。例如,别名赋予存在差异:SQL Server 支持使用等号(=)或 AS 关键字加单引号的方式来赋予别名,同时涉及某些关键字别名和系统视图的兼容性问题,以及在未加分号的情况下执行多条SQL语句的语法问题。此外,还存在一些函数返回值差异等问题。
但是,由于该系统已经稳定运行多年,甲方自然不愿进行大规模的代码修改。因此,我们的研发团队针对测试迁移中发现的问题进行了全面梳理和修改,并发布了补丁包,最终在“SQL Server模式”下实现了全面兼容。这使得最终的正式迁移过程非常顺利。
国产化数据库迁移过程中难免会遇到一些兼容性问题。解决这些问题,要么需要找到代码的同义替换方法,要么要尽量减少代码改动。这时,数据库研发团队的出手修复就显得尤为重要。
这次迁移让我学到很多,真心感谢团队的付出!以后再遇到类似的SQL Server国产化迁移的工作,心里更有底了。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐
所有评论(0)