OB案例、金融行业核心系统跑批SQL优化

最近在南宁出差，搞某个银行的核心系统跑批优化项目。

Oracle 19c Aix 生产环境跑完整体的批要40多分钟左右，在Ob国产环境（国产系统+国产海光CPU）跑要3个小时?。这个真不怪Ob，只能说海光处理器真是垃圾中的战斗机。

不过还好，测试环境硬件相对不给力的情况下，给哥优化到95分钟跑完，还算不错成绩了，目标是整体跑批时间搞到80分钟左右，就给领导交差。?

今天在跑批串行的节点（前后有依赖关系的节点上）遇到条慢SQL，挺有意思的，分享下。

表数据量：

慢SQL：

慢SQL执行计划：

主要慢的SQL和计划：

这条SQL执行时间跑10秒，慢在 PRIOR DBMS_RANDOM.VALUE IS NOT NULL ORDER BY PROD_TYPE 这段，如果去掉就非常快，毫秒级别出结果。

但是去掉以后返回的结果集数量和没去掉之前差别很大，BRANCH_ROLE 字段存储的内容是 'Role1|Role2|Role3|Role4|Role5' 这种数据格式，行的数据存放到一个列里面。

因为这条SQL没写 START WITH 条件, 我猜开发想实现的逻辑是将父节点和子节点关联成功的前提下，将每行的 BRANCH_ROLE 字段内  'Role1|Role2|Role3|Role4|Role5'  数据拆分成每一行

（REGEXP_SUBSTR(BRANCH_ROLE, '[^|]+', 1 , LEVEL) BRANCH_ROLE）

，才写了个 PRIOR DBMS_RANDOM.VALUE IS NOT NULL 条件，将不确定性带入递归条件中。

只要达到 CONNECT BY NOCYCLE LEVEL <= REGEXP_COUNT (BRANCH_ROLE, '[^|]+')  这个计数器条件以后，就停止递归。

假如 PROD_TYPE 有 10行，每行列拆行的情况下，数据会翻倍。

不过开发这个逻辑没写全，我按照他这个逻辑改写一版。

改写SQL

（PROD_TYPE 、ACCT_CCY 、SEQ_NO联合主键）

：

简单点说就是每一行数据展开 BRANCH_ROLE 列内的数据。改写的SQL看得懂就看，看不懂也不多说，说起来又一大堆?。

改成这样后SQL执行时间降到 58毫秒，优化也算是结束了， XXXXXXX 那段递归不慢不需要优化，因为 BRANCH 是唯一键。

整体SQL速度和执行计划：

验证环节：

差集比对后是等价的，我换过几个条件试过都是这样，只能说业务开发想实现的逻辑没写全，我给完善了下。、

其实还有个更简单，更激进的写法，速度比上面我改写的更快，考虑到金融行业的严谨性，没敢给。

PG好像也有个函数能实现这种逻辑，速度直接秒杀，不过哥忘了。