故障排查

一次单据复制请求被数据库自定义错误拒绝。提示指向库存质量不允许使用，但现场库存有足够实物数量，质量属性也处于允许状态。

数据库仍然掌握了拒绝写入的有效依据。可用量由实物数量减去已分配数量得到，而两层冗余计数都显示全部数量已经分配。权威预留记录中却找不到对应业务明细。触发器因此计算出可用量为零，并执行了既有业务约束。

本次处理保留了这条约束，在并发保护下修复幽灵占用，同时调整应用边界：多行复制失败时先完成事务回滚，再把数据库错误转换为用户可读的业务提示。

把数据库拒绝当作证据

排查先定位中止事务的具体语句和业务约束。复制流程已经准备好新表头，写入明细时触发数据库检查。检查会计算满足质量条件且尚未 …

新增业务记录时，数据库在主键处返回了 ORA-00001。这看起来不合常理，因为应用的主键来自 Oracle 序列。日志却给出了明确解释：本次生成的数值已经属于迁移进来的历史记录。

故障来自迁移后两个必须同步的对象发生漂移：表中的数据已经前进，负责生成后续主键的序列却仍描述旧历史。另一个独立写入流程也出现了相同故障，同时说明只修复第一个失败表并不安全。

Oracle 把 ORA-00001 定义为 INSERT、UPDATE 或 MERGE 试图写入受唯一约束、唯一索引或主键保护的重复值（Oracle ORA-00001）。第一步应确定：

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

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

有效的执行链是：

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

IDE 已经完成编译和产物准备，应用服务器却没有进入部署。真正中断启动的是调试器监听器绑定失败：配置的地址无法绑定，日志提示该地址已被使用。

常见判断是“另一个进程占用了端口”。本次现场却出现了一个容易误导排查的现象：稍后检查时，没有普通进程在监听；Windows 返回的排除 TCP 端口区间却包含这个配置值。只修改调试端口后，完整启动链路恢复。

这说明 Windows 上的固定开发监听器不能只做进程占用检查，还要避开机器当前的动态分配范围和显式排除区间。

IDE 启动应用服务器时，会依次跨过多个边界：

编译源码
  -> 构建产物
  -> 绑定调试套接字 …

一条临时媒体 URL 在某个客户端返回 HTTP 403，媒体对象本身仍然存在。这条 URL 来自一次播放请求，随后被复制到原网络路径之外继续使用。同一段文本的重试结果并不稳定：一个路径失败，另一个受控路径仍能读取对象。

线索来自 URL 内嵌的授权上下文。查询参数中同时出现过期时间和客户端地址，并且这两个字段都位于签名参数清单中。相关域名的请求还经过了不同的公网代理出口。因此，这条 URL 表示特定请求上下文中的短期授权，无法充当持久媒体身份。

这个案例给出了一套签名 URL 403 的排查顺序：分别检查时间、网络路径、重定向和请求方法；原上下文无法安全复现时，从稳定的页面或 API 身份重 …

一个桌面任务存储在归档近期任务时持续返回“找不到文件”。会话内容仍可读取，源文件确实存在，状态数据库的完整性检查也正常；重复调用归档接口，结果没有变化。

排查线索落在路径身份上。部分旧记录保存的是物理存储根目录，当前应用则统一从逻辑主目录访问数据。目录链接让两种写法都能读到同一份字节，但归档事务没有把它们视为可互换的路径。

这个案例说明，“文件存在”只覆盖了路径故障的一部分。持久化路径身份与应用当前使用的根目录发生漂移，同样会让有状态事务失败。

界面报错可能来自源文件丢失、权限不足、数据库损坏或路径过期。任何修复之前，先用只读检查缩小范围：