回忆录：多年前六 月的一个清晨，我们 DBA 技术团队的监控告警群突然弹出客户业务系统的紧急通知 —— 核心 ERP 的报表模块批量报错，屏幕上密集刷新着 "ORA-00904: "WMSYS"."WM_CONCAT": invalid identifier" 的红色警告。作为负责客户 Oracle 数据库升级项目的第三方团队，我们心里立刻绷紧了弦：上周刚完成从 11g 到 12c 的版本迁移，问题大概率出在这上面。
登录客户的生产数据库控制台，团队的资深 DBA 率先敲下核查命令： `select * from v$version;` ，返回结果清晰显示 "Oracle Database 12c Enterprise Edition Release 12.2.0.1.0"—— 升级确实成功了。紧接着，我们调取了报错的业务 SQL ： `SELECT deptno, wmsys.wm_concat(ename) nameslist FROM scott.emp GROUP BY deptno;` ，执行后同样触发 ORA-00904 错误，印证了猜想：问题就出在这个函数上。
团队迅速召开线上会诊。小组成员翻出 Oracle 12c 的官方文档，指着其中一段念道： " 从 12c 开始， WMSYS.WM_CONCAT 函数不再作为内置函数提供，官方建议使用 LISTAGG 替代，但考虑到旧系统兼容性，可手动重建该函数。 " 客户的这套 ERP 系统运行了八年，大量存储过程和业务 SQL 都依赖 WM_CONCAT 进行字符串聚合，直接替换显然不现实 —— 当务之急是让这个函数在 12c 环境里 " 复活 " 。
作为第三方服务团队，我们深知生产环境操作的风险。 " 先在测试环境复现，验证方案可行性。 " 团队负责人当即拍板。我们立刻协调客户开通测试环境权限，按生产配置复刻了 12c 升级后的环境：同样的版本、相同的业务表结构，甚至同步了部分测试数据。在测试库中运行报错 SQL ，果然复现了相同的问题，这让我们确认了问题的普遍性。
接下来是重建函数的关键步骤。我们从 Oracle官方归档中获取了必要的安装包 wm_concat.zip。上传至测试服务器的/tmp 目录后，特意执行 `chown oracle:oinstall /tmp/*.plb` 确保权限正确 —— 这是第三方团队操作客户环境的基本规范，任何权限疏忽都可能引发新的故障。
登录测试库的 sysdba 账号，团队按顺序执行脚本：
SQL>@/tmp/owmctab.plb;
SQL>@/tmp/owmaggrs.plb;
SQL>@/tmp/owmaggrb.plb;
脚本执行过程无报错，进度条走完后，再次运行那个聚合查询， deptno 对应的 ename 列表顺利合并成字符串 —— 函数重建成功了！我们又跑了客户提供的 20 多个依赖该函数的存储过程，全部执行通过，测试环境验证通过。
随后，我们向客户提交了《生产环境变更方案》，明确说明需要业务停机 2 小时，详细列出操作步骤、回滚预案和风险评估。客户运维团队确认后，我们将操作时间定在了周末凌晨 —— 这是第三方团队为减少业务影响的常规选择。
变更当晚，团队三人分工协作：一人负责上传安装包并校验权限，一人执行脚本并记录输出日志，一人实时监控数据库状态。当三个脚本成功执行完毕，验证业务 SQL 返回正确结果时，距离预定停机时间还剩 40 分钟。客户运维负责人在电话里连说 " 专业 " ，我们知道，这是对第三方团队规范流程的最好认可。
周一客户业务系统正常启动，报表模块再无报错。复盘会上，团队总结：作为第三方 DBA ，面对版本升级这类操作，不仅要懂技术，更要懂客户的业务依赖 —— 那些被官方废弃的旧功能，往往藏着客户系统的 " 隐形支柱 " ，而我们的价值，就是在新旧交替中搭好平稳过渡的桥梁。
