ORA-18173报错导致FTST0014评分计算受限，远程协助解决故障全过程分享

那天下午，我们团队接到业务部门的紧急电话，说一个非常重要的学生评分计算程序FTST0014卡住了，无法正常产出结果，这个程序每周运行一次，计算出的分数直接关系到后续的奖学金评定，时间非常紧迫，我们立刻响应,开始了远程排查。

我通过远程桌面连接到了负责运行这批任务的应用服务器，查看了程序的日志文件后，发现了一个关键的错误信息，日志里明确记录着“ORA-18173: 快照太旧”，这个错误是数据库那边抛出来的，意味着我们的程序在向数据库请求某个时间点的数据快照时，数据库说这个快照已经过期了,无法提供。

问题定位到了数据库层面，我紧接着联系了数据库管理员（DBA）同事，向他说明了情况，DBA同事非常给力，他立刻登录到Oracle数据库服务器进行检查，他解释说，ORA-18173错误通常与数据库的“撤销表空间”有关，他打了个比方：数据库为了保证数据的一致性，当某个查询需要读取一个较早时间点的数据时，它会去一个叫“撤销表空间”的地方找旧数据，就像看一本书的旧版本，但如果这个“旧书库”空间太小，或者保存旧版本的时间设置得太短，那么很早的旧版本就会被清理掉，导致查询时找不到，于是就报“快照太旧”的错误。

根据DBA的分析，他重点检查了两个地方：首先是撤销表空间的当前大小和使用率，发现确实已经快满了；其次是数据库的一个关键参数“UNDO_RETENTION”，这个参数规定了数据库应该尽力将旧数据（撤销信息）保留多长时间，检查后发现，这个保留时间设置得相对较短，只有900秒（15分钟），而我们的FTST0014评分计算程序是一个复杂的批量处理任务，运行时间可能超过半小时，并且在程序内部的不同步骤中，需要多次查询数据库，并期望这些查询看到的数据是一致的（即基于程序开始时的那个数据状态），当程序运行到后半段，再去请求程序开始时那个状态的数据时，由于保留时间已过，相关的撤销信息很可能已经被后续的其他事务覆盖了，因此数据库无法满足这个请求，抛出了ORA-18173错误。

原因找到了，解决方案就清晰了，DBA同事采取了双管齐下的办法：他紧急扩大了撤销表空间的容量，为存储更多的旧数据提供了“物理空间”；他将UNDO_RETENTION参数调整到了一个更合理的值，例如增加到10800秒（3小时），确保像FTST0014这样运行时间较长的关键任务在整个执行期间，其所需的数据快照都能被保留下来,不会被过早清除。

参数修改完成后，DBA通知我环境已经就绪，我这边清空了程序之前的错误状态，重新在应用服务器上提交了FTST0014评分计算任务，我们所有人都紧张地盯着日志输出，这一次，程序顺利地一步步执行下去，之前报错的那个环节安然度过，大约40分钟后，日志最终显示“处理成功完成”，我们立刻通知业务部门进行验证，确认评分结果已经准确生成,所有数据正常。

这次远程协助解决故障的过程，虽然紧张但很有章法，它提醒我们，对于运行时间较长的批处理任务，不能只关注应用本身的代码逻辑，还需要充分考虑底层数据库的配置是否能够支撑其运行，特别是像撤销表空间这类维护数据一致性和读写并发的基础设施，其参数设置需要与业务的峰值操作和长事务特点相匹配，这次经历也加强了我们在处理跨系统问题时的团队协作能力,应用支持和数据库管理员的紧密配合是快速定位和解决此类复合型问题的关键。