OceanBase金融核心迁移实战：三层解耦与删除标记优化

简介：本资源为中国太平洋保险数智研究院首席数据库专家林春发布的《2024年金融数据库转型方法论报告》，面向金融行业架构师、DBA、数据库国产化推进负责人及金融科技中高级技术人员，系统解答分布式数据库选型适配、Oracle存量系统平滑迁移、核心系统信创替代等关键难题。报告PDF文件1个，大小1.11MB，内容涵盖分布式数据库技术路线对比（Proxy型 vs 原生型）、迁移痛点分析（评估工具缺失、存储过程改造量大、稳定性不足）、太保OceanBase落地实践（45TB大库改造、同城双活容灾、SQL标准化规范）及降本增效方法论（工具链建设、知识库沉淀、OB认证人才培养）。目前已有170人学习下载，读者可直接获取头部金融机构在架构转型、成本压缩、能力沉淀四维度的完整方法论框架与可复用的评估模型、优化手册、运维规范等实战资产。

1. 这不是一份PPT式方法论：它是一份被产险理赔系统CPU压到95%后倒逼出来的国产数据库落地手记

你点开这份《2024年金融数据库转型方法论报告》，别急着划到“架构转型”“降本增效”这类词——先看第7页：太保产险车险理赔核心系统，每日2万案件、2万人在线作业，主节点QPS峰值超11万，优化前数据库服务器CPU平均使用率长期卡在90%以上，峰值冲破95%。这不是压力测试的模拟数据，是真实生产环境里告警灯常亮、DBA凌晨三点还在查执行计划的现场。这份报告的底色，是OceanBase集群在真实重负载场景下被反复“打脸”又重建的过程：SQL跑得慢，不是因为没写索引，而是小表TEST_TASK_PARA删了几十次记录，物理空间不释放，全表扫描硬扛5万+带删除标记的行；批处理卡顿3392秒，根因不是硬件不够，而是临时表T_CPI_TMP_SUBORDER每次只删1条，却要扫6万行——这些细节，教科书不写，开源文档不提，但一线工程师每天都在填。它不讲“分布式是趋势”，而讲“怎么让一个Oracle老系统在不重写业务逻辑的前提下，把存储过程改造量压到5%以内”；不空谈“生态建设”，而列出了1135人通过OBCE认证、知识库沉淀超1000条问题的实操路径。适合谁？适合正坐在会议室里听厂商吹“100%兼容Oracle”的架构师，更适合那个刚收到迁移排期表、手边还开着v$session和obproxy.log的DBA。这不是理论推演，是血泪经验凝结成的避坑地图。

2. 从Oracle到OceanBase：不是版本替换，而是三层解耦式迁移策略

金融核心系统迁移最怕什么？不是技术难，是“不敢动”。Oracle里一个存储过程嵌套五层游标、调用三个自定义函数、再关联四张分区表——直接扔进分布式库，大概率报错、性能雪崩、回滚无门。中国太保的解法很务实：不追求1:1平移，而做三层解耦——对象层、逻辑层、执行层分别治理。这三层不是并列关系，而是有严格先后顺序的流水线：先稳住对象结构，再重构逻辑表达，最后优化执行路径。每层都配了对应工具和检查清单，不是靠人肉眼盯，而是用“指南针”预扫描工具自动识别风险点。下面拆解这三层如何落地。

2.1 对象层：用“三类表法”替代粗暴全量迁移

传统迁移常把所有表一股脑导过去，结果历史归档表占满磁盘、配置表锁死连接、实时交易表因分布键设计不当引发热点。太保的做法是先对存量表做手术式分类：

表类型	占比	典型特征	迁移策略	工具支持
基础配置类表	~15%	数据量小（<10MB）、读多写少、强一致性要求高	直接迁移，启用全局索引保证跨分片JOIN性能；禁用分区，避免小表分裂开销	obdumper+obloader
历史归档类表	~35%	数据量大（TB级）、查询频次低、允许一定延迟	拆离至冷数据平台（如HDFS），仅在OceanBase保留近3个月热数据；用ALTER TABLE ... ARCHIVE标记	oblogproxy+ 自研归档服务
实时交易类表	~50%	高频DML、强事务、QPS>1000	重点攻坚：按业务域分库分表，分布键选tenant_id+order_no而非单一order_no；禁用AUTO_INCREMENT，改用SEQUENCE+SHARDING_KEY组合	oceanbase-migration

提示：分库分表不是越细越好。某次压测发现，将一张日均500万订单的表按order_no哈希分1024个库，导致跨库JOIN耗时飙升400%。最终收敛为按tenant_id分8库+order_no本地分区，既保证租户数据隔离，又避免跨库操作。

执行命令示例（以实时交易表POLICY_INFO为例）：

-- 创建带分库分表策略的表（OceanBase 4.2+语法） CREATE TABLE POLICY_INFO ( policy_id VARCHAR(32) NOT NULL, tenant_id VARCHAR(16) NOT NULL, issue_date DATE, premium DECIMAL(18,2), PRIMARY KEY (policy_id, tenant_id) ) PARTITION BY HASH(tenant_id) PARTITIONS 8 SUBPARTITION BY RANGE COLUMNS(issue_date) ( SUBPARTITION p2023 VALUES LESS THAN ('2024-01-01'), SUBPARTITION p2024 VALUES LESS THAN ('2025-01-01') );

参数说明：

• PARTITION BY HASH(tenant_id)：确保同一租户数据落在同一物理节点，减少跨节点RPC；
• SUBPARTITION BY RANGE COLUMNS(issue_date)：按时间切分，便于冷热分离和快速删除过期分区；
• PRIMARY KEY (policy_id, tenant_id)：复合主键强制分布键参与索引，避免全表扫描。

2.2 逻辑层：PL/SQL到SQL的“外科手术式”改造

Oracle重度依赖PL/SQL，而OceanBase虽兼容大部分语法，但FORALL批量绑定、BULK COLLECT集合操作、复杂游标循环等特性在分布式环境下极易引发性能拐点。太保的改造原则是：能用标准SQL解决的，绝不用存储过程；必须用过程的，拆成原子化小过程。例如原Oracle中一个处理理赔单据的存储过程，含12层嵌套循环和3个动态SQL拼接，迁移后被拆解为：

1. 前置清洗：用INSERT ... SELECT一次性聚合原始数据，替代循环插入；
2. 规则引擎：将业务规则抽离为JSON配置表，应用层读取后生成WHERE条件；
3. 异步补偿：高频更新操作改为写入消息队列，由独立消费者进程执行最终落库。

关键改造代码对比（原Oracle PL/SQL vs OceanBase优化后）：

-- 原Oracle：游标循环更新（伪代码，实际耗时2.3秒/单条） DECLARE CURSOR c_policy IS SELECT policy_id, status FROM POLICY_INFO WHERE status = 'PENDING'; BEGIN FOR r IN c_policy LOOP UPDATE POLICY_INFO SET status = 'PROCESSED' WHERE policy_id = r.policy_id; END LOOP; END; -- OceanBase优化：单条SQL原子更新（耗时0.08秒） UPDATE POLICY_INFO SET status = 'PROCESSED' WHERE status = 'PENDING' AND policy_id IN ( SELECT policy_id FROM ( SELECT policy_id FROM POLICY_INFO WHERE status = 'PENDING' ORDER BY create_time LIMIT 1000 ) t );

逻辑说明：

• 避免游标逐行处理，改用IN (SELECT ... LIMIT 1000)分批更新，防止长事务锁表；
• ORDER BY create_time保证按时间序处理，符合业务时效性要求；
• LIMIT 1000控制单次影响行数，降低锁竞争和内存消耗。

2.3 执行层：从“看执行计划”到“看执行轨迹”的深度诊断

在集中式数据库，EXPLAIN输出的执行计划基本等于真实执行路径。但在OceanBase，由于多层代理（OBProxy）、分布式调度（RootService）、并行执行（PX）的存在，执行计划只是“理想蓝图”，真实执行轨迹可能绕路千里。太保自研的ob-trace工具能捕获SQL从应用发出到最终返回的全链路耗时分解，定位到毫秒级瓶颈。例如某报表SQL在Oracle耗时1.2秒，在OceanBase却达8.7秒，EXPLAIN显示走索引扫描，但ob-trace暴露真相：

阶段	耗时	说明
应用到OBProxy网络	12ms	正常
OBProxy路由解析	8ms	正常
RootService分发请求	210ms	异常！因分布键未命中，需广播查询
存储层扫描	3.2s	扫描32个分区，但仅1个分区有数据
网络聚合结果	2.1s	异常！32个节点结果汇总耗时过高

解决方案：

• 在WHERE条件中强制加入分布键过滤（如AND tenant_id = 'INSURANCE_001'）；
• 将聚合操作下推到存储节点，用/*+ USE_PX */提示符启用并行执行；
• 对结果集大的查询，增加LIMIT 5000防止单次返回超限。

3. 分布式数据库的“玄学”性能：为什么小表扫描会慢500倍？

当DBA告诉你“这张表只有83行，但SELECT * FROM T要2.3秒”，你第一反应可能是“是不是锁住了？”——但在OceanBase的真实生产环境里，更大概率是掉进了删除标记（Delete Mark）的深坑。这并非Bug，而是LSM-Tree存储引擎的固有特性：删除操作不立即物理擦除，而是打标记，待后台合并（Major Freeze）时才清理。问题在于，高频删除的小表，其“逻辑行数”和“物理扫描行数”可能相差两个数量级。第8页的TEST_TASK_PARA表就是典型：逻辑行32，物理扫描行52480，全表扫描必然慢如蜗牛。这不是配置问题，是存储模型与业务模式错配的必然结果。下面直击这个“玄学”现象的根因与解法。

3.1 删除标记机制：LSM-Tree的双刃剑

OceanBase采用LSM-Tree（Log-Structured Merge-Tree）作为底层存储结构，其优势是高吞吐写入，代价是读取时需合并多个层级（MemTable、SSTable）的数据。当执行DELETE FROM T WHERE id=123时：

1. 不删除物理数据：仅在当前MemTable中插入一条DELETE标记记录；
2. 标记生效范围：该标记对后续读取可见，但旧SSTable中的原始数据仍存在；
3. 合并时机：直到后台Major Freeze任务运行，才会将标记与原始数据合并，真正丢弃旧数据。

注意：Major Freeze默认每日凌晨触发，但若表持续高频删除，未合并的标记会堆积，导致每次查询都要遍历所有标记+原始数据。

验证删除标记堆积的SQL：

-- 查看表的实际物理扫描行数（含删除标记） SELECT /*+ PARALLEL(4) */ COUNT(*) FROM TEST_TASK_PARA; -- 查看逻辑行数（不含删除标记） SELECT COUNT(*) FROM TEST_TASK_PARA WHERE __pk_increment_id > 0; -- 查看删除标记比例（关键指标！） SELECT (COUNT(*) - COUNT(CASE WHEN __pk_increment_id > 0 THEN 1 END)) * 100.0 / COUNT(*) AS delete_ratio_pct FROM TEST_TASK_PARA;

参数说明：

• __pk_increment_id是OceanBase隐藏的自增主键字段，未删除行该值>0；
• delete_ratio_pct > 30%即为高风险，需介入优化；
• PARALLEL(4)强制并行扫描，加速统计（生产环境慎用）。

3.2 Queuing表：专治高频删除的“手术刀”

针对小表高频删除场景，OceanBase提供Queuing Table模式（需4.1+版本），其核心思想是：将删除操作转化为“转储（Freeze）触发器”，让删除标记在产生时就进入可清理状态，而非等待每日合并。但直接开启QUEUING并不万能，第11页案例揭示了它的脆弱性：TEST_TASKCOUNT_DETAIL表设为Queuing后，高峰时段1小时转储28次，因阈值_ob_queuing_fast_freeze_min_count=30000无法兼顾不同表的删除频率。

正确用法是分级阈值控制：

-- 步骤1：创建Queuing表（关键！指定转储阈值） CREATE TABLE TEST_TASK_PARA ( id BIGINT PRIMARY KEY, status VARCHAR(10), create_time DATETIME ) TABLEGROUP tg_queue PARTITION BY HASH(id) PARTITIONS 4 -- 启用Queuing，设置转储阈值为500（适配小表高频删除） WITH (queuing = 'true', queuing_freeze_threshold = '500'); -- 步骤2：为删除操作添加业务状态字段（规避全表扫描） ALTER TABLE TEST_TASK_PARA ADD COLUMN deleted_status TINYINT DEFAULT 0; CREATE INDEX idx_deleted_status ON TEST_TASK_PARA(deleted_status) WHERE deleted_status = 0; -- 函数索引，仅索引有效数据 -- 步骤3：应用层改造SQL（关键！） -- 原SQL（慢）：DELETE FROM TEST_TASK_PARA WHERE id = 123; -- 新SQL（快）：UPDATE TEST_TASK_PARA SET deleted_status = 1 WHERE id = 123; -- 查询时过滤（利用函数索引） SELECT * FROM TEST_TASK_PARA WHERE deleted_status = 0 AND status = 'ACTIVE';

逻辑说明：

• queuing_freeze_threshold = '500'：当删除标记达500条时立即触发转储，避免堆积；
• WHERE deleted_status = 0函数索引：使SELECT仅扫描有效行，跳过所有已标记删除的行；
• UPDATE替代DELETE：业务上等价，但物理上不产生新删除标记，彻底规避问题。

3.3 避坑：删除标记相关的5个血泪教训

现象 → 原因 → 解决，全是线上翻车实录：

1. 现象：SELECT COUNT(*) FROM T执行超时，SHOW PROCESSLIST显示状态为Sending data。
   原因：表T被设为Queuing表，但queuing_freeze_threshold设为0（默认值），导致删除标记永不转储，扫描行数指数级增长。
   解决：立即修改阈值ALTER TABLE T SET TBL_PROPERTIES='queuing_freeze_threshold=1000'，并手动触发ALTER SYSTEM MAJOR FREEZE。

2. 现象：应用执行DELETE FROM T WHERE id IN (1,2,3)后，SELECT * FROM T仍返回这3条。
   原因：OceanBase的DELETE在事务提交前对其他会话不可见，而应用未显式COMMIT。
   解决：检查应用事务管理，确保DELETE后调用COMMIT；或改用UPDATE ... SET deleted_status=1（无需事务强一致）。

3. 现象：EXPLAIN显示走索引，但实际执行慢，ob-trace显示Storage Read耗时占比90%。
   原因：索引字段未包含分布键，导致查询需广播到所有分区，每个分区都扫描删除标记。
   解决：重建索引，将分布键（如tenant_id）作为索引首列，例如CREATE INDEX idx_tenant_status ON T(tenant_id, status)。

4. 现象：V$OB_SQL_AUDIT中某SQL的ELAPSED_TIME远大于EXECUTION_TIME。
   原因：ELAPSED_TIME包含网络传输和结果集组装时间，EXECUTION_TIME仅为存储层执行时间；当删除标记多时，存储层需合并大量碎片，EXECUTION_TIME飙升。
   解决：优先优化存储层，而非网络层；用ob-trace确认瓶颈在Storage Read而非Network Send。

5. 现象：ALTER TABLE T SET TBL_PROPERTIES='queuing=true'报错Unsupported operation。
   原因：表T已存在大量数据且未分区，OceanBase要求Queuing表必须为分区表。
   解决：先CREATE TABLE T_NEW LIKE T并指定分区，再INSERT INTO T_NEW SELECT * FROM T，最后RENAME切换。

4. 重负载系统的CPU瓶颈：不是换CPU，是重构SQL执行范式

当核心资金交易系统在压测中CPU飙到95%，运维第一反应是加CPU核数——但太保的实践证明，在国产服务器CPU主频普遍低于Intel至强的现实下，单纯堆硬件是饮鸩止渴。第16页的案例触目惊心：批处理存储过程耗时3392秒，其中88%耗时来自两条SQL，而这两条SQL单次执行仅20~50毫秒。根源在于高频低效扫描：INSERT INTO ... SELECT每次处理1条，却要扫描临时表26342行；DELETE每次删1条，却要扫62058行。这不是SQL写得差，而是执行范式与分布式存储模型不匹配。真正的解法，是把“面向过程”的批处理，重构为“面向数据流”的管道式处理。

4.1 临时表陷阱：全局临时表为何在分布式库中成为性能黑洞？

Oracle的全局临时表（GTT）是会话级私有、事务级生命周期的利器，但在OceanBase中，GTT的实现机制完全不同：

• Oracle GTT：数据存于TEMP表空间，会话结束自动清空，物理隔离；
• OceanBase GTT：本质是普通表+会话ID前缀，数据存于主存储，删除需全表扫描。

第17页的T_CPI_TMP_SUBORDER正是此例：作为GTT，它被设计为“每批次创建-填充-使用-清空”，但OceanBase中DROP TABLE成本极高，故改用DELETE，结果每次DELETE都触发全表扫描。更致命的是，GTT的分布键无法定制，导致数据随机分布在各节点，跨节点JOIN和聚合成为常态。

重构路径：GTT → Queuing表 + 批次ID索引

-- 步骤1：废弃GTT，创建Queuing表（带批次ID） CREATE TABLE T_CPI_TMP_SUBORDER ( batch_id VARCHAR(32) NOT NULL, -- 新增批次ID，作为分布键 seq BIGINT NOT NULL, order_no VARCHAR(32), amount DECIMAL(18,2), PRIMARY KEY (batch_id, seq) ) PARTITION BY HASH(batch_id) PARTITIONS 8 WITH (queuing = 'true', queuing_freeze_threshold = '1000'); -- 步骤2：为批次ID创建高效索引（避免全表扫描） CREATE INDEX idx_batch_id ON T_CPI_TMP_SUBORDER(batch_id); -- 步骤3：应用层改造（关键！） -- 原逻辑（慢）： -- INSERT INTO T_CPI_TMP_SUBORDER SELECT ... FROM SOURCE WHERE batch_id = '20240501'; -- DELETE FROM T_CPI_TMP_SUBORDER WHERE batch_id = '20240501'; -- 全表扫描！ -- 新逻辑（快）： -- INSERT INTO T_CPI_TMP_SUBORDER (batch_id, seq, ...) -- SELECT '20240501', seq, ... FROM SOURCE WHERE condition; -- DELETE FROM T_CPI_TMP_SUBORDER WHERE batch_id = '20240501'; -- 利用索引，毫秒级

参数说明：

• PARTITION BY HASH(batch_id)：确保同一批次数据落在同一节点，消除跨节点操作；
• idx_batch_id索引：使DELETE WHERE batch_id = ?走索引查找，而非全表扫描；
• queuing_freeze_threshold = '1000'：批次内删除达1000条即转储，防堆积。

4.2 高频SQL优化：从“单条精耕”到“批量管道”

第6页提出的“标量子查询改外连接”“全局索引改本地索引”等，本质都是减少分布式协调开销。以车险理赔系统的dispatchta0_表查询为例（第8页SQL）：

-- 原SQL（慢）：mod(top_actual_id, 13)=4 导致无法用索引，全表扫描 SELECT * FROM TEST_TASK_PARA WHERE status='0' AND mod(top_actual_id, 13)=4 ORDER BY id ASC LIMIT 100; -- 优化1：用范围查询替代MOD（牺牲部分均匀性，换性能） SELECT * FROM TEST_TASK_PARA WHERE status='0' AND top_actual_id BETWEEN 4 AND 999999999 AND top_actual_id % 13 = 4 -- 仍需计算，但配合索引可剪枝 ORDER BY id ASC LIMIT 100; -- 优化2：创建函数索引（OceanBase 4.2+支持） CREATE INDEX idx_top_mod ON TEST_TASK_PARA((top_actual_id % 13)) WHERE status = '0'; -- 优化3：终极方案——预计算分桶（业务侧改造） ALTER TABLE TEST_TASK_PARA ADD COLUMN mod_bucket TINYINT; UPDATE TEST_TASK_PARA SET mod_bucket = top_actual_id % 13; CREATE INDEX idx_mod_bucket ON TEST_TASK_PARA(mod_bucket, status) WHERE status = '0'; -- 查询变为：WHERE status='0' AND mod_bucket=4，完美走索引

逻辑说明：

• mod_bucket字段将计算下推到写入时，读取时零计算开销；
• 复合索引mod_bucket, status覆盖查询条件，避免回表；
• WHERE status = '0'在索引创建时指定，使索引仅存储有效数据，减小索引体积。

4.3 CPU负载归因：用ob_perf定位真实瓶颈

不要相信top命令看到的CPU占用率——那只是OS视角。OceanBase提供ob_perf工具，可深入到SQL执行引擎内部，查看CPU耗在哪个环节：

# 连接OBProxy，采集10秒性能数据 ob_perf -h 127.0.0.1 -P 2883 -u root@sys -p 'pwd' -t 10 # 输出关键指标（截取片段） +-------------------+------------+-----------+------------------+----------------+ | SQL_ID | ELAPSED_MS | CPU_MS | STORAGE_READ_MS | NET_SEND_MS | +-------------------+------------+-----------+------------------+----------------+ | 0xabc123 | 2345 | 1987 | 212 | 146 | +-------------------+------------+-----------+------------------+----------------+ # CPU_MS占比84.7%，确认是计算瓶颈，非IO或网络

解读：

• CPU_MS远高于STORAGE_READ_MS，说明瓶颈在SQL解析、表达式计算、排序等CPU密集型操作；
• 此时应聚焦SQL改写（如避免CASE WHEN嵌套、减少子查询）、索引优化（覆盖索引减少计算）、或调整ob_sql_work_area_size参数增大排序内存。

5. 数据库能力沉淀：从项目交付到组织能力的闭环构建

很多团队做完一个国产数据库迁移项目，交付一纸报告、几台服务器、一堆脚本，就宣告结束。但太保的实践揭示了一个残酷事实：没有能力沉淀的迁移，90%会在半年后返工。第3页提到的“知识库沉淀问题超1000条”“1135人获OBCE认证”，不是KPI数字，而是对抗技术熵增的防火墙。当第一个DBA离职，第二个接手时，如果他不知道_ob_queuing_fast_freeze_min_count的阈值为什么设为500而不是30000，不知道ob-trace的Storage Read耗时突增意味着删除标记堆积，那么所有优化都会在一次误操作后灰飞烟灭。能力沉淀不是写文档，而是把经验固化为可执行、可验证、可传承的资产。

5.1 知识库体系：不是Wiki，而是带验证的故障模式库

太保的知识库不是静态页面，而是与监控系统联动的活体知识库。每一条问题记录都包含：

• 故障模式（Pattern）：如“DELETE后SELECT COUNT(*)超时”；
• 根因树（Root Cause Tree）：展开为“删除标记堆积→Queuing阈值不合理→未建函数索引”三级归因；
• 验证脚本（Validation Script）：一键执行即可复现问题并验证修复效果；
• 关联指标（Linked Metrics）：自动关联ob_sql_audit中ELAPSED_TIME > 5000的SQL ID。

示例知识库条目（简化）：

## ID: KB-0872 **模式**：小表`SELECT *`响应慢，`EXPLAIN`显示走索引但实际慢 **根因**： - L1：删除标记比例 > 50% - L2：未启用Queuing表或阈值过大 - L3：缺少`deleted_status`函数索引 **验证脚本**： ```sql -- 检查删除比例 SELECT (COUNT(*) - COUNT(CASE WHEN __pk_increment_id > 0 THEN 1 END)) * 100.0 / COUNT(*) FROM {table_name}; -- 检查是否Queuing表 SELECT table_name, tbl_properties FROM oceanbase.__all_table WHERE table_name = '{table_name}' AND tbl_properties LIKE '%queuing=true%'; -- 检查函数索引 SELECT index_name FROM oceanbase.__all_index_table WHERE table_name = '{table_name}' AND index_name LIKE 'idx_%deleted%';

修复方案：

1. ALTER TABLE {table_name} SET TBL_PROPERTIES='queuing_freeze_threshold=500'
2. ALTER TABLE {table_name} ADD COLUMN deleted_status TINYINT DEFAULT 0
3. CREATE INDEX idx_del_status ON {table_name}(deleted_status) WHERE deleted_status = 0

> **提示**：知识库条目必须附带`验证脚本`，否则无法闭环。曾有团队写了一篇“OceanBase序列缓存优化指南”，但未提供`SHOW SEQUENCE`验证命令，导致新DBA无法确认缓存是否生效，优化形同虚设。 ### 5.2 认证体系：OBCE不是考试，是上岗前的“压力测试” 1135人通过OBCE（OceanBase Certified Expert）认证，背后是严格的**实战考核机制**。考试不考选择题，而是给一个模拟生产环境（含3节点集群、预置10GB脏数据、注入5种典型故障），要求考生在120分钟内： - 用`ob-trace`定位一条慢SQL的根因； - 修改`queuing_freeze_threshold`并验证转储效果； - 编写`obdumper`命令完成跨集群数据迁移； - 修复一个因分布键缺失导致的热点分区。 未通过者不得参与核心系统上线。这种认证不是筛选“知道答案的人”，而是筛选“能在压力下正确操作的人”。某次考试中，32%考生在`ob-trace`环节超时，暴露了对分布式执行轨迹理解的断层——这直接推动了后续培训中`ob-trace`实操课时从2小时增至8小时。 ### 5.3 工具链闭环：从“指南针”预扫描到“瘦身”自动化 第5页的“指南针”预扫描工具，不是简单的兼容性检查器，而是**迁移前的风险探雷器**。它会自动执行： - **语法扫描**：识别`FORALL`、`BULK COLLECT`、`UTL_FILE`等OceanBase不支持或弱支持的PL/SQL特性； - **对象分析**：检测`LONG`类型字段、`REF`类型、未分区的大表； - **SQL画像**：对TOP 100慢SQL做执行计划比对，标记`FULL TABLE SCAN`、`CROSS JOIN`等高危模式； - **风险评级**：输出`RISK_LEVEL: HIGH/MEDIUM/LOW`及修复建议。 而“数据库瘦身”不仅是删数据，更是**基于访问热度的智能分层**： ```bash # 自动识别3个月未访问的分区，并归档 ob-shrink --cluster prod-ob --table POLICY_INFO --cold-threshold 90d --action archive # 对归档分区执行压缩（比常规压缩率高30%） ob-compress --partition p2022 --algorithm zstd --level 15

参数说明：

• --cold-threshold 90d：基于oceanbase.__all_virtual_table_stat中last_access_time判断冷热；
• --action archive：非删除，而是将分区元数据标记为ARCHIVED，数据移至对象存储；
• zstd --level 15：高压缩比算法，牺牲少量CPU换取存储节省。

6. 验证迁移效果的黄金三角：不只是RTO/RPO，更是业务SLA的穿透式校验

验收一个数据库迁移项目，很多人盯着RTO<30秒、RPO=0这些指标——它们重要，但只是底线。真正的价值验证，是看业务SLA是否在迁移后得到实质性提升。太保在会计核算系统上线后，没有止步于“系统可用”，而是用“黄金三角”穿透校验：性能基线、业务时效、成本水位。这三个维度必须同时达标，才算成功。比如第13页的收益：“应收模块性能提升2倍”是性能基线，“备份恢复时间缩短5倍”是业务时效，“存储成本节省80%”是成本水位。下面给出可直接复用的校验模板。

6.1 性能基线：用业务SQL代替TPC-C跑分

不要信厂商的TPC-C分数，要测真实业务SQL的P95响应时间。太保的做法是：

• 选取3类核心SQL：
  • 高频查询：如“保单查询”（SELECT * FROM POLICY WHERE policy_no = ?）；
  • 重计算报表：如“月度保费统计”（SELECT SUM(premium) FROM POLICY WHERE create_date BETWEEN ? AND ? GROUP BY product_code）；
  • 批处理作业：如“日终清算”（含10+表JOIN、聚合、更新）。
• 压测方法：用sysbench或自研ob-bench，模拟生产流量的1.5倍并发，持续30分钟，记录P95耗时。

校验表示例（会计核算系统）：

SQL类型	迁移前(P95/ms)	迁移后(P95/ms)	提升幅度	是否达标
保单查询	128	42	3.05x	✅ (≤50ms)
月度保费统计	8420	3950	2.13x	✅ (≤4500ms)
日终清算	14200	2850	4.98x	✅ (≤3000ms)

注意：P95必须稳定，不能“平均快但偶尔超时”。曾有系统P95从120ms降到45ms，但P99高达2100ms，根源是某条SQL未走索引，被ob-trace抓出后修复。

6.2 业务时效：从“系统可用”到“业务不卡”

RTO<30秒是故障恢复时间，但用户感知的是“我的保单为什么查不到”。太保定义业务时效SLA：

• 查询类：99%请求在500ms内返回；
• 交易类：99.9%请求在2秒内完成；
• 批处理类：100%作业在窗口期内完成（如日终清算必须在04:00前结束）。

验证方法：在应用层埋点，采集全链路耗时，与数据库ob_sql_audit日志交叉比对。例如，某次上线后发现“理赔报案”接口P99超时，排查发现是应用层未启用OceanBase的connection pool，导致每次请求新建连接，TCP handshake耗时占300ms。修复后P99从1800ms降至420ms。

6.3 成本水位：算清TCO，不止看License

国产数据库常被宣传“License免费”，但TCO（总拥有成本）可能更高。太保的成本水位校验表，包含5项硬指标：

成本项	迁移前（年）	迁移后（年）	变化	校验方式
硬件采购	¥280万	¥190万	-32%	服务器数量×单价（同配置）
存储成本	¥150万	¥30万	-80%	SELECT SUM(data_size) FROM __all_virtual_table

本文还有配套的精品资源，点击获取