应直接查看installactions*.log最后20行，重点排查severe/error/exception、o/s-error、ora-等关键错误，优先确认orainst.loc配置正确及tmpdir可写，再分析prcz-1082等衍生报错。
直接看 installActions*.log 最后 20 行
OUI 失败时，日志不会把真正原因藏在中间，基本都堆在末尾。别从头翻，浪费时间。安装过程一旦中断，installActions*.log 文件会立即 flush 写入最后几条关键错误，比如 PRCZ-1082、OUI-25031 或 INS-30131 这类带编号的报错，它们就是定位入口。
常见操作：
- 进
C:Program FilesOracleInventorylogs（Windows）或/u01/app/oraInventory/logs（Linux），找最新日期命名的installActions*.log - 用
tail -20 installActions*.log（Linux）或记事本打开后跳到文件末尾（Windows） - 重点盯住含
SEVERE、ERROR、Exception的行，忽略大量INFO和CONFIG
搜 “O/S-Error” 和 “ORA-” 看底层系统反馈
OUI 是 Java 写的外壳，很多失败本质是操作系统拒绝了某项操作，比如加组、写文件、挂共享。这时候日志里会出现原生系统错误码，比 OUI 自己包装的错误更有价值。
典型线索：
-
O/S-Error: (OS1387)→ Windows 下目标组不存在（如USERS组被禁用或重命名） -
O/S-Error: (OS5)→ 拒绝访问，大概率是/u01/app/oraInventory权限不对或oraInst.loc指向了错误路径 -
ORA-12547: TNS:lost contact→ 不是监听问题，而是安装过程中尝试连本机数据库失败，说明 DB 实例根本没起来，得回头查runInstaller前是否漏了环境变量（如ORACLE_HOME未设）
确认 oraInst.loc 是否生效且指向可写目录
OUI 启动时第一件事就是读 oraInst.loc，它决定了 inventory 存哪、用哪个组管理。如果这个文件内容错、路径不存在、或权限不够，后续所有操作都会卡在权限校验环节，报错却未必明说。
检查要点：
- Linux：运行
cat /etc/oraInst.loc，确认inventory_loc路径存在且属主是当前安装用户（如oracle），权限至少为drwxr-xr-x - Windows：查注册表
HKEY_LOCAL_MACHINESOFTWAREORACLEINST_LOC，值必须是真实存在的本地路径（不能是映射网络驱动器），且当前用户对该路径有完全控制权 - 如果
oraInst.loc不存在，OUI 会 fallback 到默认路径（如/home/oracle/oraInventory），但该路径若被之前版本残留污染，就会触发OUI-10150
临时目录不可写常导致“静默退出”而非明确报错
Windows 上 setup.exe 双击后一闪而逝、Linux 上 runInstaller 执行完没反应，90% 是 TMPDIR 或 %TEMP% 不可用。OUI 需要解压 staging 包到临时区，路径不通就直接 abort，连错误对话框都不弹。
验证方式：
- Windows：管理员运行
cmd，执行echo %TMP%和net use \localhostC$，后者必须返回“命令成功完成” - Linux：切换到安装用户（
su - oracle），运行echo $TMPDIR，再mkdir -p $TMPDIR/test && touch $TMPDIR/test/a && rm -rf $TMPDIR/test - 路径含空格或总长超 80 字符（如
C:Users张三Downloadsoracle）也会触发静默失败，改用D:oh这类极简路径重试
OUI 日志里最麻烦的不是报错本身，而是它常把多个失败串在一起：比如临时目录不可写 → 导致 inventory 初始化失败 → 进而导致用户组添加失败 → 最终显示 PRCZ-1082。所以别盯着第一个红叉修，先确保 oraInst.loc 和 TMPDIR 这两个基础点稳了，再往下看。
