沉舟侧畔千帆过_

沉舟侧畔千帆过_

4. Oracle数据库移植实战

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

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

本章节包含以下内容:

4.1. 主要移植内容

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

4.1.1. 数据库、用户移植

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

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

另外,所创建数据库的字符集应与Oracle数据库字符集一致。如果KingbaseES已有同名数据库,则登录该数据库后,则只需创建同名用户。

4.1.2. Oracle数据迁移

确定使用在线迁移还是离线迁移,根据不同需要制定不同给的迁移策略,使用KDTS-PLUS 和 KFS 完成数据库迁移。

4.1.3. 应用程序移植

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

应用程序移植是指对Oracle API方式或嵌入式SQL方式的应用程序的移植。它主要包括接口驱动程序和连接方法的移植,以及Oracle扩展或私有的、且KingbaseES未兼容的API移植。通常,该项任务的工作量较少。

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

4.2. 关键移植步骤

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

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

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

4.2.1. 确定移植目标

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

  • 迁移Oracle数据库的规模。

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

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

  • 迁移的工期要求。

  • 迁移中业务系统是否可以处于停止服务状态。

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

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

4.2.2. 评估移植任务

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

通常,移植评估主要包括以下内容:

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

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

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

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

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

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

4.2.3. 组建移植团队

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

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

  • 熟悉Oracle和KingbaseES的SQL语言和PL/SQL语言特性,以及相关的KingbaseES Oracle兼容特性。

  • 熟悉Oracle和KingbaseES的各种应用编程接口,以及相关的KingbaseES Oracle兼容特性。

  • 熟悉Oracle和KingbaseES的相关客户端工具,以及这些工具间的相同点和异同点。

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

4.2.4. 准备迁移环境

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

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

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

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

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

  • 为确保迁移效率,应尽量把KingbaseES和Oracle服务器部署到同一局域网内。

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

迁移前应获取并安装如下软件:Oracle数据库系统、KingbaseES数据库系统、PL/SQL Developer、JDBC和ODBC驱动程序、C语言开发工具、OCI软件、DCI软件、TPC-C测试工具、LoadRunner等。

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

完成上述准备工作后,移植工程师便可开始Oracle数据库移植工作了。

4.2.5. 数据库、用户迁移

数据库、用户迁移主要包括以下内容:

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

  • 在目的KingbaseES数据库上,使用 ksql 或 Kstudio 工具上执行如下操作:

4.2.6. 数据迁移

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

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

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

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

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

本节包括:

4.2.6.1. 迁移前准备

在使用 KDTS-PLUS 迁移 Oracle 数据库之前,应先做如下准备工作:

4.2.6.1.1. 获取 Oracle数据库的相关信息

迁移前,应获取源数据库Oracle服务名及迁移的数据规模信息。其中,前者用于PL/SQL Developer工具的登录操作,后者用于估算数据迁移时间和设计迁移方案。

  1. Oracle数据库基本信息

在目标KingbaseES V8.6 上:

2. 查询Oracle数据库编码方式

3. 查看表数据量大小

4. 检查数据库日期格式

4.2.6.1.2. 配置KingbaseES的Oracle兼容开关

根据实际情况,应对目的数据库KingbaseES进行适当的Oracle兼容配置。通常,应配置以下会话级兼容参数:

1) nls_length_semantics:设定char类型字段默认单位是byte还是char。此外,标识符最大长度以此值为单位。如果它为char,则标识符最大长度为63个char,否则为63byte

2) search_path:模式搜索路径。例如search_path为*$USER,SCOTT,PUBLIC*时,系统将首先搜索与登录用户同名的模式对象,然后搜索SCOTT模式对象,最后搜索PUBLIC模式对象。

3) default_with_oidsOID伪列开关。KingbaseES的OID伪列可兼容Oracle的ROWID伪列。因此,如果Oracle移植对象有ROWID伪列,则建议用OID伪列替代。

4.2.6.1.3. 移植数据库、用户

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

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

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

例如:

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

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

4.2.6.2. 离线迁移

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

4.2.6.2.1. BS迁移步骤

  • 创建源数据库连接

  • 创建目标数据库连接

  • 新建迁移任务

  • 执行迁移任务

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

4.2.6.2.2. SHELL迁移步骤

  • 目录说明

  • JDK安装

    下载与KDTS-PLUS安装服务器相匹配的JDK(需要匹配操作系统和CPU架构,如Liunx/AArch64、Linux/x64、Windows/x64等),版本选择JDK 15或更高。下载地址: Archived OpenJDK GA Releases

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

    注意:

  • 配置数据库连接信息

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

    金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

  • 迁移配置参数说明

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

    • 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:

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

    • 线程相关设置

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

      进入 kdts-plus/conf目录下,打开:kb-thread-config.xml,如下图所示:

      金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

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

    • 启动脚本

      • 进入 kdts-plus/bin 目录下,编辑: startup.sh

      • 检查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”目录下)

    4.2.6.3. 在线迁移

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

    异构数据库数据同步在保障客户业务不停机的前提下,需要一个中间数据库(与源端数据库版本相同的单实例数据库)做媒介迁移存量数据。操作的过程分两部分。

    1. 先将存量数据迁移至中间数据库上,然后KFS loader进行初始数据搬迁或通过ETL进行初始数据搬迁至异构数据库(目标数据库)中。

    2. 待上一步操作完成,从指定断点开始启动KFS源端,正常启动目标端的KFS程序(在已经有KFS运行的情况下,可能需要重置KFS)。

    注意:在迁移源库存量数据时避免做以下操作:

    1. 运行大型批处理操作会降低复制速率。

    2. 备份时执行DDL操作将导致DML和DDL之间存在锁问题

    4.2.6.3.1. 源端数据库备份

    1.获取当前数据库一致性scn号

    2. 创建备份目录(需要sysdba权限)

    3.完整备份数据库

    4.2.6.3.2. 存量数据迁移

    1.在中间库中创建备份目录(需要sysdba权限)

    2.将源端备份的数据文件拷贝至E:/dump_dir目录下

    3.将备份的数据还原至中间库

    4.使用数据迁移工具(KDTS-PLUS)将中间库的数据搬迁至目标数据库。

    4.2.6.3.3. 启动KFS完成数据追平

    注意:若KFS之前已经部署运行,则源端和目标端需要先执行重置命令fsrepctl –service XXX reset -all –y,确认中间表、kufl文件等被清除。

    KFS部署参考《Kingbase FlySync 安装部署手册.pdf》

    源端操作

    先启动KFS到offline状态,replicator start offline。再使用ONLINE命令,将源端的KFS完全启起来,执行ONLINE命令时需要指定-from-event参数,参数值为备份数据库时查询的scn值(见步骤2)。 实例如下:

    replicator start offline

    fsrepctl -service oracle online -from-event ora:200725471: 200725471

    目标端操作:

    追平的判断方法:

    [hes@h1-105 ~]$ fsrepctl services
    Processing services command...
    NAME              VALUE
    ----              -----
    appliedLastSeqno: 3 //若源端无新数据产生,则源端和目标端相同
    appliedLatency  : 0.297  //若源端无新数据产生,延迟时间为0
    role            : master
    serviceName     : postgresql
    serviceType     : local
    started         : true
    state           : ONLINE
    Finished services command...
    

    4.2.6.4. 多次迁移

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

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

    1)对于定义发生变更的表,选择迁移定义和数据。可使用 KDTS-PLUS的“迁移部分表”功能完成,详细步骤可参考 KDTS 迁移工具使用指南 。

    2)对于定义没有发生变更的表,只同步数据即可。可使用 KDTS-PLUS的“按条件迁移”功能完成,详细步骤可参考 KDTS 迁移工具使用指南 。

    4.2.7. 应用代码迁移

    4.2.7.1. 服务器应用代码迁移

    数据移植后,需要迁移应用系统中用到的服务器应用代码,例如 PLSQL。

    KDTS-PLUS 已经完成了存储过程,函数,包等 PLSQL对象的迁移, 只需要关注应用代码中用到的匿名块的代码的迁移。KingbaseES 的 plsql 语言和Oracle的plsql高度兼容, 需要关注如下2点:

    var1 := 方法1;
    var2 := var1.方法2;
    var3 := var2.方法3;
    

    4.2.7.2. 客户端应用代码迁移

    在应用编程接口方面,KingbaseES与Oracle兼容程度较高,所以,一般情况下,应用程序迁移比较容易。应用程序迁移通常应和移植系统测试同时进行。这样可及时修改测试过程中发现的问题。

    如何在一个应用程序中访问和操纵数据库呢?通常,可采用API方式:

    该方式通过数据库厂商提供的各种标准应用编程接口在应用程序中与数据库进行交互。常用的应用编程接口如JDBC和ODBC等。目前,大多数数据库厂商均提供很多标准的数据库API及其驱动程序。

    在实际应用中,应首先加载驱动程序。加载成功后,利用API函数与数据库交互并完成对数据库数据的操作。

    4.2.7.2.1. ODBC

    对于使用ODBC的应用程序,应创建与Oracle同名的KingbaseES ODBC数据源,然后修改应用程序中连接数据库的用户名、密码等。此外,在Windows系统下对于OLEDB、ADO和NDP,则不需创建数据源。

    1. Windows数据源配置

    金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

    图 4.2.42 Windows平台ODBC数据源配置1

    金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

    图 4.2.43 Windows平台ODBC数据源配置2

    金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

    图 4.2.44 Windows平台ODBC数据源配置3

    金仓数据库 Oracle 至 KingbaseES 迁移最佳实践 (4. Oracle数据库移植实战)-LMLPHP

    图 4.2.45 Windows平台ODBC数据源配置4

    具体配置参数解释请参考 《KingbaseES客户端编程接口指南-ODBC》 。

    2. Linux数据源配置

    首先检查 ODBC Driver 是否已经安装。在系统中找到 odbcinst.ini 文件,和/usr/bin/odbcinst 对应的 odbcinst.ini 在 /etc 目录下,和 /usr/local/bin/odbcinst 对应的 odbcinst.ini 在 /usr/local/etc 目录下。在odbcinst.ini 文件中查找 [KingbaseES 8 ODBC Driver] 这一项。

    如果没有,则参考增加如下内容:

    [KingbaseES 8 ODBC Driver]
    
    Description = KingbaseES 8 ODBC Driver for Linux
    
    Driver = /opt/Kingbase/Odbc/lib/kdbodbcw.so
    
    增加odbc.ini文件,内容如下:
    
    [kingbase]
    
    Description = KingbaseES
    
    Driver = KingbaseES 8 ODBC Driver
    
    Servername = 127.0.0.1
    
    Port = 54321
    
    Username = SYSTEM
    
    Password = MANAGER
    
    Database = TEST
    

    具体配置参数解释请参考 《KingbaseES客户端编程接口指南-ODBC》

    4.2.7.2.2. 移植Oracle OCI应用程序

    KingbaseES V8.6 支持OCI的大部分常用接口。

    具体参见手册 《KingbaseES客户端编程接口指南-DCI》。

    4.2.7.3. 其它应用框架

    其它应用框架的使用,请参照客户端编程开发框架的使用指南。如无说明,请及时联系KingbaseES支持工程师。

    4.2.8. 测试与调试移植系统

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

    4.2.8.1. 功能测试和排错

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

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

    4.2.8.2. 性能测试和调优

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

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

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

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

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

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

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

    07-28 13:29