金仓数据库 KingbaseES V8.3 至 V8.6 迁移最佳实践（4. V8.3 到 V8.6 数据库移植实战）

4. V8.3 到 V8.6 数据库移植实战

由于 KingbaseES 内部兼容特性，在实际应用中，一般只需很少甚至不做任何修改，用户便可把 V8.3 数据库移植到 V8.6 环境中运行。不仅如此，用户还可利用 KDTS-PLUS 等多种工具简化移植过程。

本节重点描述了在实际应用中移植一个 V8.3 数据库系统的完整过程，以及其中的主要移植内容、常用移植方法和关键移植步骤。

本章节包含以下内容：

• 主要移植内容

• 关键移植步骤

4.1. 主要移植内容

在实际应用中，一个 V8.3 数据库系统的移植主要包括如下内容。这些内容的迁移是存在先后顺序的。若违反该顺序，则可能导致迁移受阻。

4.1.1. 数据库、用户和模式移植

数据库和模式是各种 SQL 和 PL/SQL 数据库对象的存放容器，而用户是这些对象的管理者和使用者。因此，在迁移数据库对象之前，一般应先迁移数据库、用户和模式。

那么，如何移植这些内容呢？应在目的数据库 KingbaseES V8.6 上创建与源数据库 V8.3 同名的数据库、用户和模式，并授予新建用户具有使用该数据库和新建模式的所有或适当的权限。

另外，所创建数据库的字符集应与 V8.3 数据库字符集一致。如果 KingbaseES 已有同名数据库，则登录该数据库后，则只需创建同名用户和属主为该用户的同名模式。

4.1.2. V8.3 数据迁移

根据数据迁移时，应用系统确定使用在线迁移还是离线迁移，根据不同需要可能需要使用 KDTS-PLUS 和 KFS 完成数据库迁移。

4.1.3. 应用程序移植

在完成数据库对象迁移以后，才可开始迁移应用程序，主要原因是：在用程序中，可能会访问和操作前面迁移的数据库对象。

应用程序移植主要包括接口驱动程序和连接方法的移植，以及 V8.3 扩展或私有的、且 V8.6 未兼容的 API 移植。通常，该项任务的工作量较少。

在实际应用中，通常应用程序移植与移植系统测试与调试交叉进行。

4.2. 关键移植步骤

作为一个典型的项目过程，数据库移植应具有健全的项目团队和全面细致的的项目执行过程。通常，移植一个 V8.3 数据库主要包括以下步骤：

• 确定移植目标

• 评估移植任务

• 组建移植团队

• 准备迁移环境

• 数据库以及用户和模式迁移

• 数据迁移

• 应用代码迁移

• 测试与调试移植系统

这些步骤指之间的关系是：前四个步骤是迁移前的准备工作，这些准备工作是确保后续 V8.3 移植顺利进行的前提条件，而最后一步是保证最终移植系统正确性和可用性的关键步骤。

下面，分别对上述各个步骤进行详细说明。

4.2.1. 确定移植目标

开始迁移前，应根据用户的实际需求，确定移植目标。这些目标诸如：

• 迁移 V8.3 数据库的规模。

• 迁移 V8.3 数据库对象的种类和特征，如简单和复杂迁移对象所占比例等。

• 迁移的难易程度，如是否迁移大对象，是否迁移大量约束等。

• 迁移的工期要求。

• 对目标系统的技术指标要求，诸如平台、版本、应用编程接口、工具、可用性、安全性和性能指标要求等。

明确移植目标以后，则可开始移植任务评估。

4.2.2. 评估移植任务

当计划把一个 V8.3 数据库系统移植到 V8.6 环境时，如果不做评估或评估不充分的话，那么整个移植工作会存在很多潜在风险，额外增加移植工程师的工作量并且无法确认移植完成时间。因此，移植前对移植的可行性、工作量、难易程度和工作进度等进行充分评估是非常必要的。

通常，移植评估主要包括以下内容：

• 移植技术指标，如移植业务压力和性能指标等。

• 移植数据规模，如移植各类数据库对象的数量，PL/SQL 程序的规模等。

• 移植中 V8.6 不支持功能的种类和数量。

• 移植的约束种类和数量。

• 移植过程中可能遇到的其他问题。

在移植中常用的评估模板如下表所示：

表 4.2.6  移植评估的数据库 / 应用概况模板

项目	描述	备注
V8R3 数据库版本	8.3
操作系统版本	Winodws 2000/2003 Server
服务器型号	联想 / SUN
CPU 配置
内存（RAM）
磁盘（Disk Profile）
服务器个数（# of Servers）	1 或 2
用户数 / 天（# Users/Day）	几十 / 天
事务量 / 天（# Transactions / Day）
当前数据库大小	几个 GB
数据库增长速率（#GB/month）
目标用户（Schema）
应用方式（OLTP/OLAP）	OLTP
应用服务器（中间件）	无
客户端应用类型 （C/S，B/S）	C/S
客户端应用编程语言	Delphi7
客户端应用连接接口	ODAC/ADO
是否深入的 SQL 应用	无
监控工具	无
备份方式	Exp/imp
其它工具（备份软件等）	无
高可用要求	较高
高可用配置方案	VCS 或单机

表 4.2.7  移植评估的移植报告总结模板

项目	描述
移植分析日期	20111009 下午
移植分析人员
KingbaseES 版本
V8R3 版本	8.3
V8R3 Schema
V8R3 DB Size (GB)	几个 GB
V8R3 Schema Size (MB)	几个 GB

表 4.2.8  移植评估的对象统计模板

类型	小计	备注
Function	7	较少用
Index	有
LOB	有	最大到几十 MB，主要是照片、word、视频（较少）
Materialized View	有 > 10
Pro*Cedure	25
Sequence	有 > 10
Table	1660	约束较多
Table Partition	无
Trigger	<30
JOB	无
Package	无
Package Body	无
Type	无
View	>200
Synonym	>300
对象共计

表 4.2.9  移植评估的约束统计模板

类型	小计	备注
CHECK OR NOT NULL
FOREIGN KEY
PRIMARY KEY
UNIQUE KEY
OTHER
约束共计

表 4.2.10  移植评估的其它方面模板

特性	小计	备注
数据压缩	无
索引组织表	无
维度（Dimensions）	无
物化视图	无
存储概要	无
高级队列	无
空间数据管理	无
全文搜索	有
数据库链接	无
数据复制	无
RAC	有
逻辑 standby	无
物理 Standby	无
自动存储管理 ASM	无
自动工作负载信息库 AWR	无
共计

4.2.3. 组建移植团队

任何一个高效、成功的项目都应具备一个健全和良好的团队， V8.3 数据库移植也不例外。如果没有这样团队互相配合和支持，那么 V8.3 数据库移植将可能存在巨大的风险。所以，组建一个高效的移植团队是非常必要的。

那么，移植团队的组成人员应具备哪些条件呢？他们应至少具备以下的知识与技能：

• 熟悉 V8.3 和 V8.6 的 SQL 语言和 PL/SQL 语言特性，以及相关的 KingbaseES 版本兼容特性。

• 熟悉 V8.3 和 V8.6 的各种应用编程接口，以及相关的 KingbaseES 版本兼容特性。

• 熟悉 V8.3 和 V8.6 的相关客户端工具，以及这些工具间的相同点和异同点。

由这些优秀人员组建的团队是高效移植 V8.3 数据库的可靠保障。

4.2.4. 准备迁移环境

在上述步骤完成以后，移植工程师应开始准备迁移环境了，这些准备工作诸如：

4.2.4.1. 部署目的数据库服务器

部署目的数据库服务器应遵循以下原则：

• 目的数据库服务器的 CPU、内存、网络环境等硬件应尽量采用较高的配置。

• 如果移植的 V8.3 数据库系统规模较大，如超过 1GB，则建议把 V8.6 和 V8.3 部署在不同的物理机器上。

• 为确保迁移效率，应尽量把 V8.6 和 V8.3 服务器部署到同一局域网内。

4.2.4.2. 获取并安装必要的软件

迁移前应获取并安装如下软件： V8.3 数据库系统、 V8.6 数据库系统、JDBC 和 ODBC 驱动程序、C 语言开发工具、OCI 软件、DCI 软件、TPC-C 测试工具、LoadRunner 等。

如果迁移数据规模较大，建议对安装的 V8.6 数据库服务器进行适当的优化，如增大 shared_buffer 大小、预先创建较大的日志文件，预先申请足够的表空间数据库文件等。

完成上述准备工作后，移植工程师便可开始 V8.3 数据库移植工作了。

4.2.5. 数据库以及用户和模式迁移

数据库、用户和模式迁移主要包括以下内容：

• 获取源 V8.3 数据库的 IP 地址、实例名、网络服务端口号、用户名 / 密码等信息。

• 在目的 V8.6 数据库上，使用 KSQL 或 Kstudio 工具上执行如下操作：

• 创建与源 V8.3 用户同名的用户，例如创建与 V8.3 同名的 system 用户。

• 创建与源 V8.3 同名的数据库，例如创建与 V8.3 同名的 test 数据库，它的属主为 system。

• 创建与源 V8.3 同名的模式，例如创建与 V8.3 同名的 public 模式，它的属主为 system。

4.2.6. 数据迁移

KingbaseES 数据迁移工具 KDTS-PLUS 动态加载待迁移的数据库访问接口，方便用户定制和使用。

KingbaseES 数据同步工具 KFS 支持同构数据源之间的数据迁移

同构数据源间数据迁移：支持 Kingbase V7 和 V8.3 到 KingbaseES V8.6 的数据迁移。

异构数据源之间的数据迁移：支持 Oracle9i、10g、11g、12c 到 KingbaseES V8.6 的数据迁移。

KingbaseES 数据同步工具 KFS 支持结构迁移、支持全量数据迁移、支持列名映射，支持数据迁移过滤，在配置数据任务时，可以对迁移的表配置 where 条件、通过匹配的 where 条件过滤需要迁移的数据。

数据库迁移时需要按照用户需求确定在线迁移还是离线迁移，若是离线迁移，使用 KDTS-PLUS 完成 Oracle 的完整迁移；若是在线迁移，则首先需要使用 KDTS-PLUS 完成历史数据迁移，然后使用 KFS 完成数据的在线追平。

本节包括：

• 迁移前准备

• 离线迁移

• 在线迁移

• 多次迁移

4.2.6.1. 迁移前准备

在使用 KDTS-PLUS 迁移 V8.3 数据库之前，应先做如下准备工作：.

4.2.6.1.1. 获取 |V8.3| 数据库的相关信息

迁移前，应获取源数据库 V8.3 的登录信息以及需要迁移的数据规模信息。其中，前者用于 Kstudio 工具的登录操作，后者用于估算数据迁移时间和设计迁移方案。

1. |V8.3| 数据库基本信息

获取源 V8.3 数据库的：

1). IP 地址；

2). 数据库名；

3). 网络服务端口号；

4). 用户名 / 密码。

在目标 V8.6 上：

1). 创建与源 V8.3 用户（如 SYSTEM）同名的用户（system）；

2). 创建与源 V8.3 （如 TEST）同名的数据库（test），属主为 system；

3). 创建与源 V8.3 （与用户名相同）同名的模式，属主为 system。

2. 查询 V8.3 数据库编码方式

SHOW SERVER_ENCODING;
【Kingbase初始化设置编码方式】
--encoding=GBK（支持 GBK UNICODE ASCII)

3. 查看表数据量大小

查看当前用户在 V8.3 中的表大小

select nspname, relname, sys_size_pretty(sys_table_size(sys_class.oid::regclass))
from sys_class, sys_namespace
where relnamespace not in (99, 11) and relkind = 'r' and relpersistence = 'p'  and relnamespace = sys_namespace.oid;

4. 检查数据库日期格式

时间的默认格式为：ISO, MDY

在配置文件中添加：datestyle ='ISO,YMD' 修改为年月日的格式（99 会改为 1999）。

4.2.6.1.2. 移植数据库、用户和模式

在目的数据库 V8.6 上创建与源数据库 V8.3 同名的用户、数据库和模式，并且授予新建用户具有使用该数据库和新建模式的所有或适当的权限。另外，所创建数据库的字符集应与 V8.3 数据库字符集一致。如果 V8.6 已有同名数据库，则登录该数据库后，只需创建同名用户和属主为该用户的同名模式。

4.2.6.1.3. 配置 JDBC 数据源

配置 V8.3 和 V8.6 的 JDBC 数据源，并设置相关的连接信息。

4.2.6.1.4. 配置目的库 KingbaseES 性能参数

为了提高迁移速度，应对目的库 KingbaseES 进行性能优化配置。

例如：

1）根据迁移数据规模的大小，迁移前可预先创建适当大小的的数据和日志文件。

开始迁移之前根据待迁移数据库的大小，保证 KingbaseES 数据目录所在位置有足够的空间。

2）根据 KingbaseES 服务器硬件配置的实际情况调整 shared_buffers 大小，默认是 128M，建议调整为内存的 1/4 大小。

4.2.6.2. 离线迁移

在完成上述准备工作以后，用户可使用 KDTS-PLUS 进行数据的离线迁移，KDTS-PLUS 提供了两种形态（BS、SHELL），用户可根据需要进行选择，以下章节将分别介绍 BS、SHELL 版本进行 V8.3 迁移的具体步骤。

4.2.6.2.1. BS 迁移步骤

• 创建源数据库连接

创建源库数据库连接。创建数据库连接界面如下，填写数据源信息，包括： “连接名称”、“数据库类型”、“数据库版本”、“服务器地址”、“端口”、“用户名”、“密码”、“数据库”、“驱动”、“URL”、“连接参数”。

• 创建目标数据库连接

创建目标数据库连接。创建数据库连接界面如下，填写数据源信息，包括： “连接名称”、“数据库类型”、“数据库版本”、“服务器地址”、“端口”、“用户名”、“密码”、“数据库”、“驱动”、“URL”、“连接参数”。

• 新建迁移任务

KDTS-PLUS 采用向导页的方式指导用户新建迁移任务，简单易用，用户依次配置 “选择数据源”-“选择模式”-“选择迁移对象”-“配置参数”，即可快速配置一个迁移任务。

1. 选择数据源

   填写自定义任务名称（任务名称不能重复），选择 “源数据库” 和 “目标数据库”，或者选择 “新建数据源” 后使用。

   

2. 选择模式

   根据您的数据迁移所需选择对应模式（如需选择模式在系统模式中可选中 “包含系统模式” 复选框）的表、视图、序列、函数、存储过程、程序包、同义词。当模式较多时也可以通过左上方的查询框进行检索。 请您至少选择一种模式，否则将收到错误提示，以至于不能完成新建任务。

   

   在选择模式的前提下如您未选择 “表”，即没有迁移对象，则系统将认为您不需要迁移对象，将提示您直接跳过 “选择迁移对象” 进入 “配置参数”。

3. 选择迁移对象

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

   

   可迁移此模式下全部表，也可以指定或排除部份表，当您选择 “包含指定表” 或 “排除指定表” 时，请您通过 “从列表选择”、“从文件导入” 或者在输入框内输入表名将数据添加到包含列表中，如您未添加数据，则会提示错误导致无法进行下一步并完成新建任务。

   

   当您点击 “包含指定表” 时也可选择多种方式。可直接在输入框内填写表名，多个表用 “，” 分割，回车确认；“从列表选择” 可在模式中选择指定表；

   从列表选择表时，可选择对应模式、检索表名关键字、数据条数限制进行快速检索对应的表。点击 “添加” 按钮后加入到已选列表，当您想要移除部份表时可以选择对应的表点击 “移除” 按钮取消表。选择完成后点击确定。

   

4. 配置参数

   可以通过对参数的更改获得预估的数据迁移结果。其中迁移配置包括 “表默认处理方式”、“表排序依据”、“表数据读取和写入”、“大表拆分阈值依据”、“非对象设置”、“数据库连接数设置”。数据类型配置包括 “源数据类型”、“目标数据类型”、“长度限制”。

   

   

   • 表默认处理方式：

     包括两个复选框项（“建表 / 重建表”、“导入数据”），迁移到 V8.6 数据库是否需要建表或者重建表，以及是否只迁移表结构而不迁移数据的选择，根据您的需求选择合适的选项（默认是全选）。

   • 表排序依据：

     对迁移的表进行排序，可通过 “按行数和大字段大小交替”、“行数”、“大小进行排序”（默认是按行数和大字段大小交替）。

   • 表数据读取和写入：

     对表数据的读取和写入制定规则，可操作项包括 “源库游标读取记录数”（默认是 100）、“批量写入目标库记录数”（默认是 1000）、“每次批量提交大小”（默认是 100MB）、“LOB 字段预读取大小”（默认是 4000Byte）。

   • 大表拆分阈值依据：

     对大表进行拆分迁移，设置拆分界限。

   • 非对象设置：

     其中包含 “主键”、“检查约束”、“唯一约束”、“外键”、“索引”、“触发器”、“自动转换对象名”。您可以根据自己的需求选择是否迁移这些非对象数据（默认是全选）。

   • 数据库连接数设置：

     您可以限制迁移程序对源数据库和目标数据库的最大连接数（默认是 100）。

• 执行迁移任务

可将此任务作为预迁移任务点击 “保存”，或者作为执行任务点击 “保存并迁移”。

• 迁移完成：

迁移结束 “状态” 栏显示 “完成”，则迁移任务成功。

• 迁移失败：

迁移结束 “状态” 栏显示 “失败”，则迁移任务失败。失败后可点击详情查看日志有助于解决问题。

• 查看迁移报告及问题处理

迁移完成后，需要确认执行结果，包括迁移数据量，是否有错误发生，可以通过迁移日志和迁移结果进行查看。

“迁移日志” 打印迁移任务执行后的日志，具体可分为 “系统日志”、“Error 日志”、“Info 日志”。

“迁移结果” 功能的工作区包括 “任务执行批次”、“迁移对象”、“总数”、“成功数”、“失败数”、“略过数”、“操作”。您可以查看历史迁移任务执行的每次记录，以及每次迁移的对象、成功数、失败数、查看失败任务的错误日志。

4.2.6.2.2. SHELL 迁移步骤

• 目录说明

• bin: 启动脚本

• conf: 配置文件

• doc: 帮助文档

• drivers: 数据库连接驱动（注意不同版本驱动的存放目录差别，详见 readme.md）

• jdk: jdk

• kdms: kdms 程序

• lib: 程序包

• logs: 日志

• result: 迁移报告

• JDK 安装

  下载与 KDTS-PLUS 安装服务器相匹配的 JDK（需要匹配操作系统和 CPU 架构，如 Liunx/AArch64、Linux/x64、Windows/x64 等），版本选择 JDK 15 或更高。下载地址: https://jdk.java.net/archive/

  将下载的 JDK 解压到 kdts-plus/jdk 目录下

  注意：

a、请使用解压版本的 JDK，以免安装 JDK 影响服务器上的其它应用。

b、不要把当前的 JDK 加入系统环境变量，以免影响服务器上的其他应用。

c、如果需要使用服务器上已有的 JDK，配置 bin/startup.sh（Windows 平台为 startup.bat）中的 JAVA_PATH 即可。

• 配置数据库连接信息

• 进入 kdts-plus/conf 目录下，打开 application.yml 文件，根据源库类型设置当前激活的源库配置（active: kingbase_kes），如下所示：

  

  在正确设置 application.yml 中的 active 项后，打开对应配置文件（kdts-kingbase_kes.yml），按实际运行环境进行配置即可。

• 配置源端数据库连接信息、目标数据库连接信息

编辑 conf/kdts-kingbase_kes.yml 文件，编辑源端和目标端连接信息，包括 url、driver-class-name、username、password 信息，如下图所示：

• 配置要迁移的源库模式，数据库对象，涉及到的参数见下图：

  

• 迁移配置参数说明

  编辑 conf/kdts-kingbase.yml 文件有多个配置参数，可灵活使用。以下列举常用的配置参数。

• fetch-size：

  源数据库游标读取记录数，在一定范围内增加该值可提升读取效率，但会增加内存开销。

• table-with-large-object-fetch-size:

  源数据库含大对象数据表的游标读取记录数，此参数针对有大对象字段的表。

• large-table-split-threshold-rows：

  大表拆分阈值行数（当表的行数超过此值时，将对表进行拆分，每块的记录数为此值和表总记录数除以 “拆分最大块数” 中的最大值）。

• large-table-split-threshold-size：

  大表拆分阈值大小（单位为 M），当表的数据大小（普通字段 + 大对象字段）超过此值时，将对表进行拆分。

  • large-table-split-condition-file：

  大表拆分条件定义文件，优先于按行数和大小拆分。

• table-data-filter-condition-file：

  表数据过滤条件定义文件。

• use-kdms:

  是否使用 kdms 做转换（视图、函数、存储过程、包、触发器）。

• kdms-url:

  kdms 访问地址，前提是 use-kdms: true

• write-batch-size:

  目标数据库表数据批量提交记录数.

• write-batch-size-big-lob：

  目标数据库表数据批量提交记录数，特指大对象数据。

  • drop-existing-object：

    是否默认删除目标库中已存在的对象（如表、视图等）。

  • truncate-table：

    是否默认清空目标库中已存在的表数据。

• rename-object：

  目标数据库对象重命名，除表名、列名外的其他对象: pk、fk、constraint、unique constraint、index 等。

• 线程相关设置

  线程相关设置可根据实际服务器配置按比例调整，如果与目标数据库运行在同一服务器上，应将绝大部分资源分配给数据库。

  进入 {安装路径}/kdts-plus/conf 目录下，打开:kb-thread-config.xml，如下图所示：

  

  数据迁移属于 IO 密集型操作，涉及网络络 IO 和磁盘 IO 的交互，一旦发生 IO，线程就会处于等待状态，当 IO 结束，数据准备好后，线程才会继续执行。为提升数据迁移的效率可以多设置⼀些线程池中线程的数量，避免任务等待，线程可以去做更多的迁移任务，提高并发处理效率。但不是线程数设置的越高，效率就越高，线程上下文切换是有代价的。 对于对于 IO 密集型线程数的设置公式为：线程数 = CPU 核心数 /(1 - 阻塞系数) ，其中阻塞系数一般为 0.8~0.9 之间，取 0.9 则：

  双核 CPU： 2/(1-0.9) = 20

  64 核 2 路 CPU： 64*2/(1-0.9) = 1280

• 启动脚本

  • 进入 {安装目录}/kdts-plus/bin 目录下，编辑: startup.sh

  • 检查 JDK 的路径是否正确

  JAVA_PATH=${BASE_PATH}"/jdk"

  • 设置 JVM 内存

    根据当前服务器的配置，调整 JVM 参数

    JAVA_OPT="-server -Dfile.encoding=UTF-8 -Dconfig.path=${CONFIG_DIR} -Xmx16g -Xms16g" 主要是: -Xmx16g -Xms16g 参数

  • 启动运行脚本

    进入 kdts-plus/bin 目录，执行: ./startup.sh

• 查看迁移报告及问题处理

  可以在运行日志（kdts_info.log）中查看到迁移整个过程的信息，包括任务启动、迁移进程、结果汇总

  可查看 result 下的迁移结果（在形如 “result/2021-12-02_15-15-15/Sehcma1” 目录下）

• index.html-- 报告主页面

• detail_XXX.html--XXX 详细信息（如表结构、表数据、表主键等）

• FailedScript-- 失败脚本目录

• IgnoredScript-- 略过脚本目录

• SuccessScript-- 成功脚本目录

在迁移过程中一旦某个对象创建失败，KDTS-PLUS 会将该对象的创建 sql 保留到本次迁移任务文件夹下的 FailedScript 目录下 *.sql 文件，用户可以手动修改后通过 ksql 或者 KStudio 工具手动执行。

4.2.6.3. 在线迁移

在线迁移时，首先需要使用 KDTS-PLUS 完成历史数据搬迁，之后使用 KFS 进行在线数据追平。

4.2.6.3.1. 在源端数据库中创建一致性状态

1. 连接数据库

ksql -d "host=10.10.3.3 user=SYSTEM password=123456 replication=database dbname=test_snapshots port=54366"

这里用了一种特殊的连接方式。

2. 手动创建复制槽并生成对应的快照

CREATE_REPLICATION_SLOT slot_name LOGICAL decoderbufs;
 slot_name | consistent_point |    snapshot_name    | output_plugin
-----------+------------------+---------------------+---------------
 slot_name | 0/A705E0C8       | 0000000C-0001EEAF-1 | test_decoding

 注意：此处的复制槽名称为1.1节中记录的复制槽名称
 注意：decoderbufs.so文件的权限需要为664

4.2.6.3.2. 存量数据迁移

使用 KDTS-PLUS 完成存量数据的迁移。

4.2.6.3.3. 启动 KFS 完成数据追平

使用 ONLINE 命令，将源端的 KFS 拉起来。 正常情况下，KFS 应该从 1.2 节中手动创建的复制槽中开始取数据。（由于 1.2 节中的创建的快照和复制槽处于一致的数据点，即做到了使用数据库的逻辑备份还原工具 + KFS 实现不停机的数据迁移）。

确认源端无误后，将目标端 KFS ONLINE（从源端第一条 KUFL 开始同步）

4.2.6.4. 多次迁移

若项目开发过程中，需要定期从一个指定的源数据库迁移到目的数据库中， 那么根据迁移时源数据库和应用的状态，决定离线迁移还是在线迁移。

同时，由于是多次迁移，需要考虑每次迁移时数据库对象的定义是否需要迁移， 若不需要，则只迁移数据就可以，使用 KDTS-PLUS 和 KFS 都支持只迁移数据； 若每次迁移时需要迁移对象定义，则

1）比较源和目的对象定义是否发生变更

2）对于定义发生变更的表，选择迁移定义和数据

3）对于定义没有发生变更的表，只同步数据即可。

4.2.7. 应用代码迁移

数据移植后，需要迁移应用系统中用到的服务器应用代码和客户端应用代码迁移。KingbaseES V8.3 和 V8.6 的兼容性高，一般不需要对应用代码进行修改，就可以直接迁移。特殊情况下，不兼容部分可参考兼容性简介章节 KingbaseES V8_3 和 V8_6 兼容特性概览 。

4.2.8. 测试与调试移植系统

任何一个成熟的应用系统如果代码、尤其是关键代码变动后，则应进行全面细致的测试。类似的，更换新的后台数据库系统以后，也应对移植后的数据库系统进行全面的功能和性能测试。

4.2.8.1. 功能测试和排错

功能测试是指对移植数据库系统的每一个模块和功能进行全面的系统回归测试，用以确保新系统各个功能的正确性。

因此，完成数据库对象和应用程序迁移后，应对移植系统进行全面的功能测试，并对测出问题及时分析、排查和修改。对那些很难定位的问题，请及时联系 KingbaseES 支持工程师。

4.2.8.2. 性能测试和调优

移植系统性能测试和调优是在完成移植系统功能测试后和系统上线前，在实际或模拟生产数据上，对移植系统进行的性能测试和调优。

移植系统性能测试和调优的主要步骤如下：

• 构造测试数据：若条件允许的话，建议构造与实际生产数据规模相同的数据，并模拟构造未来一年、两年、五年或更长生命周期的数据进行测试。

• 部署测试软硬件环境：根据测试数据规模的大小，配置适当的测试软硬件环境。

• 性能测试：既可采用手动方式，也可利用 TPCC 测试工具、LoadRunner 等工具对移植系统进行自动测试。

• 性能调优：对未达到性能指标的功能模块及其 SQL 语句进行优化并给出相关建议。

通常，性能测试效果与测试数据规模、软硬件配置等因素密切相关。因此，建议性能测试时，测试数据规模、软硬件配置应尽量与将来的实际生产环境一致。必要时，在未来一年、两年、五年等不同模拟数据规模场景下，应分别测试移植系统的性能指标，用以保证移植系统未来仍能具有良好的性能表现。