信创数据库迁移: Oracle --> KingBase

迁移方案的选择最重要的是:  在源库可承受范围内，业务的割接时间。 任何方案都需要为尽可能小影响现有业务的前提下做出最优选择。

1.  信创数据库的选择:

    各大信创数据库厂商均对信创数据库去O做了很多的适配，如：达梦、金仓、TDSQL、OB 等。 本次笔主公司迁移数据库选择人大金仓更多的考虑在于摸着石头过河，为后续核心数据库的信创积累数据和经验。

2.  迁移前准备

    本次迁移的业务系统和数据库较复杂，需要根据业务将原有在一个Oracle 中的数据根据业务拆分成两个库，放在金仓中。

    1. 梳理业务

        a. 首先由开发给出各业务对应的表、视图、函数、存储过程、序列、DBLINK 等Oracle 对象；

        b. 根据开发给出的Oracle 对象，去生产上统计表的大小(包括数据条数+ 数据存储的容量)、索引(包括索引的建、索引的大小)、主键、外键、时间条件、触发器，表定义、同义词等 内容；

        c. 根据统计的结果，根据日常业务运行的效率和历史的痛点，和开发讨论， 确定需要在迁移割接前归档的历史数据，改造的生产表(主要是普通表--> 分区表，分区表--> 普通表)。

    2. 开发改造(包含数据对象的改造)

        a. 其它Oracle --> 本次迁移业务系统的Oracle 数据库的DBLINK 改造，     原因为：Oracle 不支持到KingBase 的dblink；

        b. 对于查询DBLINK 缓慢的业务: 代码改造，直接程序直连， 原因为: 数据库性能；

        c. 改造Oracle 中的同义词 原因为： 测试中发现金仓某些DDL中无法使用同义词，特别是那种带有DBLINK的同义词；

        d. 视图改造， 原因为： 某些Oracle中视图中有DBLINK，金仓不支持；

        e. 其它根据业务运行效率和历史痛点的业务改造。

3. 迁移过程中

不管选择何种方案，第一步都为将迁移工具和KingBase数据库调整为适合本地服务器运行的状态：

主要调整为：1. KingBase 数据库的配置参数(数据库内存374GB) 　　work_mem =64MB
    maintenance_work_mem=64GB
    shared_buffers=100GB    max_parallel_maintenance_workers = 8    # taken from max_parallel_workers
    max_parallel_workers_per_gather = 8     # taken from max_parallel_workers
    max_parallel_workers = 20    max_connections=200    effective_cache_size=192GB这里的参数配置并没有遵循PG系的最佳实践的原因为：  经过测试发现KingBase在大表中建立主键、索引非常慢，导致大部分的优化放在了KingBase的这部分上，从而不断加并发，加大维护内存，扩大单个进程的work_mem,降低连接数。同时没有关闭写WAL日志和主备流复制，是因为KingBase的数据写入迁移速度还是基本跑满了网络带宽和跑出了磁盘性能。2. KDTS迁移工具的内置参数    bin/start.sh:   　　　 JAVA_MEMORY=32G    bin/thread-config.json　　　 {"poolName": "writeLargeObject", "corePoolSize": 64, "maxPoolSize": 64, "workQueueCapacity": 64}
    conf/datasource.oracle.yml      #目标端数据对比缓冲区大小（行数）
  　　dataCompareBufferSize: 1000000
  　　#数据对比顺序比对并行度
  　　dataCompareSequentialParallelism: 5      #批量提交记录数（行数）
  　　writeBatchSize: 10000
  　  #批量提交记录数（行数）--大大对象数据
  　  writeBatchSizeBigLob: 100
  　  #批量提交数据大小（单位为M）
  　　writeBatchByteSize: 256
  　　#大对象数据读入内存阈值（单位兆，默认128M）
      lobInMemoryThresholdSize: 500
3. 服务器内置参数： 略  

整库全量迁移：

    优势:  整库迁移操作简单，迁移工具可以自梳理迁移顺序和迁移关系；

    劣势:  不灵活，同时割接时间较长，不可控。

    数据库参考:

           Oracle 数据库200GB左右 --> KDTS 网络读取大概700GB -->  KingBase 金仓落盘 330多G， 在CPU足够、源库、目标库、网络带宽均性能良好的时候，整库迁移大概3h， 其中数据迁移大概30min，其余150分钟均为建立索引、建立约束等其它操作；

先迁部分表的历史数据，再迁部分表的增量数据和其它全部数据对象：

   优势:  灵活，割接时间可控；

   劣势:  迁移分步骤，需要梳理迁移顺序和迁移关系，操作较复杂；

   数据库参考:  因为整体时间和源库历史数据的分割Key、其它优化操作有关系，没有参考代表性, 但也给出数据:     Oracle 数据库200GB左右最后迁移完成大概用了8h，因为我们使用table-filter-data.json 对迁移数据做了多次的分割。

人大金仓有类似DSG、OGG这种实时同步的工具： 收费这TM的是真的离谱，如果金仓老板看到建议把这个工具先免费让客户迁移数据库的时候用一用(搞个迁移授权)，搞个方案和处理问题花了大概半个月，人都懵了。

4. 迁移后验证

    数据一致性验证:   1. select count(*)     2. 抽几条数据核对

    应用验证: 1. 信创应用放在KingBase里跑   2. 开发连KingBase 进行测试验证 

    DBA:  打"补丁",做未尽事宜。 

   问题： A. Oracle 分区表迁移到 KingBase 后全局主键索引在开启enable_globalindexscan = on后，执行计划依然无法走主键索引，导致相关功能缓慢引发数据库锁从而导致系统崩溃:    

                   解决办法:    手动对整个分区表做一次vacuum analyze full 操作，这个操作耗时非常长。

              B. 老版本支持的功能到新版本又不支持了，当然有替代方案，不过折腾，上线前要多次预演。

5. 迁移过程中的一些问题

1. KingBase KDTS 的工具版本管理比较混乱，笔者先后共拿到了3个版本的KDTS迁移工具，都是迁移到快成功的时候突发BUG换版本，当时也是气炸，好在好在好在最后成功了；

2..KingBase v8r6 的scarm 认证方式不支持JDK 1.6， 最后更改数据库的认证方式为md5；

3. 整个迁移测试都要找KingBase的销售、售前技术、售后技术参与，然后尽可能选择售前上手过大项目的迁移方案，笔者这次用的kdts的命令行工具，有些参数还真的不是配置文件的注释一样的;

总体整个迁移预演没有出现啥大的问题，整体Oracle的兼容性还可以，就差老板一声令下开干了。    说实话KingBase 的售前态度是真的可以，不推来推去，能及时处理对症下药。  见过某些厂家屁大的问题拉一堆人，最后解决问题的还是1~2个人，有时候拉人就花了很多时间，还短时间内解决不了是真的惨。