如何使用gt-checksum分析数据库迁移对象：从ORACLE到GreatSQL的实践

文
章
目
录

数据库迁移项目中，精准分析迁移对象是确保迁移工作顺利进行的前提，本文以从ORACLE迁移到GreatSQL为例，为大家详细介绍如何借助gt-checksum工具来实现这一目标。

一、项目背景与需求

先给大家讲一个实际的项目案例。当前有个“去O”项目，涉及3000张业务表，数据总量约3T，业务方要求在3小时内完成迁移。这可难住了不少人，毕竟在这么短的时间内迁移如此大量的数据，可不是一件容易的事。

要想在规定时间内完成迁移，我们就得搞清楚影响迁移效率的因素有哪些。比如说，业务表的索引情况，是主键索引还是普通索引，索引离散度怎么样；表中有没有lob或者text字段，有多少个；表是不是分区表，分区类型是什么，有多少个分区；每张表的数据量有多少，是百万级、千万级还是亿级别等等。这些信息对于制定合理的迁移方案至关重要，而gt-checksum工具就能帮助我们获取这些关键信息。

二、认识gt-checksum

gt-checksum是GreatSQL社区开源的一款静态数据库校验修复工具，对MySQL、Oracle等主流数据库都有很好的支持。本次我们使用的是它的商业版本。借助这个工具，我们可以深入分析迁移对象，为数据库迁移提供有力支持。

三、使用gt-checksum分析迁移对象的具体步骤

（一）配置gc-task.cnf配置文件

在使用gt-checksum分析迁移对象前，要先配置好gc-task.cnf文件，这个文件可是分析操作的关键。下面详细说说它的配置项。

DSNs（连接模块）
- srcDSN：代表源端连接串，用来连接源数据库（这里是ORACLE）。
- dstDSN：是目标端连接串，用于连接目标数据库（即GreatSQL）。需要注意，这两个连接串的格式有严格要求，要按照示例填写，双引号也不能漏。要是密码里有“&”符号，还得进行转义处理（写成“&”）。
rules（规则模块）
- object：指定迁移对象列表，这个列表文件名称可以自定义。文件里的格式是“库名分隔符表名”，文件要和gt-checksum放在同一级目录。
- limiter：表示迁移对象列表的分隔符，默认是逗号。
- igcount：决定分析时是否输出表行数，“true”表示不输出，“false”表示输出。
- active：用来生成配置文件类型，比如“struct”代表表结构，“index”代表索引，“sync”代表数据迁移等等，具体的详细说明在gc-task.cnf文件注释里可以查看。
object配置说明
object有四种配置方式，下面以迁移PCMS库下的BMSQL_WAREHOUSE、BMSQL_CONFIG、BMSQL_DISTRICT_TMP三张普通表为例进行说明。
- 一般情况（无需映射）：迁移到目标端后，库名和表名不变。在配置文件里这样写：

PCMS,BMSQL_WAREHOUSE
PCMS,BMSQL_CONFIG
PCMS,BMSQL_DISTRICT_TMP

这种情况下，源端和目标端的对应关系如下：

SOURCE                 -->  DEST
-- 示例1：PCMS,BMSQL_WAREHOUSE
PCMS.BMSQL_WAREHOUSE   --> PCMS.BMSQL_WAREHOUSE

- **库映射**：迁移后表名不变，但库名改变。配置如下：

PCMS:WLKY,BMSQL_WAREHOUSE
PCMS:WLKY,BMSQL_CONFIG
PCMS:WLKY,BMSQL_DISTRICT_TMP

源端和目标端的映射关系为：

SOURCE                 -->  DEST
#示例1：PCMS:WLKY,BMSQL_WAREHOUSE
PCMS.BMSQL_WAREHOUSE   --> WLKY.BMSQL_WAREHOUSE

- **表映射**：迁移后库名不变，表名改变。配置如下：

PCMS,BMSQL_WAREHOUSE:BMSQL_WAREHOUSE_0429
PCMS,BMSQL_CONFIG:BMSQL_CONFIG_0429
PCMS,BMSQL_DISTRICT_TMP:BMSQL_DISTRICT_TMP_0429

对应的映射关系是：

SOURCE                 -->  DEST
#示例1：PCMS,BMSQL_WAREHOUSE:BMSQL_WAREHOUSE_0429
PCMS.BMSQL_WAREHOUSE   --> PCMS.BMSQL_WAREHOUSE_0429

- **库表映射**：迁移后库名和表名都改变。配置如下：

PCMS:WLKY,BMSQL_WAREHOUSE:BMSQL_WAREHOUSE_0429
PCMS:WLKY,BMSQL_CONFIG:BMSQL_CONFIG_0429
PCMS:WLKY,BMSQL_DISTRICT_TMP:BMSQL_DISTRICT_TMP_0429

此时的映射关系为：

SOURCE                 -->  DEST
#示例1：PCMS:WLKY,BMSQL_WAREHOUSE:BMSQL_WAREHOUSE_0429
PCMS.BMSQL_WAREHOUSE   --> WLKY.BMSQL_WAREHOUSE_0429

gc-task.cnf配置示例
假设我们定义了一个名为“qianyi”的迁移对象列表文件，内容如下：

$ cat qianyi 
PCMS,BMSQL_WAREHOUSE
PCMS,BMSQL_CONFIG
PCMS,BMSQL_DISTRICT_TMP

接下来配置gc-task.cnf文件：

$ cp -r config-simple config
$ cat config/gc-task.cnf
DSNs {
    srcDSN = "oracle|user/password@ip:port/sid"
    dstDSN = "cluster|user:password@tcp(ip:port)/information_schema?charset=utf8mb4"
}

rules {
    task {     
        object = "qianyi"
        limiter = ","
        igcount = false
        active = struct
    }
}

这里设置了源端和目标端的连接串，指定了迁移对象列表文件为“qianyi”，分隔符为逗号，分析时输出表行数，生成表结构配置文件。

（二）执行分析命令

完成gc-task.cnf文件配置后，就可以执行分析操作了。在命令行输入以下命令：

$ ./gt-checksum -f config/gc-task.cnf

如果看到类似下面这样的输出，就说明分析操作成功了：

$ ./gt-checksum -f config/gc-task.cnf
-- gt-checksum init configuration files -- 
-- gt-checksum init log files -- 
-- gt-checksum init check parameter --
-- gt-checksum check parameter legality--
godror WARNING: discrepancy between DBTIMEZONE ("+00:00"=0) and SYSTIMESTAMP ("+08:00"=800) - set connection timezone, see https://github.com/godror/godror/blob/master/doc/timezone.md
----begin read table object file and init table meta data---
----begin write data to xls ---
[gt_tableObjectOptimizer_2025-02-18T15-34-03.xlsx] 元数据校对Excel表格已生成
----begin general gt-checksum config file ---
[gc-struct.cnf] 配置文件已生成
-- gt-task Table object sorting completed !!! --

（三）分析结果解析

分析操作成功完成后，在gt-checksum的同级目录下会生成一个分析结果Excel文件，文件名前缀是“gt_tableObjectOptimizer_”。这个Excel文件里有三个sheet，分别是：

indexTask：存放有索引的表清单。
missindexTask：记录无索引的表清单。
tableMiss：列出迁移对象列表中存在，但在源端Oracle环境中不存在的表清单。这里要特别注意tableMiss里的表，需要和业务侧确认是否真的要迁移。

这三个sheet的标题是一样的，下面来解析一下标题里各项内容：

schema：表示库名。
table：就是表名。
lobCN：lob字段名称，如果表中没有lob字段，这一列就为空。
lobCT：lob字段类型。
textCN：text字段名称，没有text字段时为空。
textCT：text字段类型。
indexName：索引名称。
indexType：索引类型。
indexColumn：索引字段名称。
columnType：索引字段类型。
cardinality：索引离散度。
rate evaluation：索引离散度等级。对于有索引的表，离散度大于50%为“优”，40%-50%为“良”，小于40%为“差”；无索引的表，如果有数据就是“差”，无数据则为“优”。
table Rows：表的行数统计。
partition Sum：表分区个数，0表示是普通表，非0则是分区表。
table Partition Type：表分区类型。
status：表状态，“true”表示表在源端存在，“miss”表示表在源端不存在。
taskName：表任务名称。