信创迁移：Oracle切换海量数据库，慢sql扫描

前言

在信创国产化落地进程中，Oracle向海量数据库迁移是政企、金融、制造行业数据库改造高频场景。大量项目落地过程中普遍遭遇同一个痛点：缺少标准化前置SQL性能摸底手段，只能上线部署后通过前端页面逐一点击业务功能，被动暴露慢SQL。该模式效率极低、漏检严重：低频定时任务、后台批处理SQL、冷门菜单查询、报表统计SQL无法通过前台操作覆盖，上线后大批量劣化SQL集中爆发，引发接口超时、业务卡顿、数据库资源耗尽，大幅拉长项目验收周期与上线风险。

本文结合Oracle迁移海量数据库落地实战，从等容量测试环境搭建、全量业务SQL采集、流量回放压测、多维度慢SQL自动捕获、SQL横向比对五个维度，输出一套可落地、标准化的预上线慢SQL挖掘落地体系，在数据体量、硬件规格贴近生产的隔离环境中，提前抓取绝大多数迁移劣化SQL，从源头规避上线性能事故。

一、痛点复盘：前台人工点选排查慢SQL的固有缺陷

1. 业务覆盖不全：仅能覆盖前端可见菜单接口，后台存储过程、定时JOB、离线报表、数据同步脚本、隐藏功能模块SQL无法触达，约30%~45%风险SQL遗漏。
2. 负载不真实：人工点击为单线程低频访问，无法复现生产高并发、大批量数据扫描场景，大量高并发下才暴露的执行计划劣化SQL无法被触发。
3. 人力成本高昂：全量业务菜单遍历需测试、DBA、开发多角色协同，数万行SQL依赖人工触发，大型业务系统排查周期动辄数周。
4. 数据量级错位：测试库常用脱敏小体量测试数据，生产千万/亿级数据下索引失效、统计信息异常带来的慢SQL在小样数据环境无法复现。

海量数据库与Oracle优化器、索引机制、SQL语法兼容、事务隔离、统计信息采集逻辑存在差异化，相同SQL在两套库执行计划极易发生畸变，是迁移慢SQL高发核心诱因，前置等容量环境摸底成为信创迁移必备环节。

二、核心方案总览：四阶式等容量环境慢SQL挖掘架构

整体落地分为四大阶段：1. 生产等效隔离环境标准化搭建；2. Oracle源端全量业务SQL归集；3. 真实业务流量全量回放压测；4. 海量数据库多源自动抓取劣化SQL，全程自动化采集，摒弃人工页面操作，覆盖全场景业务SQL。

阶段1：构建与生产数据量、硬件规格对齐的海量数据库测试环境

环境是精准复现慢SQL的基础，数据体量、硬件配置、系统参数、业务数据分布四项指标无限贴近生产，杜绝小数据测试导致的性能误判。

1.1 硬件与系统参数对齐

• 硬件：CPU架构（国产鲲鹏/飞腾同生产机型）、内存配比、存储IOPS、磁盘分区规则和生产环境保持一致；信创服务器关闭节能调度策略，规避硬件性能偏差。
• 海量数据库参数：参考生产Oracle业务特征，初始化共享内存、并发连接数、并行查询阈值、统计信息自动采集周期、事务相关参数，提前同步业务适配参数模板，避免参数不合理造成伪慢SQL干扰排查。

1.2 全量生产数据落地（关键）

1. 采用Oracle全量物理备份+逻辑导出组合方式，完整迁移生产表数据、索引、约束、分区、存储过程、函数、序列，数据行数、冷热数据分布、空值占比、分区边界和生产完全一致，严禁裁剪数据、精简历史归档数据。
2. 数据迁移完成后，在海量数据库执行全库统计信息采集，修正国产化数据库自动统计采集规则差异，规避因统计信息缺失引发执行计划异常。
3. 隔离环境：测试环境与生产网络物理隔离，杜绝测试流量影响线上业务。

阶段2：源端Oracle全量SQL采集，构建业务SQL基线库

依托Oracle原生性能组件，离线归集全量历史业务SQL，分为存量静态SQL与动态运行SQL两类，形成迁移SQL基准数据集。

2.1 存量静态SQL采集

1. 抓取应用程序源码内嵌SQL、MyBatis/MyBatis-Plus配置文件SQL、存储过程、函数、定时任务脚本、ETL同步SQL，借助代码扫描工具提取全部静态SQL语句，剔除系统内置、运维临时脚本SQL。
2. 利用Oracle SPA工具创建STS（SQL调优集），从共享游标缓存、AWR快照中批量归集周期内高频执行SQL，过滤SYS系统进程、数据库后台任务SQL，保留业务侧有效语句。

2.2 动态业务流量SQL捕获（生产低峰期执行）

两种无侵入采集方案按需选用，不影响生产性能：

1. 数据库层采集：开启Oracle细粒度审计或开启全量SQL追踪，选取3~7天完整业务周期（覆盖工作日、月末结账、定时批处理），采集全天全量执行SQL，包含高峰并发、夜间离线任务SQL。
2. 网络抓包采集：通过tcpdump抓Oracle数据库服务端口流量，基于数据库协议解析全量入站SQL，适合无法开启审计的高敏感生产场景，CPU损耗低于8%。

最终汇总形成全量SQL基线库，标注SQL执行频次、平均耗时、逻辑读、业务归属模块，作为后续压测回放数据源。

阶段3：基于真实流量的自动化压测回放，全场景触发SQL执行

基于归集的SQL基线与生产流量，在海量测试库开展多轮次分层压测，复现生产并发模型，自动触发全量业务SQL执行，替代人工前台点击。

3.1 压测场景分层设计

1. 日常业务压测：按照生产TPS配比并发数，回放日间前端接口流量，覆盖常规增删改查业务；
2. 批量任务压测：单独调度月末汇总、数据归档、报表统计、定时JOB脚本，还原夜间大批量DML/查询负载；
3. 峰值极限压测：复刻生产业务高峰期瞬时并发，挖掘高负载下优化器异常、索引失效带来的劣化SQL。

3.2 回放工具选型

1. 开源侧：Jmeter、Locust结合自定义脚本读取SQL基线文件批量回放；
2. 国产商用：海量数据库配套自带流量回放工具、信创数据库迁移SPA类性能比对组件，支持Oracle流量一键转译适配海量语法，自动修正兼容类语法差异后执行回放。

阶段4：海量数据库多渠道并行采集慢SQL，全维度汇总劣化清单

压测全周期开启多维度SQL采集机制，从慢查询日志、系统内置性能视图、监控指标、执行计划比对四路同步抓取慢SQL，统一入库归档。

4.1 开启海量数据库慢查询日志（基础采集）

1. 自定义慢SQL判定阈值：参考原Oracle同SQL平均执行耗时，设置阈值（如超过原库2倍耗时或单句执行＞1s即标记慢SQL），避免直接沿用默认阈值造成漏抓；
2. 日志落地配置：开启慢日志持久化，记录SQL原文、执行耗时、扫描行数、返回行数、执行时间、会话信息、所属业务模块，定期日志切割防止磁盘爆满。

4.2 依托海量系统视图抓取TOP负载SQL

海量数据库兼容PG生态视图体系，通过pg_stat_statements、内核性能视图实时统计全量SQL总耗时、调用次数、IO开销，筛选单次慢执行+高频累计耗资源两类风险SQL，尤其捕获低频但单次超大扫描的报表SQL。

4.3 全链路监控平台辅助抓取

搭建Prometheus+Grafana监控大盘，接入海量数据库exporter，监控CPU、磁盘IO、锁等待关联SQL，抓取因锁阻塞、资源争抢衍生的慢SQL，区分SQL本身劣化与环境资源瓶颈问题。

4.4 跨库SQL性能横向比对（迁移专项关键动作）

将同一条SQL分别在Oracle源库、海量测试库的执行耗时、逻辑读、物理读、执行计划做逐项比对：

1. 执行耗时上涨超50%、IO开销翻倍的SQL标记迁移劣化SQL；
2. 对比两套库执行计划，海量库出现全表扫描、错误索引选用、分区裁剪失效的SQL，优先纳入优化清单；
3. 语法兼容导致隐式转换、函数索引失效类慢SQL同步归类整改。

三、落地优化补充策略，进一步降低慢SQL漏检率

1. 分批次迭代压测：首轮全量回放后优化已发现慢SQL，二次复测验证优化效果，同时挖掘优化后衍生的新劣化SQL；
2. 冷门业务专项补测：针对历史半年仅执行数次的低频业务、特殊节假日专属功能，从SQL基线筛选对应语句单独构造数据场景执行；
3. 统计信息常态化校验：海量数据库数据变更量大时自动刷新统计信息，规避统计滞后导致优化器选错执行路径，减少伪慢SQL干扰排查。

四、落地收益

1. 排查效率提升70%以上：全自动化流量回放+多源采集，数天即可完成全业务SQL性能摸底，摆脱数周人工页面遍历；
2. 漏检率降至5%以内：覆盖前台业务+后台任务+离线报表+定时脚本全场景SQL，杜绝冷门SQL上线后突发性能故障；
3. 前移优化窗口期：上线前集中整改95%以上迁移劣化SQL，上线后性能故障大幅减少，保障信创迁移项目平稳割接；
4. 沉淀SQL资产：形成Oracle转海量的SQL优化知识库，后续同行业同类迁移项目可复用基线与优化方案。

五、落地注意事项

1. 生产SQL采集务必在业务低峰窗口期操作，严控抓包与审计资源开销，规避影响在线业务；
2. 测试环境数据严格脱敏，遵循数据安全法规，敏感字段加密处理；
3. 海量与Oracle语法差异提前预处理，回放前过滤语法报错SQL，单独归类做SQL改写优化。