ORA-20001: Latest xml inventory is not loaded into table这行红字第一次出现在并发请求日志里时我的第一反应是“数据库出bug了”。后来翻遍官方错误码都没找到直接解释才发现问题出在 Oracle EBS 的补丁应用流程上。这个报错是 EBS 内的 XML Publisher也就是后来的 BI Publisher组件在启动校验时主动抛出的自定义错误明摆着告诉你库存表里的 XML 清单没跟上文件系统的实际版本。如果你是 EBS 的运维 DBA、应用管理员或者负责给 EBS 打补丁、做克隆刷库这篇复盘应该能帮你少走很大一段弯路。1. 报错现场的典型场景EBS 里的“不认账”时刻1.1 这行红字到底是谁抛出来的ORA-20001 这个错误码本身没什么好查的它属于 Oracle 为应用开发者预留的自定义错误段。开发者在 PL/SQL 里调用RAISE_APPLICATION_ERROR(-20001, Latest xml inventory is not loaded into table)就可以主动把业务异常抛给前端或并发管理器。换句话说这行报错不是数据库底层崩溃而是 EBS 应用代码自己在做一致性检查时发现“对不上账”了。字面意思很清楚最新版的 xml inventory 没有被装载到表里。这里的“表”就是xmlp_inventory表。EBS 启动 XML Publisher 相关功能时会去这张表里读取当前登记的 XML 资源清单和版本信息。如果表里的版本和文件系统里实际存放的版本不一致或者表里压根没有最新记录应用就会直接拒绝继续工作而不是“少点什么也能凑合用”。这点很关键报错说的是“最新库存未加载”不是“文件丢失”。往往文件系统里已经躺着一堆最新的 XML 模板和样式文件缺的只是登记动作。所以解决问题的思路应该放在“把库存这张账补上”而不是去重新装软件。1.2 印象最深的三类现场第一次遇到这种报错是在给一套 11.5.10 的环境应用 XMLP 相关补丁时。AutoPatch 显示补丁应用完毕按 README 要求重启了应用和数据库服务结果业务人员一提交 XML Publisher 报表就报 ORA-20001。后来查日志才发现补丁明明包含了“更新 XML Publisher inventory”这个步骤但当时 AutoPatch 由于中途有人误操作退出过一次导致这个任务从未真正执行完。第二类场景和克隆刷库有关。快速克隆完成之后目标环境跑 XML Publisher 报表偶尔也报同样的错。原因不难想克隆复制了源库的xmlp_inventory数据但目标环境的文件系统是在不同时间点构建的两边版本可能对不上。尤其是源库在克隆之后又打过补丁或者克隆后直接在目标端升级了中间层都会加重这种不一致。第三类场景是人为改表。有些同行看到这个报错第一反应是“表坏了”于是备份后直接 delete 掉xmlp_inventory里的记录或者手动 update 一条高版本号进去。这种做法极大概率会引发更诡异的问题因为你改表的时候文件系统里的版本标识并没有同步改应用的下一次校验同样过不去而且由于原始记录已经没了连排查的参照系都被你亲手毁掉了。1.3 它会影响哪些功能凡是要和 XML Publisher 打交道的前台功能都可能受牵连。最典型的是报表请求在“XML Publisher 报表队列”里提交一个并发请求状态会直接变成 Error日志里就是那行 ORA-20001。BI Publisher 管理页面、部分审计报表生成、以及契约管理里的文档生成流程在调用 XML 发布组件时也可能出现类似错误。值得注意的是普通业务单据查询通常不受影响因为那些流程走的是 ERP 自身的业务模块没到 XMLP 这一层。所以你会看到一个很分裂的现象核心业务都正常偏偏所有和“报表模板”“XML 导出”沾边的功能集体罢工。这种“又好又快但一头包”的状态很容易让初次接触的人误判断是并发管理器配置出了问题。2. xmlp_inventory 的“账本”机制库存表到底在记什么2.1 文件系统是书架表是目录卡片XML Publisher 的组件不完全是存在表里的很大一部分是文件系统里的实体文件比如 XSL 样式表、RTF 模板的辅助文件、XSD 结构定义等。EBS 在运行过程中需要知道这些文件是否存在、版本是多少于是就用xmlp_inventory表做了一份“目录卡片”。把这个机制想象成一个小型图书馆补丁包里的新书被搬进了书架图书馆管理员必须同时更新目录卡否则读者来查目录时找不到新书甚至系统会认为这本书不存在。EBS 的 XMLP 组件也一样它在启动阶段会做一次“账实核对”核对方法就是去xmlp_inventory表里找最新版本。表里没有或者版本落后应用直接抛出 ORA-20001。这个比对逻辑通常发生在补丁安装后第一轮组件调用时。所以很多时候补丁打完了当天没人用报表功能一切风平浪静等到第二天大家上班一提交报表报错就像潮水一样涌出来了。2.2 核心表结构与典型内容不同版本的 EBS 里这张表的字段可能略有差异但核心列基本一致。我习惯用这个查询快速看账SELECT file_id, application_id, file_name, version, last_update_date FROM xmlp_inventory WHERE ROWNUM 20 ORDER BY last_update_date DESC;常见字段含义大致如下字段含义典型示例file_id文件唯一编号67324application_id所属应用编号630XML Publisher 常见值file_name登记的文件名xdo/xsl/des/xxrep.xslversion该文件在系统中的版本标识12.0.0.0.0last_update_date登记时间2024-06-18 10:23:45实际执行时你会看到类似这样的输出FILE_ID APPLICATION_ID FILE_NAME VERSION LAST_UPDATE_DATE ---------- ------------- ------------------------------ -------------- ------------------- 67324 630 xdo/xsl/des/xxrep.xsl 12.0.0.0.0 2024-06-18 10:23:45 67325 630 xdo/xsl/des/xxsec.xsl 12.0.0.0.0 2024-06-18 10:23:45 67326 630 xdo/xsl/des/xxstr.xsl 12.0.0.0.0 2024-06-18 10:23:45看着好像全是版本号其实这张表的价值不只是给人看的。应用启动时真正关心的是最近有没有一条“足够新”的清单记录。只要最新记录的版本号与当前补丁级别匹配校验就通过否则就认为“最新 inventory 未加载”。2.3 版本比较的规则不是比大小很多初次接触的人容易误解版本号越大就越新呗。实际上 EBS 的 XMLP 库存校验通常不是把version转换成数字再比大小而是对照补丁包内携带的版本标记做精确匹配或前缀匹配。你的文件系统里如果有一套更高版本的 XSL 文件但表里登记的版本不在应用的“白名单”里系统照样不认。这个设计是有道理的。补丁之间不一定完全线性迭代不同分支的版本可能各自维护。单纯按数字比较大小很容易出现“文件系统比表里新太多”的误判。所以 EBS 的做法更像是检查我当前代码版本依赖的这一批 XML 资源是否已经被登记到库存表中。补丁安装时会有一个专门的脚本负责把该次补丁所需的文件清单写进表里。脚本没跑或者跑挂了后续一切校验都会失败。这也解释了为什么“手工 update 一条高版本号”没有用。你只是改了目录卡片上的数字没有让卡片内容和真正的书目体系对应起来。应用一核对发现这是张来路不明的卡片照样拒绝放行。2.4 报错从哪个包来并不重要重要的是定位触发点如果你拿到一份跟踪文件可能会看到类似这样的调用栈ORA-20001: Latest xml inventory is not loaded into table ORA-06512: at APPS.XDP_INVENTORY_PKG, line 123 ORA-06512: at APPS.FND_CP_PXXXX, line 456不同版本里包名不一定相同别死记这个示例。我想说的是这个报错的定位价值不在“哪个函数抛出来的”而在于它自己把原因写得很清楚了库存表没有被更新到最新。看到跟踪文件里带出 XDP 或 XMLP 相关包名时就可以顺着补丁流程去查该跑的步骤有没有跑完。有一种情况要特别注意如果跟踪文件里根本不是 XDP/XMLP 相关包而是 FND 基础包抛出来的那就要重新审视环境是不是缺少共享库存目录或者多节点环境的文件系统不一致。这种场景在 RAC 多节点加多应用服务器时偶尔出现后文会展开说。3. 排查链路从日志到表数据一次完整的定位过程3.1 第 0 步把日志准确翻出来遇到这种报错先别急着上 SQL。你需要确认错误是从哪个进程里出来的。并发管理器报的错就去并发请求详情里找日志文件如果是在应用服务器页面上弹的 ORA-20001就去对应的应用日志目录翻。EBS 各版本日志路径不完全一样常见的是应用安装目录下的admin/log子目录或者$INST_TOP/logs下的相关文件。我一般会先把这个命令跑一遍快速定位最近的并发请求日志find $LOG_HOME -name *.log -newermt 2024-06-01 -type f然后直接看这次失败请求的日志主文件。里面该有类似这样的片段ERROR ORA-20001: Latest xml inventory is not loaded into table ORA-06512: at APPS.XDP_INVENTORY_PKG, line 123拿到这个堆栈意味着你在排查路径上已经锁定“XMLP 库存校验”这一步了。下一步就是比较表和文件系统的账。3.2 第 1 步查 XML 产品的安装状态XML Publisher 在 EBS 的“产品安装表”里也有一笔台账可以通过这个标准表快速看到产品的基本状态SELECT fa.application_short_name, pi.application_id, pi.status, pi.patch_level, pi.last_update_date FROM fnd_product_installations pi, fnd_application fa WHERE fa.application_id pi.application_id AND fa.application_short_name XML;正常情况下结果里应该有一条记录状态为IInstalledpatch_level应该和你最近一次应用补丁的级别对得上。如果这条记录本身就不存在或者patch_level明显偏旧那么问题可能要追溯到产品安装步骤而不只是 inventory 表。我见过一种情况补丁包确实包含了 XMLP 组件但 README 要求先运行某个前置脚本把 XML 产品注册表状态更新到新级别。运维跳过了这步导致 AutoPatch 虽然报告完成产品状态却是陈旧的。到了系统启动时组件校验发现自己“没被正确升级”自然就抛 ORA-20001。3.3 第 2 步对照文件系统实际版本接下来同时做两件事查表查文件系统。查表的 SQL 前文已经给过了。查文件系统我习惯这样做ls -l $XMLP_TOP/admin/sql也可以直接用 grep 在相关目录里搜版本标记grep -r version $XMLP_TOP/admin/sql --include*.sql | head -20这么做不是为了精确定位每个文件的版本而是为了确认文件系统的 XMLP 目录里确实已经有新补丁放进去的文件。如果文件全是老时间、老版本那就说明补丁在文件复制阶段就出问题了问题不在 inventory 表反之如果文件系统里已经有最新文件而表里登记的last_update_date或version还是旧的那“账实不符”的根源就坐实了。为了更直观我习惯把表和文件系统信息并排看。比如表里file_name xdo/xsl/des/xxrep.xsl的版本是12.0.0.0.0但文件系统里同名文件的修改时间戳是补丁应用当天且补丁 README 标注的 XMLP 版本是12.0.1.0.0。这就非常清楚地说明文件已经到位登记步骤没执行完整。3.4 第 3 步回补丁日志里找“没跑完的任务”确定是登记步骤缺失后下一步就是回到补丁日志里确认具体原因。常见的补丁日志目录包括$PATCH_TOP/log和$INST_TOP/logs。我用这几个关键词去翻grep -i xml.*inventory $PATCH_TOP/log/*.log grep -i update.*xmlp $PATCH_TOP/log/*.log grep -i adadmin $PATCH_TOP/log/*.log补丁日志里如果出现了 “Skipped”“Not executed” 之类的状态基本就能定位到那个被跳过的任务。还有一种情况是 AutoPatch 在执行到一半时由于超时或者人工干预中断退出重进补丁会话时没有选择“从断点继续”导致后半段任务被标记为已完成或干脆没执行。如果日志表明这个任务压根没出现在补丁动作清单里那就要再回头翻 README。有些 XMLP 相关维护步骤不在 AutoPatch 的标准动作里而是要求 DBA 在补丁结束后自行运行一个独立脚本或 adadmin 菜单选项。README 里那段 “Post-Installation” 经常被人忽略而这恰恰是 ORA-20001 的温床。3.5 第 4 步区分三种“账实不符”排查到最后通常归到以下三类类型表现修复方向漏加载表里根本没有对应最新文件记录执行 inventory 同步脚本或标准菜单加载滞后表里有记录但版本和文件系统不一致重新执行补丁中的 inventory 更新步骤人为破坏记录被 update/delete 过无从比对从备份恢复表或重新执行完整补丁流程前两类处理起来相对干净第三类最头痛。因为一旦原始记录被改过你和文件系统之间的参照系就破坏了靠猜版本号几乎不可能安全修复。最稳妥的办法是从补丁安装前的导出备份或克隆源里把xmlp_inventory表恢复出来再重新执行同步脚本。4. 修复与预防把账本补上4.1 方法一用 AutoPatch 继续完成未跑完的任务如果已经确认是某个补丁的 inventory 更新步骤没执行完最推荐的办法是回到 AutoPatch 继续跑。重新进入 AutoPatch加载同一个补丁目录文件它会自动检查哪些任务已经完成、哪些没完成然后只补跑缺失的部分。这个机制很成熟不用太担心重复执行造成混乱。具体操作方式取决于你用的是交互模式还是非交互模式cd $PATCH_TOP adpatch进入菜单后选择适合的补丁路径AutoPatch 会询问是否继续未完成的任务选 yes 即可。如果不确定当时用的补丁文件名最好去旧的 adpatch 日志里翻一下把$PATCH_TOP的路径找对。有一个细节值得提如果补丁文件已经被清理掉或者节点已经拆了那 AutoPatch 继续执行这条路就走不通了。这时候别硬编一个补丁名进去改用下面的 adadmin 菜单方案。4.2 方法二用 adadmin 的 “Maintain Applications Files” 菜单对于大部分 EBS 11i 和 R12 环境adadmin 提供了一个维护文件库存的入口。具体菜单名称在不同版本之间略有差异常见的是“Maintain Applications Files”下的“Update XML Publisher inventory”选项也有版本直接放在“Reload Oracle Applications Inventory”里。操作步骤大致如下切换到 applmgr 系统用户source 环境变量。执行adadmin选择当前维护状态对应的上下文文件。在主菜单中找到“Maintain Applications Files”相关选项。选择“Update XML Publisher inventory”按提示输入 apps 用户密码。等待脚本扫描文件系统并更新表数据。这么做比手动跑脚本安全因为 adadmin 会尝试把文件系统扫描结果和补丁安装历史对齐不是简单地向表里插几条记录。我在 R12.1 和 R12.2 上都试过基本能覆盖绝大多数的版本不一致场景。如果菜单里找不到这个选项也别强行找。不同版本功能摆的地方不一样有些版本的 XMLP inventory 同步被抽出来作为独立脚本发布那种情况下就直接跳到手动脚本方案。4.3 方法三手动执行 inventory 脚本有些场景不适合走交互菜单比如你在写自动化脚本、或者环境里 adadmin 真的没有那个选项。这时可以定位 XMLP 的 inventory 脚本手动执行。先找到脚本文件。不同版本里脚本名可能略有差异常见的是xmlpInventory.sql或类似的 naming 风格。你可以用文件名模糊搜索ls -l $XMLP_TOP/admin/sql | grep -i -E invent|xmlp一旦确认脚本位置先用 apps 用户登录 SQL*Plus按环境实际情况设置 SIDsqlplus apps/apps$ORACLE_SID $XMLP_TOP/admin/sql/xmlpInventory.sql执行前我强烈建议先做一次备份。数据库大的话不需要整库备份只需要把这极小的一张表导出成临时表就行CREATE TABLE xmlp_inventory_backup_2024 AS SELECT * FROM xmlp_inventory;这样做的好处是万一脚本执行到一半因为权限或空间问题中断你还能把账目恢复原状不至于让环境处于中间态。脚本执行完成后回到 SQL*Plus 里验证一下最新记录SELECT MAX(last_update_date) AS latest_load_date FROM xmlp_inventory;如果显示的时间是刚才那几分钟说明清单已经重新加载过一轮了。4.4 修复后的验证清单修复完不能光看表里多了几条记录必须回到业务路径验证。我建议按下述顺序检查再次查询fnd_product_installations确认 XML 产品状态和补丁级别正确。在应用层重新提交一个之前失败的 XML Publisher 并发请求观察是否从 Error 变成 Success。若无前台请求可测找一个 XML Publisher 管理页面直接打开确认不再弹 ORA-20001。检查应用服务器日志确认没有新的xmlp_inventory相关错误堆栈。如果以上都能通过说明账本已经补上故障可以关闭。如果问题依然存在那就要回头检查是不是多节点环境节点间文件系统不一致或者应用服务器上的文件系统本身没更新成功。多节点环境里光在一个节点跑 inventory 同步是不够的其它节点的文件系统如果版本落后下次调用还会报错。这种情况要确保所有应用节点的 XMLP 文件都更新到相同版本再选择任一节点执行一次同步。4.5 预防策略以后补丁别漏这几步补丁操作最怕的就是“看起来成功”。这种报错的预防其实不难核心就一句话认真读 READMEPOST 安装步骤一个都不能省。我的习惯是任何涉及 XML Publisher 或 BI Publisher 的补丁无论在测试还是生产都会做下面几件事打补丁前把xmlp_inventory的条目数和last_update_date记录下来作为变更前基线。补丁执行完毕后主动运行一次 XMLP inventory 同步不等到业务报错才动手。在变更记录单里明确写出“XMLP inventory 已更新到 XX 版本”方便后续刷库时对照。如果是克隆环境目标端环境配置完成后主动执行一次 adadmin 的 inventory 更新不依赖源库数据。做到这几点基本可以把这个 ORA-20001 挡在正式上线之前。5. 写在最后一个老运维的处置习惯我在第一次遇到这个报错时也走过弯路。当时第一反应是去查 Oracle 官方技术库里的 ORA-20001 错误码结果自然一无所获因为这是 EBS 内部业务逻辑主动抛出的自定义消息。后来静下心把补丁流程从头捋了一遍才发现是 AutoPatch 中途退出后没续跑导致的。这些年下来我的最大体会是遇到这种带“Latest ... is not loaded into table”字样的报错别急着去动表先把它当成一个“流程未完成”的信号。正常业务表一般不会因为版本不匹配而拒绝工作它会拒绝恰恰说明有一套严谨的登记机制被跳过了。另外千万别尝试通过手工 delete 或 updatexmlp_inventory来“修数据”。我见过最惨的一个案例同事为了快速恢复把所有库存记录删除了三分之一最后补丁重跑都救不回来只能从备份单独恢复这张表。一旦库存账本失去完整性后续的 XML Publisher 相关模块会连锁出现各种来源报错那种场景远比今天的 ORA-20001 难收场。如果你现在正被这个报错折腾建议先把补丁日志和xmlp_inventory的最新记录时间对一下如果时间对不上大概率就是补丁步骤缺失重跑一次同步就能解决。如果时间能对上再往多节点文件系统一致性和产品安装状态方向查。把这个顺序记在心里下次再看到那行红字你就能比第一次从容很多。
Oracle EBS报错ORA-20001：XML Publisher库存未加载的排查与修复
ORA-20001: Latest xml inventory is not loaded into table这行红字第一次出现在并发请求日志里时我的第一反应是“数据库出bug了”。后来翻遍官方错误码都没找到直接解释才发现问题出在 Oracle EBS 的补丁应用流程上。这个报错是 EBS 内的 XML Publisher也就是后来的 BI Publisher组件在启动校验时主动抛出的自定义错误明摆着告诉你库存表里的 XML 清单没跟上文件系统的实际版本。如果你是 EBS 的运维 DBA、应用管理员或者负责给 EBS 打补丁、做克隆刷库这篇复盘应该能帮你少走很大一段弯路。1. 报错现场的典型场景EBS 里的“不认账”时刻1.1 这行红字到底是谁抛出来的ORA-20001 这个错误码本身没什么好查的它属于 Oracle 为应用开发者预留的自定义错误段。开发者在 PL/SQL 里调用RAISE_APPLICATION_ERROR(-20001, Latest xml inventory is not loaded into table)就可以主动把业务异常抛给前端或并发管理器。换句话说这行报错不是数据库底层崩溃而是 EBS 应用代码自己在做一致性检查时发现“对不上账”了。字面意思很清楚最新版的 xml inventory 没有被装载到表里。这里的“表”就是xmlp_inventory表。EBS 启动 XML Publisher 相关功能时会去这张表里读取当前登记的 XML 资源清单和版本信息。如果表里的版本和文件系统里实际存放的版本不一致或者表里压根没有最新记录应用就会直接拒绝继续工作而不是“少点什么也能凑合用”。这点很关键报错说的是“最新库存未加载”不是“文件丢失”。往往文件系统里已经躺着一堆最新的 XML 模板和样式文件缺的只是登记动作。所以解决问题的思路应该放在“把库存这张账补上”而不是去重新装软件。1.2 印象最深的三类现场第一次遇到这种报错是在给一套 11.5.10 的环境应用 XMLP 相关补丁时。AutoPatch 显示补丁应用完毕按 README 要求重启了应用和数据库服务结果业务人员一提交 XML Publisher 报表就报 ORA-20001。后来查日志才发现补丁明明包含了“更新 XML Publisher inventory”这个步骤但当时 AutoPatch 由于中途有人误操作退出过一次导致这个任务从未真正执行完。第二类场景和克隆刷库有关。快速克隆完成之后目标环境跑 XML Publisher 报表偶尔也报同样的错。原因不难想克隆复制了源库的xmlp_inventory数据但目标环境的文件系统是在不同时间点构建的两边版本可能对不上。尤其是源库在克隆之后又打过补丁或者克隆后直接在目标端升级了中间层都会加重这种不一致。第三类场景是人为改表。有些同行看到这个报错第一反应是“表坏了”于是备份后直接 delete 掉xmlp_inventory里的记录或者手动 update 一条高版本号进去。这种做法极大概率会引发更诡异的问题因为你改表的时候文件系统里的版本标识并没有同步改应用的下一次校验同样过不去而且由于原始记录已经没了连排查的参照系都被你亲手毁掉了。1.3 它会影响哪些功能凡是要和 XML Publisher 打交道的前台功能都可能受牵连。最典型的是报表请求在“XML Publisher 报表队列”里提交一个并发请求状态会直接变成 Error日志里就是那行 ORA-20001。BI Publisher 管理页面、部分审计报表生成、以及契约管理里的文档生成流程在调用 XML 发布组件时也可能出现类似错误。值得注意的是普通业务单据查询通常不受影响因为那些流程走的是 ERP 自身的业务模块没到 XMLP 这一层。所以你会看到一个很分裂的现象核心业务都正常偏偏所有和“报表模板”“XML 导出”沾边的功能集体罢工。这种“又好又快但一头包”的状态很容易让初次接触的人误判断是并发管理器配置出了问题。2. xmlp_inventory 的“账本”机制库存表到底在记什么2.1 文件系统是书架表是目录卡片XML Publisher 的组件不完全是存在表里的很大一部分是文件系统里的实体文件比如 XSL 样式表、RTF 模板的辅助文件、XSD 结构定义等。EBS 在运行过程中需要知道这些文件是否存在、版本是多少于是就用xmlp_inventory表做了一份“目录卡片”。把这个机制想象成一个小型图书馆补丁包里的新书被搬进了书架图书馆管理员必须同时更新目录卡否则读者来查目录时找不到新书甚至系统会认为这本书不存在。EBS 的 XMLP 组件也一样它在启动阶段会做一次“账实核对”核对方法就是去xmlp_inventory表里找最新版本。表里没有或者版本落后应用直接抛出 ORA-20001。这个比对逻辑通常发生在补丁安装后第一轮组件调用时。所以很多时候补丁打完了当天没人用报表功能一切风平浪静等到第二天大家上班一提交报表报错就像潮水一样涌出来了。2.2 核心表结构与典型内容不同版本的 EBS 里这张表的字段可能略有差异但核心列基本一致。我习惯用这个查询快速看账SELECT file_id, application_id, file_name, version, last_update_date FROM xmlp_inventory WHERE ROWNUM 20 ORDER BY last_update_date DESC;常见字段含义大致如下字段含义典型示例file_id文件唯一编号67324application_id所属应用编号630XML Publisher 常见值file_name登记的文件名xdo/xsl/des/xxrep.xslversion该文件在系统中的版本标识12.0.0.0.0last_update_date登记时间2024-06-18 10:23:45实际执行时你会看到类似这样的输出FILE_ID APPLICATION_ID FILE_NAME VERSION LAST_UPDATE_DATE ---------- ------------- ------------------------------ -------------- ------------------- 67324 630 xdo/xsl/des/xxrep.xsl 12.0.0.0.0 2024-06-18 10:23:45 67325 630 xdo/xsl/des/xxsec.xsl 12.0.0.0.0 2024-06-18 10:23:45 67326 630 xdo/xsl/des/xxstr.xsl 12.0.0.0.0 2024-06-18 10:23:45看着好像全是版本号其实这张表的价值不只是给人看的。应用启动时真正关心的是最近有没有一条“足够新”的清单记录。只要最新记录的版本号与当前补丁级别匹配校验就通过否则就认为“最新 inventory 未加载”。2.3 版本比较的规则不是比大小很多初次接触的人容易误解版本号越大就越新呗。实际上 EBS 的 XMLP 库存校验通常不是把version转换成数字再比大小而是对照补丁包内携带的版本标记做精确匹配或前缀匹配。你的文件系统里如果有一套更高版本的 XSL 文件但表里登记的版本不在应用的“白名单”里系统照样不认。这个设计是有道理的。补丁之间不一定完全线性迭代不同分支的版本可能各自维护。单纯按数字比较大小很容易出现“文件系统比表里新太多”的误判。所以 EBS 的做法更像是检查我当前代码版本依赖的这一批 XML 资源是否已经被登记到库存表中。补丁安装时会有一个专门的脚本负责把该次补丁所需的文件清单写进表里。脚本没跑或者跑挂了后续一切校验都会失败。这也解释了为什么“手工 update 一条高版本号”没有用。你只是改了目录卡片上的数字没有让卡片内容和真正的书目体系对应起来。应用一核对发现这是张来路不明的卡片照样拒绝放行。2.4 报错从哪个包来并不重要重要的是定位触发点如果你拿到一份跟踪文件可能会看到类似这样的调用栈ORA-20001: Latest xml inventory is not loaded into table ORA-06512: at APPS.XDP_INVENTORY_PKG, line 123 ORA-06512: at APPS.FND_CP_PXXXX, line 456不同版本里包名不一定相同别死记这个示例。我想说的是这个报错的定位价值不在“哪个函数抛出来的”而在于它自己把原因写得很清楚了库存表没有被更新到最新。看到跟踪文件里带出 XDP 或 XMLP 相关包名时就可以顺着补丁流程去查该跑的步骤有没有跑完。有一种情况要特别注意如果跟踪文件里根本不是 XDP/XMLP 相关包而是 FND 基础包抛出来的那就要重新审视环境是不是缺少共享库存目录或者多节点环境的文件系统不一致。这种场景在 RAC 多节点加多应用服务器时偶尔出现后文会展开说。3. 排查链路从日志到表数据一次完整的定位过程3.1 第 0 步把日志准确翻出来遇到这种报错先别急着上 SQL。你需要确认错误是从哪个进程里出来的。并发管理器报的错就去并发请求详情里找日志文件如果是在应用服务器页面上弹的 ORA-20001就去对应的应用日志目录翻。EBS 各版本日志路径不完全一样常见的是应用安装目录下的admin/log子目录或者$INST_TOP/logs下的相关文件。我一般会先把这个命令跑一遍快速定位最近的并发请求日志find $LOG_HOME -name *.log -newermt 2024-06-01 -type f然后直接看这次失败请求的日志主文件。里面该有类似这样的片段ERROR ORA-20001: Latest xml inventory is not loaded into table ORA-06512: at APPS.XDP_INVENTORY_PKG, line 123拿到这个堆栈意味着你在排查路径上已经锁定“XMLP 库存校验”这一步了。下一步就是比较表和文件系统的账。3.2 第 1 步查 XML 产品的安装状态XML Publisher 在 EBS 的“产品安装表”里也有一笔台账可以通过这个标准表快速看到产品的基本状态SELECT fa.application_short_name, pi.application_id, pi.status, pi.patch_level, pi.last_update_date FROM fnd_product_installations pi, fnd_application fa WHERE fa.application_id pi.application_id AND fa.application_short_name XML;正常情况下结果里应该有一条记录状态为IInstalledpatch_level应该和你最近一次应用补丁的级别对得上。如果这条记录本身就不存在或者patch_level明显偏旧那么问题可能要追溯到产品安装步骤而不只是 inventory 表。我见过一种情况补丁包确实包含了 XMLP 组件但 README 要求先运行某个前置脚本把 XML 产品注册表状态更新到新级别。运维跳过了这步导致 AutoPatch 虽然报告完成产品状态却是陈旧的。到了系统启动时组件校验发现自己“没被正确升级”自然就抛 ORA-20001。3.3 第 2 步对照文件系统实际版本接下来同时做两件事查表查文件系统。查表的 SQL 前文已经给过了。查文件系统我习惯这样做ls -l $XMLP_TOP/admin/sql也可以直接用 grep 在相关目录里搜版本标记grep -r version $XMLP_TOP/admin/sql --include*.sql | head -20这么做不是为了精确定位每个文件的版本而是为了确认文件系统的 XMLP 目录里确实已经有新补丁放进去的文件。如果文件全是老时间、老版本那就说明补丁在文件复制阶段就出问题了问题不在 inventory 表反之如果文件系统里已经有最新文件而表里登记的last_update_date或version还是旧的那“账实不符”的根源就坐实了。为了更直观我习惯把表和文件系统信息并排看。比如表里file_name xdo/xsl/des/xxrep.xsl的版本是12.0.0.0.0但文件系统里同名文件的修改时间戳是补丁应用当天且补丁 README 标注的 XMLP 版本是12.0.1.0.0。这就非常清楚地说明文件已经到位登记步骤没执行完整。3.4 第 3 步回补丁日志里找“没跑完的任务”确定是登记步骤缺失后下一步就是回到补丁日志里确认具体原因。常见的补丁日志目录包括$PATCH_TOP/log和$INST_TOP/logs。我用这几个关键词去翻grep -i xml.*inventory $PATCH_TOP/log/*.log grep -i update.*xmlp $PATCH_TOP/log/*.log grep -i adadmin $PATCH_TOP/log/*.log补丁日志里如果出现了 “Skipped”“Not executed” 之类的状态基本就能定位到那个被跳过的任务。还有一种情况是 AutoPatch 在执行到一半时由于超时或者人工干预中断退出重进补丁会话时没有选择“从断点继续”导致后半段任务被标记为已完成或干脆没执行。如果日志表明这个任务压根没出现在补丁动作清单里那就要再回头翻 README。有些 XMLP 相关维护步骤不在 AutoPatch 的标准动作里而是要求 DBA 在补丁结束后自行运行一个独立脚本或 adadmin 菜单选项。README 里那段 “Post-Installation” 经常被人忽略而这恰恰是 ORA-20001 的温床。3.5 第 4 步区分三种“账实不符”排查到最后通常归到以下三类类型表现修复方向漏加载表里根本没有对应最新文件记录执行 inventory 同步脚本或标准菜单加载滞后表里有记录但版本和文件系统不一致重新执行补丁中的 inventory 更新步骤人为破坏记录被 update/delete 过无从比对从备份恢复表或重新执行完整补丁流程前两类处理起来相对干净第三类最头痛。因为一旦原始记录被改过你和文件系统之间的参照系就破坏了靠猜版本号几乎不可能安全修复。最稳妥的办法是从补丁安装前的导出备份或克隆源里把xmlp_inventory表恢复出来再重新执行同步脚本。4. 修复与预防把账本补上4.1 方法一用 AutoPatch 继续完成未跑完的任务如果已经确认是某个补丁的 inventory 更新步骤没执行完最推荐的办法是回到 AutoPatch 继续跑。重新进入 AutoPatch加载同一个补丁目录文件它会自动检查哪些任务已经完成、哪些没完成然后只补跑缺失的部分。这个机制很成熟不用太担心重复执行造成混乱。具体操作方式取决于你用的是交互模式还是非交互模式cd $PATCH_TOP adpatch进入菜单后选择适合的补丁路径AutoPatch 会询问是否继续未完成的任务选 yes 即可。如果不确定当时用的补丁文件名最好去旧的 adpatch 日志里翻一下把$PATCH_TOP的路径找对。有一个细节值得提如果补丁文件已经被清理掉或者节点已经拆了那 AutoPatch 继续执行这条路就走不通了。这时候别硬编一个补丁名进去改用下面的 adadmin 菜单方案。4.2 方法二用 adadmin 的 “Maintain Applications Files” 菜单对于大部分 EBS 11i 和 R12 环境adadmin 提供了一个维护文件库存的入口。具体菜单名称在不同版本之间略有差异常见的是“Maintain Applications Files”下的“Update XML Publisher inventory”选项也有版本直接放在“Reload Oracle Applications Inventory”里。操作步骤大致如下切换到 applmgr 系统用户source 环境变量。执行adadmin选择当前维护状态对应的上下文文件。在主菜单中找到“Maintain Applications Files”相关选项。选择“Update XML Publisher inventory”按提示输入 apps 用户密码。等待脚本扫描文件系统并更新表数据。这么做比手动跑脚本安全因为 adadmin 会尝试把文件系统扫描结果和补丁安装历史对齐不是简单地向表里插几条记录。我在 R12.1 和 R12.2 上都试过基本能覆盖绝大多数的版本不一致场景。如果菜单里找不到这个选项也别强行找。不同版本功能摆的地方不一样有些版本的 XMLP inventory 同步被抽出来作为独立脚本发布那种情况下就直接跳到手动脚本方案。4.3 方法三手动执行 inventory 脚本有些场景不适合走交互菜单比如你在写自动化脚本、或者环境里 adadmin 真的没有那个选项。这时可以定位 XMLP 的 inventory 脚本手动执行。先找到脚本文件。不同版本里脚本名可能略有差异常见的是xmlpInventory.sql或类似的 naming 风格。你可以用文件名模糊搜索ls -l $XMLP_TOP/admin/sql | grep -i -E invent|xmlp一旦确认脚本位置先用 apps 用户登录 SQL*Plus按环境实际情况设置 SIDsqlplus apps/apps$ORACLE_SID $XMLP_TOP/admin/sql/xmlpInventory.sql执行前我强烈建议先做一次备份。数据库大的话不需要整库备份只需要把这极小的一张表导出成临时表就行CREATE TABLE xmlp_inventory_backup_2024 AS SELECT * FROM xmlp_inventory;这样做的好处是万一脚本执行到一半因为权限或空间问题中断你还能把账目恢复原状不至于让环境处于中间态。脚本执行完成后回到 SQL*Plus 里验证一下最新记录SELECT MAX(last_update_date) AS latest_load_date FROM xmlp_inventory;如果显示的时间是刚才那几分钟说明清单已经重新加载过一轮了。4.4 修复后的验证清单修复完不能光看表里多了几条记录必须回到业务路径验证。我建议按下述顺序检查再次查询fnd_product_installations确认 XML 产品状态和补丁级别正确。在应用层重新提交一个之前失败的 XML Publisher 并发请求观察是否从 Error 变成 Success。若无前台请求可测找一个 XML Publisher 管理页面直接打开确认不再弹 ORA-20001。检查应用服务器日志确认没有新的xmlp_inventory相关错误堆栈。如果以上都能通过说明账本已经补上故障可以关闭。如果问题依然存在那就要回头检查是不是多节点环境节点间文件系统不一致或者应用服务器上的文件系统本身没更新成功。多节点环境里光在一个节点跑 inventory 同步是不够的其它节点的文件系统如果版本落后下次调用还会报错。这种情况要确保所有应用节点的 XMLP 文件都更新到相同版本再选择任一节点执行一次同步。4.5 预防策略以后补丁别漏这几步补丁操作最怕的就是“看起来成功”。这种报错的预防其实不难核心就一句话认真读 READMEPOST 安装步骤一个都不能省。我的习惯是任何涉及 XML Publisher 或 BI Publisher 的补丁无论在测试还是生产都会做下面几件事打补丁前把xmlp_inventory的条目数和last_update_date记录下来作为变更前基线。补丁执行完毕后主动运行一次 XMLP inventory 同步不等到业务报错才动手。在变更记录单里明确写出“XMLP inventory 已更新到 XX 版本”方便后续刷库时对照。如果是克隆环境目标端环境配置完成后主动执行一次 adadmin 的 inventory 更新不依赖源库数据。做到这几点基本可以把这个 ORA-20001 挡在正式上线之前。5. 写在最后一个老运维的处置习惯我在第一次遇到这个报错时也走过弯路。当时第一反应是去查 Oracle 官方技术库里的 ORA-20001 错误码结果自然一无所获因为这是 EBS 内部业务逻辑主动抛出的自定义消息。后来静下心把补丁流程从头捋了一遍才发现是 AutoPatch 中途退出后没续跑导致的。这些年下来我的最大体会是遇到这种带“Latest ... is not loaded into table”字样的报错别急着去动表先把它当成一个“流程未完成”的信号。正常业务表一般不会因为版本不匹配而拒绝工作它会拒绝恰恰说明有一套严谨的登记机制被跳过了。另外千万别尝试通过手工 delete 或 updatexmlp_inventory来“修数据”。我见过最惨的一个案例同事为了快速恢复把所有库存记录删除了三分之一最后补丁重跑都救不回来只能从备份单独恢复这张表。一旦库存账本失去完整性后续的 XML Publisher 相关模块会连锁出现各种来源报错那种场景远比今天的 ORA-20001 难收场。如果你现在正被这个报错折腾建议先把补丁日志和xmlp_inventory的最新记录时间对一下如果时间对不上大概率就是补丁步骤缺失重跑一次同步就能解决。如果时间能对上再往多节点文件系统一致性和产品安装状态方向查。把这个顺序记在心里下次再看到那行红字你就能比第一次从容很多。
