Oracle 19c 中用确定性 LISTAGG 替换 WM_CONCAT

浏览器请求返回了 HTTP 200，响应体却是空的，页面也没有数据。状态码看起来成功，后端日志却给出了另一条链路：映射 SQL 在调用 WM_CONCAT 时触发了 ORA-00904。

这次修复不能只做全局文本替换。字符串聚合包含排序、重复值、分隔符、别名和溢出语义。安全迁移到 Oracle 19c，需要逐项保留这些契约，证明运行时产物已经同步变化，并把“源码与数据库验证完成”和“部署后页面已恢复”严格分开。

从第一个失败边界开始

有效的执行链是：

HTTP 200 空响应
  -> 异常被捕获
  -> 映射 SQL 失败
  -> ORA-00904: WM_CONCAT

Oracle 把 ORA-00904 定义为无效的标识符或列名（ORA-00904）。在本次运行中，无效标识符就是遗留聚合函数本身；目标 Oracle 19c 数据库无法识别它。

这一区分很关键。空响应并不代表查询正常返回了零行，而是应用异常处理产生的次生表现。数据库错误是最早失败的边界，也应当成为修复入口。

修改前先找全调用范围

第一次搜索找到了大部分调用，却不是全部。改用不区分大小写的扫描后，又发现三种大小写变体。最终清单覆盖十一份 XML 查询映射。

修改前的记录至少应包含：

• 文件与查询标识；
• 被拼接的表达式；
• 分隔符；
• 应用代码读取的结果别名；
• 分组列与过滤条件；
• 输出需要遵循的顺序；
• 重复值是否具有业务含义；
• 是否存在必须保持位置对齐的并行聚合。

这份清单可以防止机械替换悄悄改变查询契约，也为修改后的扫描提供精确预期范围。

替换语法，同时保留语义

采用的替换结构是：

LISTAGG(
  value_expression,
  ','
) WITHIN GROUP (
  ORDER BY stable_key
)

Oracle 文档说明，LISTAGG 会在组内按 ORDER BY 排序后拼接度量表达式；只有排序列能够形成唯一顺序时，结果才是确定性的（Oracle 19c LISTAGG）。

因此，迁移遵循五项约束。

1. 保留分隔符。 现有消费者依赖逗号分隔格式，替换后继续使用逗号。
2. 不擅自增加 DISTINCT。 原查询没有要求去重；删除重复项会改变可见数据。
3. 选择稳定顺序。 每个聚合沿用已经定义行顺序的业务键。如果单个键不唯一，应增加有记录的次级排序键，不能依赖数据库取数顺序。
4. 对齐并行列表。 同一查询若同时返回名称列表和编码列表，两者必须使用相同排序键，否则相同位置可能描述不同记录。
5. 保留别名和过滤。 应用仍通过旧别名读取结果，原来的 WHERE 与 GROUP BY 逻辑也是查询契约的一部分。

只有在能够证明外层字符转换不再改变 LISTAGG 结果类型时，才删除冗余转换；它不是迁移的必选动作。

把溢出当成数据契约，而不是语法细节

字符输入下，LISTAGG 返回 VARCHAR2。Oracle 19c 文档记录：MAX_STRING_SIZE=STANDARD 时上限为 4,000 字节，EXTENDED 时为 32,767 字节。默认溢出行为是 ON OVERFLOW ERROR，会触发 ORA-01489；ON OVERFLOW TRUNCATE 则会明确返回不完整列表（Oracle 19c LISTAGG）。

本次修复没有加入截断。被截断的标识或名称列表可能错误表达业务数据，却让查询表面上继续成功。更安全的策略是：

• 在目标数据库上用 LENGTHB 测量代表性分组结果；
• 把最大值与当前环境的真实上限比较；
• 保持溢出时故障关闭；
• 如果未来数据增长逼近上限，再重新设计输出，或建立经过明确批准的截断契约。

Oracle 的 19c 教程同时演示了 ORA-01489 和显式截断选项（避免 LISTAGG 溢出）。因此，这个选择会改变应用可观察行为，不是单纯的 SQL 美化。

分别验证源码、构建、产物和数据库

每一层能发现的错误不同，所以本次没有用一次构建代替全部验证。

源码与 XML

• 不区分大小写扫描后，WM_CONCAT 剩余数量为零。
• 十一份受影响文件中共有 42 个预期 LISTAGG 表达式。
• 每一份修改后的映射文件都能通过 XML 解析。

构建

所需多模块应用链使用隔离的 JDK 8 工具链完成编译。另一个不在目标产物必需路径内的历史模块，仍存在原有依赖问题；它的映射 XML 与 SQL 已检查，但没有把这项无关问题描述成“本次已修复并可单独构建”。

打包产物

最终应用包经过递归扫描，而不是只相信源码目录。在 935 个内嵌 XML 条目中，没有运行时 WM_CONCAT 引用，并找到了预期的 LISTAGG 表达式。源码数量与产物数量不同，是因为并非每个源码映射都会进入选定产物。

Oracle 19c

代表性查询在脱敏的 Oracle 19c 测试数据库执行。它们没有再触发 ORA-00904，没有触发 ORA-01489，实测字节长度也低于当前配置上限。

这些证据共同证明兼容性已经跨过数据库与打包产物边界，但不能证明部署后的页面已经健康。

不把部署写进已完成结论

本次工作没有部署修复后的产物。后续发布仍要在部署完成后检查真实页面、响应体、日志流和代表性数据。

因此，准确结论是：受影响源码和打包运行时中的遗留聚合已经清除；替换保留了已审阅的查询语义；所需构建完成；代表性 Oracle 19c 查询通过标识符与溢出检查。生产页面恢复仍是独立验收步骤。

这个边界与 SQL 修改本身同样重要。它能防止把一次成功编译误报成一次成功发布。