真是被自己气笑了。。。
环境信息
产品：Oracle Database 19c (19.0.0.0)
Oracle Home：
/u01/app/oracle/product/19.0.0.0/dbhome_1oraInventory 路径：
/u01/app/oraInventoryOPatch 版本：12.2.0.1.48
OUI 版本：12.2.0.7.0
故障现象
执行任何 OPatch 命令（如 opatch apply）时，OPatch 在初始化oraInventory会话阶段报错：
Unable to lock Central Inventory. OPatch will attempt to re-lock.OPatch 会反复提示“是否继续重试”，表面上看起来像有其他进程持有了库存锁。
初步排查（常规方向）
检查残留 OPatch 进程：执行
ps -ef | grep -i opatch未发现其他 OPatch 进程。检查锁文件：在oraInventory目录
/u01/app/oraInventory及其子目录下未发现.lock、.ouilock、patch_locked等文件。检查文件句柄占用：使用
lsof +D /u01/app/oraInventory未发现任何进程占用库存目录下文件。
然后又开了debug, export OPATCH_DEBUG=true
OUISessionManager::createAndInitCISession() sets up READ-WRITE session
==> OUIInventorySession::initSession(): Process ID: 142598. Thread ID: 1
OUISessionManager::createAndInitCISession() throws Exception <<只能看到这个。
OUISessionManager::createAndInitCISession() done
locking starts at 1780452434676, now is 1780453090161, 655 seconds has gone by.
Unable to lock Central Inventory. OPatch will attempt to re-lock.
Do you want to proceed? [y|n]还是看不到比较合适的报错。
但是有一个点，opatch lsinventory 是正常的。 说明 invertory 是正常的。
深入定位（系统调用跟踪）
我们注意到日志里 OPatch 自己的 PID（142598）在初始化会话时抛出异常，于是决定直接跟踪该进程的系统调用。
检查进程存活：
ps -p 142598确认进程仍在。使用
strace附加进程：bash
分析 strace 输出：在日志中发现了决定性的一行：
text
mkdir("/u01/app/oraInventory/locks", 0777) = -1 ENOSPC (No space left on device)这揭示出 OPatch 尝试在库存目录下创建
locks子目录时，因ENOSPC（No space left on device）而失败，紧接着它就抛出异常并进入“无法锁定oraInventory”的重试循环。
strace -f -p 142598 -s 256 -o /tmp/opatch.strace.log真是无语，前面常规排查 lock 文件问题花了很多时间，浪费了好多时间，又是被自己气笑的一天。
