1. 把读文件的脑子换成发SQL的脑子COBOL这门语言的骨子里刻的是文件系统那一套FILE-CONTROL 里 SELECT 一个逻辑文件名FD 里描述记录布局READ 一条记录AT END 走结束分支。这套思维在很多老项目里延续了几十年也正因为如此第一次把 COBOL 和关系型数据库对接起来时最容易犯的错不是语法不会写而是思维模型没切过来——手里拿着 SQL脑子里还在做逐记录的循环。我这里说的COBOL 与数据库的交互指的是在 COBOL 源程序里通过**嵌入式 SQLEmbedded SQL**的方式访问关系型数据库源码里以EXEC SQL ... END-EXEC包裹一段 SQL 语句由预编译器把这段外来的语句翻译成标准的 COBOL 调用再交给后面的编译、链接环节。它不是某种新框架也不是中间件而是从七十年代一路沿用至今、在大型核心业务系统里依然每天跑着几亿笔交易的老技术路线。适合读这篇的人大致分两类一类是刚接触大型机开发、手上有 COBOL 基础但没写过数据库交互的同学另一类是写过不少嵌入式 SQL、但在批处理作业和在线交易里被锁等待、游标泄漏、数据截断折腾过的老手想回头把机制理清楚。先说一个最直观的差异。文件读写是我走到数据跟前把它拎出来SQL 是我告诉数据库我要什么剩下的事它来办。前者的性能取决于你怎么安排 READ 的顺序、怎么建索引文件、什么时候做 REORG后者的性能取决于你写的 WHERE 条件能不能用上索引、取数的粒度有多大、事务边界切在哪里。这两种优化思路几乎不通用。我见过有人把文件时代一条一条处理、处理完立刻写回的习惯原封不动搬到数据库上结果一个夜间批处理从两小时跑成了八小时原因很简单每条记录一次 UPDATE加上一次提交网络往返和日志写盘的开销把时间全吃掉了。还有一个更隐蔽的惯性文件时代的状态码是FILE STATUS里的两位数字比如00正常、10到了文件尾、23记录不存在。数据库这边对应的是SQLCODE0正常、100没找到数据、负数是错误。看起来只是换了一套码值但坑在于语义并不完全对应文件读不到记录时你会很自然地走去建新记录的分支而 SQL 的100出现在单行 SELECT 里是一个明确信号出现在 FETCH 里是正常的循环终止条件出现在 UPDATE 后的影响行数判断里又是另一回事。把这三处混为一谈是后面很多逻辑 bug 的源头。1.1 源码里那段 SQL 到底长什么样先看一段最基础的写法这段代码在几乎所有 COBOL 项目里都能找到它的变体WORKING-STORAGE SECTION. EXEC SQL INCLUDE SQLCA END-EXEC. EXEC SQL BEGIN DECLARE SECTION END-EXEC. 01 WS-CUST-ID PIC X(10). 01 WS-CUST-NAME PIC X(60). 01 WS-CUST-BAL PIC S9(09)V99 COMP-3. EXEC SQL END DECLARE SECTION END-EXEC. PROCEDURE DIVISION. 1000-MAIN. MOVE C000000123 TO WS-CUST-ID EXEC SQL SELECT CUST_NAME, CUST_BAL INTO :WS-CUST-NAME, :WS-CUST-BAL FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC IF SQLCODE 0 DISPLAY NAME WS-CUST-NAME BAL WS-CUST-BAL ELSE IF SQLCODE 100 DISPLAY NOT FOUND ELSE PERFORM 9000-SQL-ERROR END-IF END-IF GOBACK.几个格式上的硬性约定必须记住这些不是风格问题是能不能编译通过的问题EXEC SQL必须写在B 区也就是第 12 列之后。写在 A 区第 8 到 11 列预编译器直接报错而且报错信息往往指不到真正的位置得自己数格子。每个语句块以END-EXEC收尾中间的内容按 SQL 语法写不遵循 COBOL 的句号规则。也就是说块里面不能拿 COBOL 的.去断句那会被当成 SQL 的一部分或者干脆报语法错。宿主变量前面必须带冒号:这是告诉预编译器这是 COBOL 的变量别当成列名。少了冒号数据库会以为你要比较的是一个叫 WS-CUST-ID 的列报-206列不存在。宿主变量必须在BEGIN DECLARE SECTION和END DECLARE SECTION之间声明。写在外面能编译过但预编译阶段取不到定义运行时的地址绑定会错位这种错最难查因为编译零告警跑起来数据全乱。1.2 预编译这一步改写了什么为什么它决定了运维流程很多刚上手的人会以为嵌入式 SQL 是编译器直接支持的其实不是。COBOL 编译器根本不认识EXEC SQL。中间必须插一道预编译器Precompiler它的工作可以拆成三件事理解这三件事对后面排查问题非常关键第一扫描并替换。预编译器把每一段EXEC SQL ... END-EXEC挖出来换成一串CALL语句调用数据库运行时的接口模块同时把原来的 SQL 变成注释保留在扩展源里。你拿到的扩展源有些环境叫 DBRM 对应的扩展 COBOL打开一看原来的 SQL 位置变成了一堆CALL DSNHLI USING ...之类的东西。第二生成访问包。SQL 语句本身被抽取成一份独立的中间文件再通过绑定Bind动作写进数据库的系统表里形成包Package或计划Plan。这一步是很多人忽略的关键程序跑的时候执行的其实是数据库里存的那份不是你源码里那份。第三产出时间戳。扩展源里会嵌进一个一致性标识Consistency Token程序运行时拿它去和数据库里的包比对对不上就报-818时间戳冲突。由此推出一个运维层面的铁律改了 SQL 就必须重新预编译、重新绑定、重新链接。我在一个项目里遇到过更离谱的情况——有人只重新编译了 COBOL没有重新绑定也就是跳过了预编译直接拿旧扩展源编译。程序上线后新加的那个字段死活取不出来日志里 SQLCODE 一直是 0看起来一切正常。查了整整一个下午最后把扩展源和数据库里的包定义调出来对比才发现跑的还是三个月前那份计划。所以上线检查清单里预编译—绑定—编译—链接—传输这五步必须是一条完整链路任何一步跳过都可能埋雷。2. 宿主变量怎么摆决定了数据准不准宿主变量Host Variable这块看着简单实际是数据错误的头号来源。它承担两个方向的搬运程序变量送进 SQL 当条件值SQL 结果集送出来填进程序变量。搬运过程中涉及类型转换、长度对齐、符号处理、空值判断每一环都能悄悄把数据搞坏而且往往不报错。2.1 PIC 子句与数据库类型的对照关系最实用的做法是把下面这张表贴在工位上写 SQL 之前先对一遍COBOL 声明对应的数据库列类型使用建议PIC X(n)CHAR(n)定长长度严格一致否则补空格或截断PIC X(n)VARCHAR(n)取数后会补空格到 n 位需另取长度字段PIC 9(4)SMALLINT/NUMERIC(4,0)无符号最大 9999超了报 -304PIC S9(9) COMPINTEGER二进制整数范围 ±21 亿PIC S9(18) COMPBIGINT二进制长整数PIC S9(p)V9(s) COMP-3DECIMAL(ps, s)打包十进制金额字段首选PIC S9(p)V9(s)(DISPLAY)DECIMAL(ps, s)字符形态存储效率低少用PIC XCHAR(1)单字符标志位01 ... OCCURS n TIMES数组 FETCH批量取数用见第 5 节关于金额字段这里要单独强调一句。千万不要用COMP二进制去接DECIMAL类型的金额。二进制浮点在十进制小数上做不到精确表示0.1 这种值存进去再取出来会变成 0.0999999…。可能一次运算看不出来但金额累计到几万笔之后尾差就出来了对账的时候能把人逼疯。COMP-3是打包十进制一位十进制数占半个字节和数据库的DECIMAL是天然的对应关系精度完全一致这是金融类系统里唯一正确的选择。2.2 定长字符串补空格一个静默的数据污染源VARCHAR类型的列取到PIC X(60)的变量里如果实际值是 5 个字符剩下的 55 个位置会被空格填满。这一刻变量里的内容已经不是原来的值了而是一个被右补空格到 60 位的版本。更麻烦的是在这个基础上再做比较EXEC SQL SELECT CUST_NAME INTO :WS-CUST-NAME FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC MOVE WS-CUST-NAME TO WS-SEARCH-KEY EXEC SQL SELECT COUNT(*) INTO :WS-CNT FROM CUSTOMER WHERE CUST_NAME :WS-SEARCH-KEY END-EXEC如果CUST_NAME列是VARCHAR(60)且实际值不带尾部空格而WS-SEARCH-KEY是PIC X(60)带着 55 个空格数据库在做等值比较时要不要忽略尾部空格取决于列类型的填充规则和比较语义。同一套代码在不同版本、不同兼容级别下表现可能不一致这是典型的本地测试通过、生产对不上的类型。稳妥的做法有两条一是取VARCHAR时同时取长度用LENGTH函数或者专门的长度字段比较时用TRIM处理二是比较条件里明确写WHERE TRIM(CUST_NAME) TRIM(:WS-SEARCH-KEY)代价是索引可能用不上所以更推荐第一条——在程序侧把数据规整干净再送进去。2.3 空值指示器变量不写就是自找麻烦数据库的NULL和 COBOL 变量里的空格、零是完全不同的概念但宿主变量本身表达不了我没值这件事。所以标准做法是给每个可能为空的宿主变量配一个指示器变量Indicator Variable紧跟在宿主变量后面写01 WS-CUST-PHONE PIC X(20). 01 WS-PHONE-IND PIC S9(4) COMP. EXEC SQL SELECT CUST_PHONE INTO :WS-CUST-PHONE :WS-PHONE-IND FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC IF WS-PHONE-IND 0 MOVE PHONE IS NULL TO WS-MSG ELSE CONTINUE END-IF指示器取值规则很简单-1表示该列是NULL0表示非空-2表示取数时发生了截断这个额外含义很多人不知道很有用。不判断指示器的后果是WS-CUST-PHONE里保留的是上一次循环的残留值程序会把这个陈旧的电话号码当成当前客户的信息继续用下去。这种错误在测试环境几乎不可能复现因为测试数据里往往没有 NULL一到生产就出事。还有一个反方向的坑插入时如果宿主变量的指示器是-1数据库会写入NULL如果不带指示器写进去的是空格串。空格串和NULL在后续的IS NULL查询、COUNT统计、外连接结果里行为完全不同。要写NULL就明确带指示器别指望默认行为。3. 游标的完整生命周期与那些容易漏掉的收尾动作单行SELECT ... INTO只能接一行结果这是硬约束。一旦你的查询可能返回多行必须上游标Cursor。这个道理大家都懂但游标真正难的不是怎么用而是什么时候必须用、什么时候必须关、跨提交怎么活下来。3.1 批处理里不用游标会怎样假设你写了一个不带游标的多行处理EXEC SQL SELECT CUST_ID INTO :WS-CUST-ID FROM CUSTOMER WHERE STATUS A END-EXEC表里若有 5000 条满足条件的记录数据库会报-811Result of SELECT is more than one row。有意思的是在不同的编译选项和运行时配置下这个错误有时被当作警告处理程序继续跑下去拿到的是任意一行通常是第一行。于是你写了五千次的循环实际处理的是同一条记录五千遍。这种 bug 的隐蔽程度极高因为 SQLCODE 可能不是负的日志里也没有明显报错唯一的线索是处理条数和源表条数对不上。加上WHERE条件精确到主键唯一性或者改用游标是仅有的两条路。前者在确实只要一条的场景下是正解后者在要处理一批的场景下是唯一解。3.2 DECLARE、OPEN、FETCH、CLOSE 的完整链路标准写法长这样四个动作一个都不能少01 WS-EOF-FLAG PIC X VALUE N. 01 WS-CUST-ID PIC X(10). 01 WS-CUST-NAME PIC X(60). PROCEDURE DIVISION. 2000-PROCESS. EXEC SQL DECLARE CUST-CUR CURSOR WITH HOLD FOR SELECT CUST_ID, CUST_NAME FROM CUSTOMER WHERE STATUS A ORDER BY CUST_ID END-EXEC. EXEC SQL OPEN CUST-CUR END-EXEC. IF SQLCODE NOT 0 PERFORM 9000-SQL-ERROR END-IF PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL FETCH CUST-CUR INTO :WS-CUST-ID, :WS-CUST-NAME END-EXEC EVALUATE SQLCODE WHEN 0 PERFORM 2100-HANDLE-ONE WHEN 100 MOVE Y TO WS-EOF-FLAG WHEN OTHER PERFORM 9000-SQL-ERROR END-EVALUATE END-PERFORM EXEC SQL CLOSE CUST-CUR END-EXEC.几个细节值得掰开说DECLARE放哪里。DECLARE CURSOR是声明性语句不是可执行语句它必须写在PROCEDURE DIVISION里但位于任何可执行语句之前。放在循环里、放在 IF 里、放在段落中间预编译器会报错。这也是后面事故复盘里那个典型案例的根源——有人为了每次循环重新查一批把 DECLARE 塞进了 PERFORM 内部。WITH HOLD的意义。默认情况下游标遇到COMMIT或ROLLBACK会自动关闭。批处理为了避免长事务撑爆日志必然要分批提交。这时候如果没有WITH HOLD第一次提交之后游标就没了下一次 FETCH 直接返回-501Cursor is not open。加了WITH HOLD游标跨提交保持打开位置不变接着往下取。这个关键字是批处理程序能不能正常跑完的分水岭。ORDER BY要不要写。如果处理逻辑对顺序没有要求不写能省掉一次排序开销大批量取数时差别很明显。但如果涉及按主键顺序分段提交按序号生成流水号这类需求ORDER BY就必须写而且最好让它走索引否则数据库会在临时空间里排一遍几千万行的排序能把临时表空间撑满。CLOSE一定要在正常出口和异常出口都执行。这个后面单独讲。3.3 定位更新不用重复写 WHERE 的那种写法处理读出来、算一下、写回去这类场景有两种写法。一种是在循环里再写一条UPDATE ... WHERE CUST_ID :WS-CUST-ID另一种是用定位更新EXEC SQL DECLARE UPD-CUR CURSOR FOR SELECT CUST_ID, CUST_BAL FROM CUSTOMER WHERE STATUS A FOR UPDATE OF CUST_BAL END-EXEC. EXEC SQL OPEN UPD-CUR END-EXEC. PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL FETCH UPD-CUR INTO :WS-CUST-ID, :WS-CUST-BAL END-EXEC IF SQLCODE 0 COMPUTE WS-NEW-BAL WS-CUST-BAL * 1.05 EXEC SQL UPDATE CUSTOMER SET CUST_BAL :WS-NEW-BAL WHERE CURRENT OF UPD-CUR END-EXEC ELSE MOVE Y TO WS-EOF-FLAG END-IF END-PERFORM EXEC SQL CLOSE UPD-CUR END-EXEC.WHERE CURRENT OF 游标名的好处有两个一是不用把主键再传一遍少一次参数绑定和比较二是数据库可以直接用游标当前行的物理位置定位省掉一次索引查找。但它有使用前提游标声明时必须带FOR UPDATE OF 列名而且查询里不能有DISTINCT、GROUP BY、UNION、聚合函数这些会让结果集无法回溯到具体行的东西。写了不支持的查询再配FOR UPDATE数据库会直接拒绝声明。还有一个隐性成本要注意带FOR UPDATE的游标在 FETCH 的时候就会对行加锁锁一直持有到游标关闭或者事务提交。如果循环体里做了耗时的计算、调用了外部接口、写了日志文件锁持有时间会被拉得很长并发环境下极容易造成锁等待连锁反应。批处理里更推荐先全量读出来放到内存数组算完再批量更新把锁的持有窗口压到最短。4. SQLCODE 的分支不能只判断是不是负数错误处理这块是分水岭。写得糙的程序只有一个IF SQLCODE NOT 0 THEN DISPLAY ERROR写得好的程序会把返回码分类处理因为不是所有非零返回码都是错误也不是所有零返回码都代表操作生效了。4.1 SQLCA 里真正该看的几个字段INCLUDE SQLCA引入的是一个通信区结构里面字段不少但日常需要盯的就下面这几个字段含义什么时候必须看SQLCODE主返回码0 成功100 无数据负数错误每条语句执行后SQLSTATE五位标准状态码跨平台通用性更好做可移植代码时SQLERRD(3)上一条语句实际影响的行数UPDATE / DELETE / INSERT 之后SQLERRD(4)预估的代价信息调优时参考SQLWARN0是否发生了警告值为W表示有取数之后SQLWARN1字符串截断警告取 VARCHAR 到定长变量时SQLWARN2空值被消除警告聚合函数遇到 NULL 时SQLERRMC错误详细信息记录日志时这里面SQLERRD(3)最容易被忽略也最要命。看这段EXEC SQL UPDATE ACCOUNT SET BALANCE :WS-NEW-BAL WHERE ACCT_NO :WS-ACCT-NO END-EXEC IF SQLCODE 0 DISPLAY UPDATE SUCCESS END-IF如果WHERE一条都没命中SQLCODE 依然是0。程序会认为更新成功了后续的对账、流水、通知全部按已更新往下走实际数据库里一个字节都没变。正确写法是紧跟着判断SQLERRD(3)IF SQLCODE 0 IF SQLERRD(3) 0 DISPLAY NO ROW UPDATED, KEY WS-ACCT-NO MOVE N TO WS-UPDATE-FLAG ELSE MOVE Y TO WS-UPDATE-FLAG END-IF END-IF4.2 几个高频返回码的实际含义100无数据。它在三个位置含义完全不同——单行 SELECT 里表示没查到FETCH 里表示游标取完了UPDATE/DELETE ... WHERE CURRENT OF里表示当前行已被别人删掉。三种情况要做三种处理不能统一PERFORM ERROR。-811单行 SELECT 返回了多行。前面说过这个在宽松配置下会退化成取第一行必须主动捕获并当作逻辑错误处理因为这意味着你的 WHERE 条件设计有问题。-305空值不能赋给宿主变量。说明你取了一个 NULL 列但没有配指示器变量这时候宿主变量的内容是未定义的可能是上次的残留值也可能是垃圾。看到这个码别急着加COALESCE了事先想清楚业务上 NULL 应该怎么表达。-304数值超出范围。典型场景是用PIC 9(4)去接一个五位数的列或者PIC S9(9) COMP去接超过了 21 亿的值。这种错误在老系统扩容时批量出现——业务量涨了原来四位的编号不够用了代码里所有 PIC 定义都得跟着改。-911/-913死锁或锁等待超时。这是并发问题的信号不是代码语法问题。看到这两个码第一反应应该是去查锁等待图看是谁在持锁而不是在代码里加RETRY循环硬扛。-501游标没打开就 FETCH。八成是COMMIT把游标关了回去检查WITH HOLD。-818时间戳冲突。包和程序版本对不上回去检查预编译、绑定、链接的顺序有没有断。4.3 事务边界在线交易和批处理是两套规则在线交易环境里事务边界通常由事务监控器统一管理。一个交易进来监控器开启事务程序处理返回时监控器统一提交或回滚。这种情况下程序里主动写 COMMIT 是非常危险的动作因为它会把监控器管理的事务提前切断后续如果出错回滚只能回到 COMMIT 那个点前面已经提交的部分撤不回来数据一致性直接崩掉。批处理环境则相反程序自己就是事务的主人。这里的经验值是提交间隔500 到 2000 条记录提交一次。太小了日志写盘次数多太大了日志空间不够用、回滚段压力大、重启点太靠前。重启点设计批处理必须能在中断后接着跑。常见做法是每批提交时更新一张控制表记录已处理到的最大主键重启时从这个值之后继续。这张控制表的更新必须和业务数据在同一个事务里否则会出现数据提交了但重启点没更新或者反过来的错位。保存点的使用局部可恢复的场景可以用SAVEPOINT出错回滚到保存点而不影响前面的批次。用的人不多但在处理一条记录有多个写操作、失败要整条回退的场景下很实用。5. 一次游标泄漏事故的完整排查链路这一段复盘一个我印象比较深的线上问题把前面说的机制串起来。问题现象是夜间批处理作业运行到中途开始变慢日志里每隔一段时间刷一批-911最后整个 JOB 挂住不动直到运维手动杀掉。5.1 现象与第一轮排查先看 JOBLOG 的 SQLCODE 分布。发现-911集中出现在某几个特定段落而且出现频率随着运行时间递增。再看数据库侧的活动会话发现有大量会话状态是UOW-EXECUTING都在等同一把锁锁的持有者是一个长时间运行的批处理会话。第一反应是找出谁在持锁。查下去发现持锁的是同一个作业自己的另一个游标——也就是说程序自己在跟自己抢锁。这就把方向锁定了游标的加锁范围超出了预期循环体里必然有地方让锁没有被及时释放。5.2 根因DECLARE 写在了循环里面翻代码问题段落的骨架是这样的PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL DECLARE REV-CUR CURSOR WITH HOLD FOR SELECT ... FROM REVERSAL WHERE ... END-EXEC EXEC SQL OPEN REV-CUR END-EXEC EXEC SQL FETCH REV-CUR INTO :WS-REC END-EXEC IF SQLCODE 0 PERFORM 5000-PROCESS-ONE ELSE MOVE Y TO WS-EOF-FLAG END-IF EXEC SQL CLOSE REV-CUR END-EXEC END-PERFORM表面上 OPEN 和 CLOSE 是配对的看起来没问题。但这里有两个连锁反应一是WITH HOLD加在了这段游标上。WITH HOLD的语义是游标跨提交保持打开但同时也意味着在游标关闭之前它持有的锁不会因为提交而释放。这个游标在每轮循环里开了又关但关闭动作在异常分支里被跳过了——PERFORM 5000-PROCESS-ONE如果内部遇到错误直接GOBACK后面的CLOSE根本不执行。累积下来每次异常都漏掉一个游标锁越积越多。二是DECLARE写在循环里虽然预编译器在某些版本下允许但每次重新执行 OPEN 会用同一个游标名去申请新的资源命名空间冲突导致前面那个游标的句柄丢失想关也关不掉了。这属于典型的句柄泄漏。5.3 修复方案与验证办法改写思路四条DECLARE移到PROCEDURE DIVISION的最前面只声明一次。去掉不必要的WITH HOLD。这个游标是逐条处理、不跨提交的WITH HOLD只会延长锁持有时间纯属负优化。异常出口统一收口。把 GOBACK 全部改成PERFORM 9999-EXIT在9999-EXIT段落里统一判断游标状态并关闭。加一层运行期埋点每次 OPEN 和 CLOSE 都向日志写一行记录用计数器统计配平情况。验证方式很直接跑一轮完整批处理后从日志里统计 OPEN 次数和 CLOSE 次数两者必须相等。如果再出现不等说明还有别的异常出口没被收口。这个配平检查后来被固化进了上线检查清单凡是涉及游标的改动都要过一遍。提示凡是使用WITH HOLD的游标都要在代码注释里写明为什么这里需要跨提交保持并注明预期的关闭点。没有明确理由的WITH HOLD一律删掉。这条经验在很多次性能问题复盘里都成立。6. 让程序跑得快几条血泪换来的调优经验最后这一段讲性能。嵌入式 SQL 的性能问题有个特点代码上完全正确逻辑上完全站得住就是慢。慢的原因几乎都在看不到的地方——索引失效、类型转换、网络往返、锁竞争。6.1 隐式类型转换是索引的头号杀手看这条语句01 WS-CUST-ID PIC 9(08). EXEC SQL SELECT CUST_NAME INTO :WS-CUST-NAME FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC如果CUSTOMER.CUST_ID列的类型是CHAR(8)而宿主变量是PIC 9(8)数字数据库在执行时要把两边的类型统一这个统一动作发生在列的一侧也就是对CUST_ID施加了函数转换索引直接失效全表扫描。解决办法只有一个宿主变量的类型必须和列的声明类型严格一致。列是CHAR(8)变量就是PIC X(8)列是DECIMAL(9,2)变量就是PIC S9(7)V99 COMP-3连符号位和位数都要对齐。这在重构老代码时工作量不小但收益立竿见影。同样的道理也适用于变量比列长和变量比列短两种情况。变量比列长取数时会补空格前面说过会污染比较变量比列短取数时会被截断SQLWARN1会被置位数据静默丢尾。两种都不报错但都是错的。6.2 批量取数数组 FETCH 与批次大小逐行 FETCH 的问题是每次都在网络上走一个来回。跨 LPAR、跨数据中心的时候单次往返可能是几百微秒乘以一千万行就是一个小时起步。解决办法是数组 FETCH一次取多行到 COBOL 的数组里然后在内存里遍历。01 WS-FETCH-SIZE PIC S9(4) COMP VALUE 500. 01 WS-ID-ARRAY. 05 WS-ID-ELEM PIC X(10) OCCURS 500 TIMES. 01 WS-NAME-ARRAY. 05 WS-NAME-ELEM PIC X(60) OCCURS 500 TIMES. EXEC SQL FETCH CUST-CUR INTO :WS-ID-ARRAY, :WS-NAME-ARRAY END-EXEC EVALUATE SQLCODE WHEN 0 MOVE WS-FETCH-SIZE TO WS-LOOP-CNT WHEN 100 MOVE 0 TO WS-LOOP-CNT WHEN OTHER PERFORM 9000-SQL-ERROR END-EVALUATE PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I WS-LOOP-CNT PERFORM 2100-HANDLE-ONE END-PERFORM批次大小怎么定我自己的经验是有个几百到一千行的甜点区。太小了往返次数降不下来太大了单次网络传输的数据量大、内存占用高而且一旦 SQLCODE 是 0 但实际只取到一半最后一批需要靠SQLERRD(3)判断实际取到了多少行。上代码里简化的MOVE WS-FETCH-SIZE TO WS-LOOP-CNT只在能整除的情况下成立实际生产代码必须处理尾批。6.3 把循环里的单条查询消灭掉这是最常见也最容易被放过的问题主查询取出一个列表然后对列表里每一条再发一次子查询。一千万行意味着多发一千万次查询哪怕每个都很小累计开销也能把整批处理拖垮。破法是把子查询改成关联一次取出EXEC SQL SELECT A.CUST_ID, A.CUST_NAME, B.LAST_ORDER_DT INTO :WS-CUST-ID, :WS-CUST-NAME, :WS-LAST-DT FROM CUSTOMER A LEFT JOIN ORDER_HDR B ON B.CUST_ID A.CUST_ID AND B.ORDER_DT (SELECT MAX(ORDER_DT) FROM ORDER_HDR C WHERE C.CUST_ID A.CUST_ID) WHERE A.STATUS A END-EXEC这种改写要注意的一点是LEFT JOIN和聚合子查询的组合在大数据量下执行计划可能不理想。上线前务必用EXPLAIN看看实际走的是不是索引嵌套循环或者哈希连接如果冒出全表扫描和临时排序宁可拆成先批量取出客户列表 → 再用IN列表批量查订单 → 在内存里做映射的两段式虽然代码长一点但可控性强得多。注意任何新写的多表关联都不要在没看过执行计划的情况下直接投产。跑一次EXPLAIN五秒钟的事能省掉后面几天的性能问题排查。6.4 锁的持有窗口比锁的粒度更重要前面反复提到锁这里做个总结。影响并发的不只是隔离级别和锁粒度锁的持有时间往往是决定性因素。三条实操原则循环体内部不做耗时的非数据库操作。写文件、调外呼、算复杂逻辑统统挪到循环外面或者挪到取数完成之后。游标的锁窗口从 OPEN 开始算到 CLOSE 结束。既然锁的持有时间和取数范围强相关就不要用一个大游标扫全表。按主键分段一段一段来既降低锁窗口也方便断点重启。在线交易里尽量把访问对象的顺序统一。同一个交易流程里先访问 A 表再访问 B 表所有并发交易都保持这个顺序能规避掉绝大部分死锁。死锁的本质是环环的成因是顺序不一致。7. 几句实操层面的补充嵌入式 SQL 这块的知识点书本上讲的都是语法真正难的是那些不报错但结果不对的情形。我自己踩得最多的三类前面都覆盖到了宿主变量的类型与长度对齐、指示器的使用、返回码的分支处理。这三块如果一开始就建立正确习惯后面的项目能少走很多弯路。再补充一个工作习惯上的建议新写的 SQL 段先在交互式环境里手工跑一遍确认语句本身返回的结果和行数是符合预期的再嵌进 COBOL 里。很多人一上来就在程序里调出了错分不清是 SQL 写错了还是宿主变量绑错了来回折腾半天。先在数据库客户端验证 SQL 逻辑再验证 COBOL 侧的数据搬运两段分开定位效率差好几倍。还有个细节批处理程序建议在开场和收场各打一条带时间戳的日志在循环里每处理 N 条打一条进度日志。看起来是小事但夜间作业出问题时这两条日志能让你在一分钟内判断是卡在取数还是卡在写库省下的排查时间远超过写日志的成本。这是纯经验性的东西文档里不会写但实际干活的时候特别管用。
1. 把读文件的脑子换成发SQL的脑子COBOL这门语言的骨子里刻的是文件系统那一套FILE-CONTROL 里 SELECT 一个逻辑文件名FD 里描述记录布局READ 一条记录AT END 走结束分支。这套思维在很多老项目里延续了几十年也正因为如此第一次把 COBOL 和关系型数据库对接起来时最容易犯的错不是语法不会写而是思维模型没切过来——手里拿着 SQL脑子里还在做逐记录的循环。我这里说的COBOL 与数据库的交互指的是在 COBOL 源程序里通过**嵌入式 SQLEmbedded SQL**的方式访问关系型数据库源码里以EXEC SQL ... END-EXEC包裹一段 SQL 语句由预编译器把这段外来的语句翻译成标准的 COBOL 调用再交给后面的编译、链接环节。它不是某种新框架也不是中间件而是从七十年代一路沿用至今、在大型核心业务系统里依然每天跑着几亿笔交易的老技术路线。适合读这篇的人大致分两类一类是刚接触大型机开发、手上有 COBOL 基础但没写过数据库交互的同学另一类是写过不少嵌入式 SQL、但在批处理作业和在线交易里被锁等待、游标泄漏、数据截断折腾过的老手想回头把机制理清楚。先说一个最直观的差异。文件读写是我走到数据跟前把它拎出来SQL 是我告诉数据库我要什么剩下的事它来办。前者的性能取决于你怎么安排 READ 的顺序、怎么建索引文件、什么时候做 REORG后者的性能取决于你写的 WHERE 条件能不能用上索引、取数的粒度有多大、事务边界切在哪里。这两种优化思路几乎不通用。我见过有人把文件时代一条一条处理、处理完立刻写回的习惯原封不动搬到数据库上结果一个夜间批处理从两小时跑成了八小时原因很简单每条记录一次 UPDATE加上一次提交网络往返和日志写盘的开销把时间全吃掉了。还有一个更隐蔽的惯性文件时代的状态码是FILE STATUS里的两位数字比如00正常、10到了文件尾、23记录不存在。数据库这边对应的是SQLCODE0正常、100没找到数据、负数是错误。看起来只是换了一套码值但坑在于语义并不完全对应文件读不到记录时你会很自然地走去建新记录的分支而 SQL 的100出现在单行 SELECT 里是一个明确信号出现在 FETCH 里是正常的循环终止条件出现在 UPDATE 后的影响行数判断里又是另一回事。把这三处混为一谈是后面很多逻辑 bug 的源头。1.1 源码里那段 SQL 到底长什么样先看一段最基础的写法这段代码在几乎所有 COBOL 项目里都能找到它的变体WORKING-STORAGE SECTION. EXEC SQL INCLUDE SQLCA END-EXEC. EXEC SQL BEGIN DECLARE SECTION END-EXEC. 01 WS-CUST-ID PIC X(10). 01 WS-CUST-NAME PIC X(60). 01 WS-CUST-BAL PIC S9(09)V99 COMP-3. EXEC SQL END DECLARE SECTION END-EXEC. PROCEDURE DIVISION. 1000-MAIN. MOVE C000000123 TO WS-CUST-ID EXEC SQL SELECT CUST_NAME, CUST_BAL INTO :WS-CUST-NAME, :WS-CUST-BAL FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC IF SQLCODE 0 DISPLAY NAME WS-CUST-NAME BAL WS-CUST-BAL ELSE IF SQLCODE 100 DISPLAY NOT FOUND ELSE PERFORM 9000-SQL-ERROR END-IF END-IF GOBACK.几个格式上的硬性约定必须记住这些不是风格问题是能不能编译通过的问题EXEC SQL必须写在B 区也就是第 12 列之后。写在 A 区第 8 到 11 列预编译器直接报错而且报错信息往往指不到真正的位置得自己数格子。每个语句块以END-EXEC收尾中间的内容按 SQL 语法写不遵循 COBOL 的句号规则。也就是说块里面不能拿 COBOL 的.去断句那会被当成 SQL 的一部分或者干脆报语法错。宿主变量前面必须带冒号:这是告诉预编译器这是 COBOL 的变量别当成列名。少了冒号数据库会以为你要比较的是一个叫 WS-CUST-ID 的列报-206列不存在。宿主变量必须在BEGIN DECLARE SECTION和END DECLARE SECTION之间声明。写在外面能编译过但预编译阶段取不到定义运行时的地址绑定会错位这种错最难查因为编译零告警跑起来数据全乱。1.2 预编译这一步改写了什么为什么它决定了运维流程很多刚上手的人会以为嵌入式 SQL 是编译器直接支持的其实不是。COBOL 编译器根本不认识EXEC SQL。中间必须插一道预编译器Precompiler它的工作可以拆成三件事理解这三件事对后面排查问题非常关键第一扫描并替换。预编译器把每一段EXEC SQL ... END-EXEC挖出来换成一串CALL语句调用数据库运行时的接口模块同时把原来的 SQL 变成注释保留在扩展源里。你拿到的扩展源有些环境叫 DBRM 对应的扩展 COBOL打开一看原来的 SQL 位置变成了一堆CALL DSNHLI USING ...之类的东西。第二生成访问包。SQL 语句本身被抽取成一份独立的中间文件再通过绑定Bind动作写进数据库的系统表里形成包Package或计划Plan。这一步是很多人忽略的关键程序跑的时候执行的其实是数据库里存的那份不是你源码里那份。第三产出时间戳。扩展源里会嵌进一个一致性标识Consistency Token程序运行时拿它去和数据库里的包比对对不上就报-818时间戳冲突。由此推出一个运维层面的铁律改了 SQL 就必须重新预编译、重新绑定、重新链接。我在一个项目里遇到过更离谱的情况——有人只重新编译了 COBOL没有重新绑定也就是跳过了预编译直接拿旧扩展源编译。程序上线后新加的那个字段死活取不出来日志里 SQLCODE 一直是 0看起来一切正常。查了整整一个下午最后把扩展源和数据库里的包定义调出来对比才发现跑的还是三个月前那份计划。所以上线检查清单里预编译—绑定—编译—链接—传输这五步必须是一条完整链路任何一步跳过都可能埋雷。2. 宿主变量怎么摆决定了数据准不准宿主变量Host Variable这块看着简单实际是数据错误的头号来源。它承担两个方向的搬运程序变量送进 SQL 当条件值SQL 结果集送出来填进程序变量。搬运过程中涉及类型转换、长度对齐、符号处理、空值判断每一环都能悄悄把数据搞坏而且往往不报错。2.1 PIC 子句与数据库类型的对照关系最实用的做法是把下面这张表贴在工位上写 SQL 之前先对一遍COBOL 声明对应的数据库列类型使用建议PIC X(n)CHAR(n)定长长度严格一致否则补空格或截断PIC X(n)VARCHAR(n)取数后会补空格到 n 位需另取长度字段PIC 9(4)SMALLINT/NUMERIC(4,0)无符号最大 9999超了报 -304PIC S9(9) COMPINTEGER二进制整数范围 ±21 亿PIC S9(18) COMPBIGINT二进制长整数PIC S9(p)V9(s) COMP-3DECIMAL(ps, s)打包十进制金额字段首选PIC S9(p)V9(s)(DISPLAY)DECIMAL(ps, s)字符形态存储效率低少用PIC XCHAR(1)单字符标志位01 ... OCCURS n TIMES数组 FETCH批量取数用见第 5 节关于金额字段这里要单独强调一句。千万不要用COMP二进制去接DECIMAL类型的金额。二进制浮点在十进制小数上做不到精确表示0.1 这种值存进去再取出来会变成 0.0999999…。可能一次运算看不出来但金额累计到几万笔之后尾差就出来了对账的时候能把人逼疯。COMP-3是打包十进制一位十进制数占半个字节和数据库的DECIMAL是天然的对应关系精度完全一致这是金融类系统里唯一正确的选择。2.2 定长字符串补空格一个静默的数据污染源VARCHAR类型的列取到PIC X(60)的变量里如果实际值是 5 个字符剩下的 55 个位置会被空格填满。这一刻变量里的内容已经不是原来的值了而是一个被右补空格到 60 位的版本。更麻烦的是在这个基础上再做比较EXEC SQL SELECT CUST_NAME INTO :WS-CUST-NAME FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC MOVE WS-CUST-NAME TO WS-SEARCH-KEY EXEC SQL SELECT COUNT(*) INTO :WS-CNT FROM CUSTOMER WHERE CUST_NAME :WS-SEARCH-KEY END-EXEC如果CUST_NAME列是VARCHAR(60)且实际值不带尾部空格而WS-SEARCH-KEY是PIC X(60)带着 55 个空格数据库在做等值比较时要不要忽略尾部空格取决于列类型的填充规则和比较语义。同一套代码在不同版本、不同兼容级别下表现可能不一致这是典型的本地测试通过、生产对不上的类型。稳妥的做法有两条一是取VARCHAR时同时取长度用LENGTH函数或者专门的长度字段比较时用TRIM处理二是比较条件里明确写WHERE TRIM(CUST_NAME) TRIM(:WS-SEARCH-KEY)代价是索引可能用不上所以更推荐第一条——在程序侧把数据规整干净再送进去。2.3 空值指示器变量不写就是自找麻烦数据库的NULL和 COBOL 变量里的空格、零是完全不同的概念但宿主变量本身表达不了我没值这件事。所以标准做法是给每个可能为空的宿主变量配一个指示器变量Indicator Variable紧跟在宿主变量后面写01 WS-CUST-PHONE PIC X(20). 01 WS-PHONE-IND PIC S9(4) COMP. EXEC SQL SELECT CUST_PHONE INTO :WS-CUST-PHONE :WS-PHONE-IND FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC IF WS-PHONE-IND 0 MOVE PHONE IS NULL TO WS-MSG ELSE CONTINUE END-IF指示器取值规则很简单-1表示该列是NULL0表示非空-2表示取数时发生了截断这个额外含义很多人不知道很有用。不判断指示器的后果是WS-CUST-PHONE里保留的是上一次循环的残留值程序会把这个陈旧的电话号码当成当前客户的信息继续用下去。这种错误在测试环境几乎不可能复现因为测试数据里往往没有 NULL一到生产就出事。还有一个反方向的坑插入时如果宿主变量的指示器是-1数据库会写入NULL如果不带指示器写进去的是空格串。空格串和NULL在后续的IS NULL查询、COUNT统计、外连接结果里行为完全不同。要写NULL就明确带指示器别指望默认行为。3. 游标的完整生命周期与那些容易漏掉的收尾动作单行SELECT ... INTO只能接一行结果这是硬约束。一旦你的查询可能返回多行必须上游标Cursor。这个道理大家都懂但游标真正难的不是怎么用而是什么时候必须用、什么时候必须关、跨提交怎么活下来。3.1 批处理里不用游标会怎样假设你写了一个不带游标的多行处理EXEC SQL SELECT CUST_ID INTO :WS-CUST-ID FROM CUSTOMER WHERE STATUS A END-EXEC表里若有 5000 条满足条件的记录数据库会报-811Result of SELECT is more than one row。有意思的是在不同的编译选项和运行时配置下这个错误有时被当作警告处理程序继续跑下去拿到的是任意一行通常是第一行。于是你写了五千次的循环实际处理的是同一条记录五千遍。这种 bug 的隐蔽程度极高因为 SQLCODE 可能不是负的日志里也没有明显报错唯一的线索是处理条数和源表条数对不上。加上WHERE条件精确到主键唯一性或者改用游标是仅有的两条路。前者在确实只要一条的场景下是正解后者在要处理一批的场景下是唯一解。3.2 DECLARE、OPEN、FETCH、CLOSE 的完整链路标准写法长这样四个动作一个都不能少01 WS-EOF-FLAG PIC X VALUE N. 01 WS-CUST-ID PIC X(10). 01 WS-CUST-NAME PIC X(60). PROCEDURE DIVISION. 2000-PROCESS. EXEC SQL DECLARE CUST-CUR CURSOR WITH HOLD FOR SELECT CUST_ID, CUST_NAME FROM CUSTOMER WHERE STATUS A ORDER BY CUST_ID END-EXEC. EXEC SQL OPEN CUST-CUR END-EXEC. IF SQLCODE NOT 0 PERFORM 9000-SQL-ERROR END-IF PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL FETCH CUST-CUR INTO :WS-CUST-ID, :WS-CUST-NAME END-EXEC EVALUATE SQLCODE WHEN 0 PERFORM 2100-HANDLE-ONE WHEN 100 MOVE Y TO WS-EOF-FLAG WHEN OTHER PERFORM 9000-SQL-ERROR END-EVALUATE END-PERFORM EXEC SQL CLOSE CUST-CUR END-EXEC.几个细节值得掰开说DECLARE放哪里。DECLARE CURSOR是声明性语句不是可执行语句它必须写在PROCEDURE DIVISION里但位于任何可执行语句之前。放在循环里、放在 IF 里、放在段落中间预编译器会报错。这也是后面事故复盘里那个典型案例的根源——有人为了每次循环重新查一批把 DECLARE 塞进了 PERFORM 内部。WITH HOLD的意义。默认情况下游标遇到COMMIT或ROLLBACK会自动关闭。批处理为了避免长事务撑爆日志必然要分批提交。这时候如果没有WITH HOLD第一次提交之后游标就没了下一次 FETCH 直接返回-501Cursor is not open。加了WITH HOLD游标跨提交保持打开位置不变接着往下取。这个关键字是批处理程序能不能正常跑完的分水岭。ORDER BY要不要写。如果处理逻辑对顺序没有要求不写能省掉一次排序开销大批量取数时差别很明显。但如果涉及按主键顺序分段提交按序号生成流水号这类需求ORDER BY就必须写而且最好让它走索引否则数据库会在临时空间里排一遍几千万行的排序能把临时表空间撑满。CLOSE一定要在正常出口和异常出口都执行。这个后面单独讲。3.3 定位更新不用重复写 WHERE 的那种写法处理读出来、算一下、写回去这类场景有两种写法。一种是在循环里再写一条UPDATE ... WHERE CUST_ID :WS-CUST-ID另一种是用定位更新EXEC SQL DECLARE UPD-CUR CURSOR FOR SELECT CUST_ID, CUST_BAL FROM CUSTOMER WHERE STATUS A FOR UPDATE OF CUST_BAL END-EXEC. EXEC SQL OPEN UPD-CUR END-EXEC. PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL FETCH UPD-CUR INTO :WS-CUST-ID, :WS-CUST-BAL END-EXEC IF SQLCODE 0 COMPUTE WS-NEW-BAL WS-CUST-BAL * 1.05 EXEC SQL UPDATE CUSTOMER SET CUST_BAL :WS-NEW-BAL WHERE CURRENT OF UPD-CUR END-EXEC ELSE MOVE Y TO WS-EOF-FLAG END-IF END-PERFORM EXEC SQL CLOSE UPD-CUR END-EXEC.WHERE CURRENT OF 游标名的好处有两个一是不用把主键再传一遍少一次参数绑定和比较二是数据库可以直接用游标当前行的物理位置定位省掉一次索引查找。但它有使用前提游标声明时必须带FOR UPDATE OF 列名而且查询里不能有DISTINCT、GROUP BY、UNION、聚合函数这些会让结果集无法回溯到具体行的东西。写了不支持的查询再配FOR UPDATE数据库会直接拒绝声明。还有一个隐性成本要注意带FOR UPDATE的游标在 FETCH 的时候就会对行加锁锁一直持有到游标关闭或者事务提交。如果循环体里做了耗时的计算、调用了外部接口、写了日志文件锁持有时间会被拉得很长并发环境下极容易造成锁等待连锁反应。批处理里更推荐先全量读出来放到内存数组算完再批量更新把锁的持有窗口压到最短。4. SQLCODE 的分支不能只判断是不是负数错误处理这块是分水岭。写得糙的程序只有一个IF SQLCODE NOT 0 THEN DISPLAY ERROR写得好的程序会把返回码分类处理因为不是所有非零返回码都是错误也不是所有零返回码都代表操作生效了。4.1 SQLCA 里真正该看的几个字段INCLUDE SQLCA引入的是一个通信区结构里面字段不少但日常需要盯的就下面这几个字段含义什么时候必须看SQLCODE主返回码0 成功100 无数据负数错误每条语句执行后SQLSTATE五位标准状态码跨平台通用性更好做可移植代码时SQLERRD(3)上一条语句实际影响的行数UPDATE / DELETE / INSERT 之后SQLERRD(4)预估的代价信息调优时参考SQLWARN0是否发生了警告值为W表示有取数之后SQLWARN1字符串截断警告取 VARCHAR 到定长变量时SQLWARN2空值被消除警告聚合函数遇到 NULL 时SQLERRMC错误详细信息记录日志时这里面SQLERRD(3)最容易被忽略也最要命。看这段EXEC SQL UPDATE ACCOUNT SET BALANCE :WS-NEW-BAL WHERE ACCT_NO :WS-ACCT-NO END-EXEC IF SQLCODE 0 DISPLAY UPDATE SUCCESS END-IF如果WHERE一条都没命中SQLCODE 依然是0。程序会认为更新成功了后续的对账、流水、通知全部按已更新往下走实际数据库里一个字节都没变。正确写法是紧跟着判断SQLERRD(3)IF SQLCODE 0 IF SQLERRD(3) 0 DISPLAY NO ROW UPDATED, KEY WS-ACCT-NO MOVE N TO WS-UPDATE-FLAG ELSE MOVE Y TO WS-UPDATE-FLAG END-IF END-IF4.2 几个高频返回码的实际含义100无数据。它在三个位置含义完全不同——单行 SELECT 里表示没查到FETCH 里表示游标取完了UPDATE/DELETE ... WHERE CURRENT OF里表示当前行已被别人删掉。三种情况要做三种处理不能统一PERFORM ERROR。-811单行 SELECT 返回了多行。前面说过这个在宽松配置下会退化成取第一行必须主动捕获并当作逻辑错误处理因为这意味着你的 WHERE 条件设计有问题。-305空值不能赋给宿主变量。说明你取了一个 NULL 列但没有配指示器变量这时候宿主变量的内容是未定义的可能是上次的残留值也可能是垃圾。看到这个码别急着加COALESCE了事先想清楚业务上 NULL 应该怎么表达。-304数值超出范围。典型场景是用PIC 9(4)去接一个五位数的列或者PIC S9(9) COMP去接超过了 21 亿的值。这种错误在老系统扩容时批量出现——业务量涨了原来四位的编号不够用了代码里所有 PIC 定义都得跟着改。-911/-913死锁或锁等待超时。这是并发问题的信号不是代码语法问题。看到这两个码第一反应应该是去查锁等待图看是谁在持锁而不是在代码里加RETRY循环硬扛。-501游标没打开就 FETCH。八成是COMMIT把游标关了回去检查WITH HOLD。-818时间戳冲突。包和程序版本对不上回去检查预编译、绑定、链接的顺序有没有断。4.3 事务边界在线交易和批处理是两套规则在线交易环境里事务边界通常由事务监控器统一管理。一个交易进来监控器开启事务程序处理返回时监控器统一提交或回滚。这种情况下程序里主动写 COMMIT 是非常危险的动作因为它会把监控器管理的事务提前切断后续如果出错回滚只能回到 COMMIT 那个点前面已经提交的部分撤不回来数据一致性直接崩掉。批处理环境则相反程序自己就是事务的主人。这里的经验值是提交间隔500 到 2000 条记录提交一次。太小了日志写盘次数多太大了日志空间不够用、回滚段压力大、重启点太靠前。重启点设计批处理必须能在中断后接着跑。常见做法是每批提交时更新一张控制表记录已处理到的最大主键重启时从这个值之后继续。这张控制表的更新必须和业务数据在同一个事务里否则会出现数据提交了但重启点没更新或者反过来的错位。保存点的使用局部可恢复的场景可以用SAVEPOINT出错回滚到保存点而不影响前面的批次。用的人不多但在处理一条记录有多个写操作、失败要整条回退的场景下很实用。5. 一次游标泄漏事故的完整排查链路这一段复盘一个我印象比较深的线上问题把前面说的机制串起来。问题现象是夜间批处理作业运行到中途开始变慢日志里每隔一段时间刷一批-911最后整个 JOB 挂住不动直到运维手动杀掉。5.1 现象与第一轮排查先看 JOBLOG 的 SQLCODE 分布。发现-911集中出现在某几个特定段落而且出现频率随着运行时间递增。再看数据库侧的活动会话发现有大量会话状态是UOW-EXECUTING都在等同一把锁锁的持有者是一个长时间运行的批处理会话。第一反应是找出谁在持锁。查下去发现持锁的是同一个作业自己的另一个游标——也就是说程序自己在跟自己抢锁。这就把方向锁定了游标的加锁范围超出了预期循环体里必然有地方让锁没有被及时释放。5.2 根因DECLARE 写在了循环里面翻代码问题段落的骨架是这样的PERFORM UNTIL WS-EOF-FLAG Y EXEC SQL DECLARE REV-CUR CURSOR WITH HOLD FOR SELECT ... FROM REVERSAL WHERE ... END-EXEC EXEC SQL OPEN REV-CUR END-EXEC EXEC SQL FETCH REV-CUR INTO :WS-REC END-EXEC IF SQLCODE 0 PERFORM 5000-PROCESS-ONE ELSE MOVE Y TO WS-EOF-FLAG END-IF EXEC SQL CLOSE REV-CUR END-EXEC END-PERFORM表面上 OPEN 和 CLOSE 是配对的看起来没问题。但这里有两个连锁反应一是WITH HOLD加在了这段游标上。WITH HOLD的语义是游标跨提交保持打开但同时也意味着在游标关闭之前它持有的锁不会因为提交而释放。这个游标在每轮循环里开了又关但关闭动作在异常分支里被跳过了——PERFORM 5000-PROCESS-ONE如果内部遇到错误直接GOBACK后面的CLOSE根本不执行。累积下来每次异常都漏掉一个游标锁越积越多。二是DECLARE写在循环里虽然预编译器在某些版本下允许但每次重新执行 OPEN 会用同一个游标名去申请新的资源命名空间冲突导致前面那个游标的句柄丢失想关也关不掉了。这属于典型的句柄泄漏。5.3 修复方案与验证办法改写思路四条DECLARE移到PROCEDURE DIVISION的最前面只声明一次。去掉不必要的WITH HOLD。这个游标是逐条处理、不跨提交的WITH HOLD只会延长锁持有时间纯属负优化。异常出口统一收口。把 GOBACK 全部改成PERFORM 9999-EXIT在9999-EXIT段落里统一判断游标状态并关闭。加一层运行期埋点每次 OPEN 和 CLOSE 都向日志写一行记录用计数器统计配平情况。验证方式很直接跑一轮完整批处理后从日志里统计 OPEN 次数和 CLOSE 次数两者必须相等。如果再出现不等说明还有别的异常出口没被收口。这个配平检查后来被固化进了上线检查清单凡是涉及游标的改动都要过一遍。提示凡是使用WITH HOLD的游标都要在代码注释里写明为什么这里需要跨提交保持并注明预期的关闭点。没有明确理由的WITH HOLD一律删掉。这条经验在很多次性能问题复盘里都成立。6. 让程序跑得快几条血泪换来的调优经验最后这一段讲性能。嵌入式 SQL 的性能问题有个特点代码上完全正确逻辑上完全站得住就是慢。慢的原因几乎都在看不到的地方——索引失效、类型转换、网络往返、锁竞争。6.1 隐式类型转换是索引的头号杀手看这条语句01 WS-CUST-ID PIC 9(08). EXEC SQL SELECT CUST_NAME INTO :WS-CUST-NAME FROM CUSTOMER WHERE CUST_ID :WS-CUST-ID END-EXEC如果CUSTOMER.CUST_ID列的类型是CHAR(8)而宿主变量是PIC 9(8)数字数据库在执行时要把两边的类型统一这个统一动作发生在列的一侧也就是对CUST_ID施加了函数转换索引直接失效全表扫描。解决办法只有一个宿主变量的类型必须和列的声明类型严格一致。列是CHAR(8)变量就是PIC X(8)列是DECIMAL(9,2)变量就是PIC S9(7)V99 COMP-3连符号位和位数都要对齐。这在重构老代码时工作量不小但收益立竿见影。同样的道理也适用于变量比列长和变量比列短两种情况。变量比列长取数时会补空格前面说过会污染比较变量比列短取数时会被截断SQLWARN1会被置位数据静默丢尾。两种都不报错但都是错的。6.2 批量取数数组 FETCH 与批次大小逐行 FETCH 的问题是每次都在网络上走一个来回。跨 LPAR、跨数据中心的时候单次往返可能是几百微秒乘以一千万行就是一个小时起步。解决办法是数组 FETCH一次取多行到 COBOL 的数组里然后在内存里遍历。01 WS-FETCH-SIZE PIC S9(4) COMP VALUE 500. 01 WS-ID-ARRAY. 05 WS-ID-ELEM PIC X(10) OCCURS 500 TIMES. 01 WS-NAME-ARRAY. 05 WS-NAME-ELEM PIC X(60) OCCURS 500 TIMES. EXEC SQL FETCH CUST-CUR INTO :WS-ID-ARRAY, :WS-NAME-ARRAY END-EXEC EVALUATE SQLCODE WHEN 0 MOVE WS-FETCH-SIZE TO WS-LOOP-CNT WHEN 100 MOVE 0 TO WS-LOOP-CNT WHEN OTHER PERFORM 9000-SQL-ERROR END-EVALUATE PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I WS-LOOP-CNT PERFORM 2100-HANDLE-ONE END-PERFORM批次大小怎么定我自己的经验是有个几百到一千行的甜点区。太小了往返次数降不下来太大了单次网络传输的数据量大、内存占用高而且一旦 SQLCODE 是 0 但实际只取到一半最后一批需要靠SQLERRD(3)判断实际取到了多少行。上代码里简化的MOVE WS-FETCH-SIZE TO WS-LOOP-CNT只在能整除的情况下成立实际生产代码必须处理尾批。6.3 把循环里的单条查询消灭掉这是最常见也最容易被放过的问题主查询取出一个列表然后对列表里每一条再发一次子查询。一千万行意味着多发一千万次查询哪怕每个都很小累计开销也能把整批处理拖垮。破法是把子查询改成关联一次取出EXEC SQL SELECT A.CUST_ID, A.CUST_NAME, B.LAST_ORDER_DT INTO :WS-CUST-ID, :WS-CUST-NAME, :WS-LAST-DT FROM CUSTOMER A LEFT JOIN ORDER_HDR B ON B.CUST_ID A.CUST_ID AND B.ORDER_DT (SELECT MAX(ORDER_DT) FROM ORDER_HDR C WHERE C.CUST_ID A.CUST_ID) WHERE A.STATUS A END-EXEC这种改写要注意的一点是LEFT JOIN和聚合子查询的组合在大数据量下执行计划可能不理想。上线前务必用EXPLAIN看看实际走的是不是索引嵌套循环或者哈希连接如果冒出全表扫描和临时排序宁可拆成先批量取出客户列表 → 再用IN列表批量查订单 → 在内存里做映射的两段式虽然代码长一点但可控性强得多。注意任何新写的多表关联都不要在没看过执行计划的情况下直接投产。跑一次EXPLAIN五秒钟的事能省掉后面几天的性能问题排查。6.4 锁的持有窗口比锁的粒度更重要前面反复提到锁这里做个总结。影响并发的不只是隔离级别和锁粒度锁的持有时间往往是决定性因素。三条实操原则循环体内部不做耗时的非数据库操作。写文件、调外呼、算复杂逻辑统统挪到循环外面或者挪到取数完成之后。游标的锁窗口从 OPEN 开始算到 CLOSE 结束。既然锁的持有时间和取数范围强相关就不要用一个大游标扫全表。按主键分段一段一段来既降低锁窗口也方便断点重启。在线交易里尽量把访问对象的顺序统一。同一个交易流程里先访问 A 表再访问 B 表所有并发交易都保持这个顺序能规避掉绝大部分死锁。死锁的本质是环环的成因是顺序不一致。7. 几句实操层面的补充嵌入式 SQL 这块的知识点书本上讲的都是语法真正难的是那些不报错但结果不对的情形。我自己踩得最多的三类前面都覆盖到了宿主变量的类型与长度对齐、指示器的使用、返回码的分支处理。这三块如果一开始就建立正确习惯后面的项目能少走很多弯路。再补充一个工作习惯上的建议新写的 SQL 段先在交互式环境里手工跑一遍确认语句本身返回的结果和行数是符合预期的再嵌进 COBOL 里。很多人一上来就在程序里调出了错分不清是 SQL 写错了还是宿主变量绑错了来回折腾半天。先在数据库客户端验证 SQL 逻辑再验证 COBOL 侧的数据搬运两段分开定位效率差好几倍。还有个细节批处理程序建议在开场和收场各打一条带时间戳的日志在循环里每处理 N 条打一条进度日志。看起来是小事但夜间作业出问题时这两条日志能让你在一分钟内判断是卡在取数还是卡在写库省下的排查时间远超过写日志的成本。这是纯经验性的东西文档里不会写但实际干活的时候特别管用。
