【金仓数据库征文】Oracle到金仓：分区表迁移及分区裁剪验证

文章目录

- 每日一句正能量
- 摘要
- [1. 背景与问题](#1. 背景与问题)
- [2. 环境与数据](#2. 环境与数据)
- - [2.1 示例环境](#2.1 示例环境)
  - [2.2 迁移前对象画像](#2.2 迁移前对象画像)
- [3. 复现过程](#3. 复现过程)
- - [3.1 Oracle 源表模型](#3.1 Oracle 源表模型)
  - [3.2 容易导致裁剪失效的 SQL](#3.2 容易导致裁剪失效的 SQL)
  - [3.3 边界异常样例](#3.3 边界异常样例)
- [4. 方案实施](#4. 方案实施)
- - [4.1 兼容评估分级](#4.1 兼容评估分级)
  - [4.2 目标端 DDL 模板](#4.2 目标端 DDL 模板)
  - [4.3 分区命名与边界规则](#4.3 分区命名与边界规则)
  - [4.4 历史数据装载](#4.4 历史数据装载)
  - [4.5 增量追平](#4.5 增量追平)
  - [4.6 分区裁剪验证](#4.6 分区裁剪验证)
  - [4.7 索引策略](#4.7 索引策略)
- [5. 结果对比](#5. 结果对比)
- - [5.1 数据一致性校验](#5.1 数据一致性校验)
  - [5.2 边界校验](#5.2 边界校验)
  - [5.3 计划校验](#5.3 计划校验)
- [6. 风险与复盘](#6. 风险与复盘)
- - [6.1 主要风险](#6.1 主要风险)
  - [6.2 灰度切换门禁](#6.2 灰度切换门禁)
  - [6.3 回退方案](#6.3 回退方案)
  - [6.4 项目复盘](#6.4 项目复盘)

每日一句正能量

人的痛苦，一半源于自己的平庸，一半源于别人的优秀。

痛苦的核心是比较。平庸让人自厌，别人的优秀让人焦虑------二者都来自用同一把尺子量自己与他人。

摘要

本文以"历史交易明细大表"迁移为背景，重点讨论 Oracle 分区表迁移到金仓数据库时，如何完成分区策略兼容评估、DDL 重建、历史数据装载、分区裁剪验证、数据一致性校验、灰度切换和可逆回退。

1. 背景与问题

某报表平台保存近七年的交易流水，核心明细表约 28 亿行，日增数据在 120 万至 300 万行之间。Oracle 源表按交易日期做月度范围分区，报表查询主要集中在最近三个月，历史数据则用于审计、对账和监管抽查。迁移前，团队最初把任务理解为"把表结构和数据搬过去"，但在预演阶段很快暴露出三个问题。

第一，Oracle 上可用的分区语法、分区边界表达、局部索引、全局索引以及分区维护方式，不能仅凭名称判断与目标库完全同构。第二，目标表即使成功建成分区表，也不代表查询一定发生分区裁剪。SQL 中函数包裹分区键、隐式类型转换、绑定变量计划选择、分区统计信息不准确，都会让执行计划扫描超出预期的分区。第三，历史大表迁移时间长，任何一次失败都不应从头重来，因此迁移必须以"分区"为最小可重跑单元，并保留明确的数据水位、校验结果和回退路径。

Oracle 官方文档把分区裁剪描述为：优化器根据 SQL 的 FROM 与 WHERE 条件，在构造分区访问列表时排除不需要的分区。金仓官方开发规范同样建议，对经常按时间范围查询、并有定期数据维护需求的超大表使用时间字段范围分区。因此，本文的目标不是机械复制 Oracle DDL，而是保持业务上的三个结果不变：

数据能够按明确边界落入正确分区；
典型报表 SQL 只访问必要分区；
迁移、切换与回退都能按分区粒度执行并审计。

2. 环境与数据

2.1 示例环境

源端采用 Oracle 19c，目标端采用 KingbaseES V8 系列测试环境。版本号在正式项目中必须精确到补丁级，因为分区 DDL、全局索引、默认分区、分区维护命令和执行计划展示方式可能随版本与兼容模式变化。

示例业务表包含以下字段：

字段	含义	迁移关注点
`trade_id`	交易流水号	是否全局唯一，主键是否必须带分区键
`tenant_id`	租户编号	是否需要与日期组成联合访问路径
`trade_date`	交易日期	分区键、边界、空值和时区口径
`account_id`	账户编号	高频过滤与关联字段
`amount`	交易金额	精度与汇总一致性
`status`	交易状态	低基数条件是否适合作为索引前导列
`created_at`	创建时间	与业务日期可能不一致
`updated_at`	更新时间	增量同步水位

2.2 迁移前对象画像

迁移前不应只导出 CREATE TABLE，还要把以下对象纳入清单：

分区方式：范围、列表、哈希、间隔或组合分区；
分区键数据类型、表达式以及是否允许空值；
每个分区的高边界、表空间、压缩属性和只读状态；
本地索引、全局索引、唯一约束及失效索引；
触发器、物化视图、同义词、存储过程和报表 SQL 的依赖；
分区新增、拆分、合并、交换、截断、删除等日常作业；
分区级统计信息的收集频率和保留策略。

Oracle 侧可先形成统一清单。下面的查询用于展示思路，字段应按实际权限和版本调整：

sql 复制代码

SELECT table_owner,
       table_name,
       partitioning_type,
       subpartitioning_type,
       partition_count,
       interval
FROM dba_part_tables
WHERE table_owner = 'RPT'
  AND table_name = 'TRADE_DETAIL';

SELECT table_owner,
       table_name,
       partition_name,
       partition_position,
       high_value,
       num_rows,
       last_analyzed
FROM dba_tab_partitions
WHERE table_owner = 'RPT'
  AND table_name = 'TRADE_DETAIL'
ORDER BY partition_position;

SELECT owner,
       index_name,
       locality,
       partitioning_type,
       status
FROM dba_part_indexes
WHERE owner = 'RPT'
  AND table_name = 'TRADE_DETAIL';

HIGH_VALUE 在部分 Oracle 字典视图中是较特殊的长文本类型，生产采集脚本应妥善转为可存档文本，不能只截屏。

3. 复现过程

3.1 Oracle 源表模型

源端按月建立范围分区，边界遵循"左闭右开"原则。以 2025 年第一季度为例：

sql 复制代码

CREATE TABLE rpt.trade_detail (
    trade_id     NUMBER(20)      NOT NULL,
    tenant_id    NUMBER(12)      NOT NULL,
    trade_date   DATE            NOT NULL,
    account_id   NUMBER(20)      NOT NULL,
    amount       NUMBER(18,2)    NOT NULL,
    status       VARCHAR2(20)    NOT NULL,
    created_at   TIMESTAMP(6)    NOT NULL,
    updated_at   TIMESTAMP(6)    NOT NULL
)
PARTITION BY RANGE (trade_date) (
    PARTITION p202501 VALUES LESS THAN (DATE '2025-02-01'),
    PARTITION p202502 VALUES LESS THAN (DATE '2025-03-01'),
    PARTITION p202503 VALUES LESS THAN (DATE '2025-04-01')
);

这里必须明确：分区名只是运维标识，真正决定数据落点的是边界。p202501 的上界是 2025-02-01，意味着它保存所有小于该日期、且不属于更早分区的数据。

3.2 容易导致裁剪失效的 SQL

业务曾经使用以下写法统计某月交易：

sql 复制代码

SELECT tenant_id, SUM(amount)
FROM rpt.trade_detail
WHERE TO_CHAR(trade_date, 'YYYYMM') = '202503'
GROUP BY tenant_id;

从业务逻辑看没有问题，但分区键被函数包裹后，优化器未必能把条件稳定还原为原始日期范围。即使某个版本或某种统计信息下出现裁剪，也不应把这种偶然行为当作迁移验收标准。更稳妥的写法是：

sql 复制代码

SELECT tenant_id, SUM(amount)
FROM rpt.trade_detail
WHERE trade_date >= DATE '2025-03-01'
  AND trade_date <  DATE '2025-04-01'
GROUP BY tenant_id;

另一个常见风险是隐式转换：

sql 复制代码

WHERE trade_date = '2025-03-15'

字符串如何解释可能受会话日期格式影响，且源库与目标库的隐式转换路径并不应假定完全一致。迁移后统一使用显式日期字面量或正确类型的绑定变量。

3.3 边界异常样例

测试数据至少应覆盖：

sql 复制代码

-- 月初与月末
DATE '2025-01-31'
DATE '2025-02-01'
DATE '2025-02-28'
DATE '2025-03-01'

-- 闰日
DATE '2024-02-29'

-- 跨年
DATE '2024-12-31'
DATE '2025-01-01'

如果业务分区键是时间戳，还要验证 23:59:59.999999 与次日零点。不要用 BETWEEN 月初 AND 月末 表示整月，因为时间字段存在秒和小数秒时，"月末"很容易漏数。统一采用半开区间：

sql 复制代码

ts_col >= TIMESTAMP '2025-03-01 00:00:00'
AND ts_col < TIMESTAMP '2025-04-01 00:00:00'

4. 方案实施

4.1 兼容评估分级

我们把源端分区表分成四类。

A 类：直接映射。 单列日期范围分区、边界清晰、索引简单，目标端可直接按相同业务边界重建。

B 类：语法改写。 业务分区策略可以保留，但 DDL、分区子表定义、索引或维护命令需要按 KingbaseES 实际版本改写。

C 类：模型调整。 Oracle 间隔分区、复杂组合分区、表达式分区键或高度依赖全局唯一索引，需要重新设计自动建分区、唯一性约束和运维流程。

D 类：暂缓迁移。 分区交换、在线重定义、特殊压缩或专用组件依赖尚未完成等价验证，先保留源端访问或通过同步表过渡。

4.2 目标端 DDL 模板

KingbaseES 官方文档给出了 PARTITION BY RANGE 以及 PARTITION OF ... FOR VALUES FROM ... TO ... 的范围分区示例。本文使用以下模板：

sql 复制代码

CREATE TABLE rpt.trade_detail (
    trade_id      bigint          NOT NULL,
    tenant_id     bigint          NOT NULL,
    trade_date    date            NOT NULL,
    account_id    bigint          NOT NULL,
    amount        numeric(18,2)   NOT NULL,
    status        varchar(20)     NOT NULL,
    created_at    timestamp(6)    NOT NULL,
    updated_at    timestamp(6)    NOT NULL,
    CONSTRAINT pk_trade_detail PRIMARY KEY (trade_id, trade_date)
) PARTITION BY RANGE (trade_date);

CREATE TABLE rpt.trade_detail_p202501
PARTITION OF rpt.trade_detail
FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

CREATE TABLE rpt.trade_detail_p202502
PARTITION OF rpt.trade_detail
FOR VALUES FROM ('2025-02-01') TO ('2025-03-01');

CREATE TABLE rpt.trade_detail_p202503
PARTITION OF rpt.trade_detail
FOR VALUES FROM ('2025-03-01') TO ('2025-04-01');

主键是否必须包含分区键、能否使用全局唯一索引、全局索引在分区维护时如何处理，应以目标版本实测结果为准。历史表中如果 trade_id 已全局唯一，但目标端约束机制要求把 trade_date 纳入主键，可以保留业务唯一性校验，或者在确认版本能力后使用合适的全局索引。切忌为了"建表成功"而悄悄改变业务唯一性定义。

4.3 分区命名与边界规则

统一规则比语法本身更重要：

月分区名称使用 pYYYYMM；
所有日期边界采用半开区间；
未来至少提前创建三个月分区；
分区创建作业必须幂等；
越界写入必须报警，不能长期依赖兜底分区吞掉错误；
删除历史分区前必须完成归档、校验与审批；
运维台账记录分区名、起止边界、行数、容量、校验摘要和状态。

4.4 历史数据装载

不建议对 28 亿行大表执行一次性全表迁移。采用"按月分区、分片并行、失败可重跑"的方式：

冻结待迁移历史月份，确认源分区不再发生更新；
记录源分区行数、金额汇总、最小最大主键、最小最大时间；
按分区导出或抽取；
目标端装载对应分区；
建立或恢复必要索引；
收集统计信息；
执行数据校验与裁剪验证；
将通过状态写入迁移台账。

迁移台账可设计为：

sql 复制代码

CREATE TABLE mig.partition_task_log (
    task_id             bigint primary key,
    table_name          varchar(128) not null,
    partition_name      varchar(128) not null,
    range_start         date not null,
    range_end           date not null,
    source_row_count    bigint,
    target_row_count    bigint,
    source_amount_sum   numeric(30,2),
    target_amount_sum   numeric(30,2),
    source_digest       varchar(128),
    target_digest       varchar(128),
    extract_watermark   timestamp(6),
    status              varchar(20) not null,
    error_message       varchar(2000),
    started_at          timestamp(6),
    finished_at         timestamp(6)
);

状态建议至少包括 PENDING、EXTRACTED、LOADED、VALIDATED、FAILED。重跑前先根据 task_id + partition_name 判断是否已完成，避免重复装载。

4.5 增量追平

历史分区迁完后，当前月仍持续写入。增量同步使用 updated_at + trade_id 作为复合水位，避免同一微秒内多行更新造成漏数。伪代码如下：

sql 复制代码

WHERE updated_at > :last_time
   OR (updated_at = :last_time AND trade_id > :last_id)
ORDER BY updated_at, trade_id

目标端采用幂等写入策略，并记录每批次起止水位、读取行数、写入行数、冲突行数和失败明细。正式切换前进入短暂只读窗口，完成最后一批增量和全量摘要校验。

4.6 分区裁剪验证

目标表建好后，必须用 EXPLAIN 和 EXPLAIN ANALYZE 对典型 SQL 逐条验证。不能只看总耗时，还要看：

访问了哪些分区；
是否出现被裁剪的子计划；
预估行数与实际行数偏差；
顺序扫描、索引扫描或位图扫描的选择；
共享缓冲区命中与磁盘读取；
过滤掉的行数；
排序、哈希聚合和临时文件使用；
绑定变量实参变化后计划是否稳定。

示例：

sql 复制代码

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT tenant_id, SUM(amount)
FROM rpt.trade_detail
WHERE trade_date >= DATE '2025-03-01'
  AND trade_date <  DATE '2025-04-01'
GROUP BY tenant_id;

验收标准不是"出现分区表"几个字，而是计划中仅访问三月目标分区，且实际读取块数与数据量符合预期。

4.7 索引策略

分区裁剪解决的是"少访问分区"，索引解决的是"在目标分区内少访问数据"。二者不能互相替代。

对于 tenant_id + trade_date 的报表条件，可建立联合索引：

sql 复制代码

CREATE INDEX idx_trade_detail_tenant_date
ON rpt.trade_detail (tenant_id, trade_date);

索引设计要根据查询选择性、数据倾斜和写入压力验证。低基数 status 通常不宜盲目作为单列索引，但若绝大多数报表固定查询极少数状态，可评估组合索引。每增加一个索引都会提高装载和增量写入成本，历史迁移期间可先装载数据，再按批次建立索引。

5. 结果对比

以下数据是示例化测试结果，用于说明验收方法，正式投稿必须替换为真实项目数据。

指标	迁移前问题写法	迁移后标准写法
查询条件	`to_char(trade_date,'YYYYMM')='202503'`	日期半开区间
实际访问分区	36 个	1 个
扫描行数	4.2 亿	1180 万
执行时间	96.4 秒	4.7 秒
共享块读取	约 310 万	约 8.6 万
临时文件	6.8 GB	0
结果金额	一致	一致

5.1 数据一致性校验

校验分为四层。

第一层：结构校验。 列名、类型、非空、默认值、主键、索引和分区边界逐项核对。

第二层：分区汇总校验。

sql 复制代码

SELECT date_trunc('month', trade_date) AS month_start,
       COUNT(*) AS row_count,
       SUM(amount) AS amount_sum,
       MIN(trade_id) AS min_id,
       MAX(trade_id) AS max_id
FROM rpt.trade_detail
GROUP BY date_trunc('month', trade_date)
ORDER BY month_start;

源端执行等价 SQL，并按月份比较。

第三层：业务维度校验。 按租户、状态、账户类型、业务日等维度比对行数与金额，防止总量相同但分布错误。

第四层：逐行摘要或抽样明细。 对关键字段按稳定顺序计算摘要；摘要算法、空值表示、日期格式和数值格式必须两端统一。对于监管或财务数据，摘要只用于快速发现差异，最终仍需对差异主键逐行核对。

5.2 边界校验

sql 复制代码

SELECT *
FROM rpt.trade_detail
WHERE trade_date IN (
    DATE '2025-01-31',
    DATE '2025-02-01',
    DATE '2025-02-28',
    DATE '2025-03-01'
)
ORDER BY trade_date, trade_id;

重点确认每条数据实际进入的物理分区。目标端可通过系统列或分区元数据观察物理落点，具体方法以版本为准。

5.3 计划校验

同一业务 SQL 至少验证五组参数：

单日；
单月；
跨两个月；
历史一年；
不含分区键。

这样才能区分"某个参数恰好很快"和"访问模型整体合理"。绑定变量场景还要分别测试近期热分区和历史冷分区，观察计划缓存是否导致明显偏差。

6. 风险与复盘

6.1 主要风险

风险一：边界复制错误。 把 Oracle 的"上界小于"机械翻译成闭区间，容易造成月初重复或月末漏数。统一采用左闭右开。

风险二：分区键口径错误。 有些系统同时存在 trade_date、created_at 和 settle_date。源表按交易日分区，目标端却按创建时间分区，会让报表裁剪与归档策略失效。

风险三：唯一约束语义变化。 为适配分区表而把日期加入主键，可能允许同一 trade_id 在不同日期重复。必须保留业务唯一性验证。

风险四：统计信息缺失。 数据装载后未及时收集统计信息，优化器可能错误估算，导致裁剪正常但分区内访问路径很差。

风险五：函数与隐式转换。 迁移只验证 DDL，不整改 SQL，最终仍可能扫描大量分区。

风险六：未来分区未创建。 新月份到来时写入失败，或数据进入兜底分区后长期无人治理。应提前创建并监控。

风险七：删除历史分区不可逆。 分区删除前必须完成归档校验、审批和恢复演练。

6.2 灰度切换门禁

满足以下条件后才能放量：

所有历史分区状态为 VALIDATED；
当前增量延迟低于约定阈值；
行数、金额、业务维度与抽样明细一致；
典型 SQL 分区裁剪符合预期；
P95、P99 响应时间达到门槛；
新分区创建、统计信息收集和告警作业已验证；
源端回退窗口、差异导出和回放脚本可用。

6.3 回退方案

切换初期 Oracle 源表保持只读或有限写入能力，应用通过配置开关决定查询路由。若出现以下任一情况，立即停止目标端放量：

关键业务汇总不一致；
典型 SQL 扫描分区数异常；
查询延迟持续超过阈值；
新数据落入错误分区；
增量同步水位断裂；
唯一性或外键关系异常。

回退步骤：

冻结目标端写入或同步入口；
记录最后成功水位；
导出灰度期间目标端新增或变更的主键；
与源端差异比对；
以幂等方式回放源端；
应用查询路由切回 Oracle；
保留目标端现场和执行计划，不立即清理；
修复后从已验证分区和水位继续，不重复全量迁移。

6.4 项目复盘

这次迁移最重要的经验是：分区表迁移的验收对象不是 DDL，而是"边界、数据、计划和运维闭环"。

只验证表能创建，可能遗漏业务唯一性；只验证数据量一致，可能遗漏边界错位；只验证一次查询很快，可能遗漏绑定变量或函数条件下的裁剪失效；只验证切换成功，可能遗漏下个月分区未创建。因此，最终交付物至少应包含：

源端对象与依赖清单；
分区映射表；
目标端 DDL 模板；
历史迁移任务台账；
数据校验 SQL；
执行计划对照样例；
新分区自动化与告警；
灰度切换和回退手册。

转载自：https://blog.csdn.net/u014727709/article/details/163191315

欢迎 👍点赞✍评论⭐收藏，欢迎指正