一次在测试环境给客户部署 Oracle 19c 单机版安装程序走到第二步屏幕上接连弹了三个错误码INS-06006、INS-44000、INS-32070。旁边还有等着验收的同事气氛一度很尴尬。这三个错误码在 Oracle 19c 的 Linux 安装里出现频率相当高而且经常是连体婴一样一起跳出来很多人第一次遇到就直接懵了——明明按照文档一步步来怎么就装不上。先说结论这三个错误本质上都不是 Oracle 软件包的问题而是安装前置环境检查没通过分别指向系统依赖包、oraInventory 目录权限、系统用户组配置。换句话说问题出在“你准备这台机器的方式”上而不是安装包本身。下面我按自己的实际排查过程把这个组合报错的来龙去脉、解决步骤、以及我踩过的坑完整写一遍。这篇文章适合刚接触 Oracle 19c 安装的 DBA、运维工程师也包括在公司内网搭测试环境的前后端开发同学照着做一遍基本能顺利把单机 CDB 装起来。1. 先搞清楚三个错误码到底在说什么网上很多人把这三个错误码混在一起谈逻辑其实没理清。我建议你拿到报错后先别急着百度先看 OUIOracle Universal Installer的判定逻辑。这三个错误码不是同一个检查项但它们的共同点是OUI 在图形界面阶段做“环境预检”发现有一批系统条件不满足然后一次性抛出。1.1 INS-44000oralnventory 目录没有准备好INS-44000 的完整信息一般是INS-44000: the inventory location and the inventory group cannot be accessed.翻译过来就是Oracle 在系统里找不到可用的中央库存oraInventory目录或者找到了但是权限不对。oraInventory 是 Oracle 用来记录“本机装过哪些 Oracle 产品、安装了哪些组件”的中央清单目录它在 Linux 上默认位于$ORACLE_BASE/../oraInventory也就是如果你 ORACLE_BASE 是/u01/app/oracle那它就在/u01/app/oraInventory。这个目录的位置信息保存在/etc/oraInst.loc文件里对普通用户安装来说这个文件一般是由 root 执行的oraInventory创建脚本生成的。如果你是以 oracle 用户直接启动 runInstaller而/etc/oraInst.loc又不存在、或者指向的目录没有创建权限就会触发 INS-44000。这类问题常见于用户手动删除了/u01/app/oraInventory、重新安装系统后残留旧的 oraInst.loc、或者 /u01 分区空间不足导致目录创建失败。1.2 INS-32070dba/oper 系统组配置不满足要求INS-32070 的报错信息通常是INS-32070: The OSDBA, OSOPER or OSBACKUPDBA group is not specified.这个错误我早期遇到过好几次印象很深。Oracle 19c 安装时OUI 要求指定一组系统组名用于划分数据库的 DBA 权限、操作员权限、备份权限。默认情况下这些组对应的是oinstall、dba、oper其中oinstall是 oracle 软件所有者主组dba是数据库管理员组。如果你创建用户时只建了一个 oracle 用户没有同时创建 oinstall 和 dba 组或者创建了但 oracle 用户的主组/附加组没指定对OUI 在检查到“指定组不存在或用户不属于该组”时就会报 INS-32070。还有一个隐藏很深的场景oinstall、dba组存在oracle 用户也加了进去但你是在旧会话里执行的安装程序shell 会话内的组信息没有刷新OUI 读到的还是旧数据。1.3 INS-06006系统不满足最低安装要求INS-06006 的信息一般长这样INS-06006: Passwordless SSH connectivity is not set up between the following node(s).这是最坑的一条。很多人看到 SSH 就以为必须要配免密其实在单机安装场景下遇到这个错误更常见的原因是ksh 没装、libaio 没装、glibc 版本不对或者主机名解析不正常。严格来说INS-06006 属于“系统检查未通过”的综合错误它对应的检查项可能有好几条OUI 只显示最后一条导致失败的项目。所以解决思路不能只盯着 SSH而是要往后看日志找到真正的失败项。我在实际环境中遇到的 INS-06006大多数情况是缺少ksh或pdksh。Oracle 19c 的 OUI 在检查操作环境时会去验证 Korn Shell 是否存在因为后端很多脚本比如root.sh、orainstRoot.sh是用 ksh 写的。RHEL/CentOS 7 默认没有安装 ksh这基本是一踩一个准。另外libXpX 图形库缺失也会触发图形化 OUI 的异常判定虽然 19c 文档里已经不太提 libXp但某些内网离线环境还是有这个问题。1.4 为什么这三个错误经常一起出现因为 OUI 的环境预检是“批量执行”的它不会遇到第一个失败就停下来而是把整批检查跑完把所有失败项汇总后一起弹出来。所以 INS-06006、INS-44000、INS-32070 一起出现说明这台机器在依赖包、目录权限、系统组三块都没准备到位——典型的“从零开始装 Oracle环境准备环节被跳过了”的状态。理解这个逻辑之后你的解决顺序就清楚了先把系统组建好再把 inventory 目录建好最后再处理依赖包和系统检查。顺序不对的话会出现“改了 A 报错变成 B、改了 B 报错又回到 A”的死循环。2. 安装前环境清单别等报错了才回头补很多安装教程喜欢直接扔命令不解释为什么。这一节我会把 Oracle 19c 在 Linux 上安装前必须准备的几类环境项拆开讲每条后面都补一句“如果不做会怎样”这样你以后再装 12c、21c 也能举一反三。2.1 内核参数与资源限制配置Oracle 对 Linux 内核参数有硬性要求虽然 19c 比 11g 放宽了一些但最核心的几个还是必须设置。编辑/etc/sysctl.conf追加以下内容fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4294967295 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576然后执行sysctl -p让它生效。这里不建议你只抄前三个net.core.wmem_max等网络参数如果不配后面建监听Listener时可能出现奇怪的内存分配问题日志还看不出直接关联。资源限制方面需要编辑/etc/security/limits.conforacle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768改完后用ulimit -u、ulimit -n检查是否生效。这个文件有个坑CentOS 7 之后有些版本需要确认/etc/security/limits.d/下面有没有 90-nproc.conf 之类的覆盖文件如果有里面内容可能把 nproc 限制盖掉你光改 limits.conf 是不生效的。2.2 依赖包一条 yum 命令补齐Oracle 19c 在 RHEL/CentOS 7 上的依赖包官方文档列了一张很长的表。我实际用过最少的一套是yum install -y binutils compat-libcap1 compat-libstdc-33 \ gcc gcc-c glibc glibc-devel ksh libaio libaio-devel \ libgcc libstdc libstdc-devel libXext libXtst libX11 \ libXau libXi libXv libXrender libXp make net-tools \ nfs-utils python python-configshell \ sysstat unixODBC unixODBC-devel重点说下ksh。Oracle 官方安装文档里提到 pdksh但 pdksh 在 RHEL 7 的官方 yum 源里早就不提供了RHEL 7 默认的 ksh 是由 ATT 维护的 KSH-93 版本完全满足 Oracle 19c 的检查要求。所以如果你看到网上老帖子让你装 pdksh先确认系统版本别去第三方源硬装旧包容易把系统搞坏。compat-libstdc-33在 CentOS 7 的默认源里可能在 Base 源中如果 yum 提示找不到可以加 EPEL 源或者直接忽略它。我在多次实测中没装这个包也能完成 19c 安装只是官方文档里列了它。libXp也是同理图形化安装界面在 CentOS 7 上不一定缺它但保险起见装上没坏处。2.3 创建用户、组和目录结构这是很多人“凭感觉”操作最容易出错的一步。正确顺序是先建组再建用户最后建目录。方向反了会出现目录属主不对、组 ID 对不上等问题。groupadd oinstall groupadd dba groupadd oper useradd -g oinstall -G dba,oper oracle echo oracle | passwd --stdin oracle mkdir -p /u01/app/oracle mkdir -p /u01/app/oraInventory chown -R oracle:oinstall /u01/app chmod -R 775 /u01/app这里有个容易忽略的细节oinstall组要用-g指定为 oracle 用户的主组dba和oper用-G加到附加组。如果建用户时漏了-G dba,oper后面安装到指定 OSDBA 组时OUI 能检测到 dba 组存在但检查 oracle 用户是否在该组里时会失败INS-32070 就出来了。目录结构方面/u01/app是整个 Oracle Base 的父目录/u01/app/oraInventory承载中央库存。有些人喜欢把 oraInventory 放在/u01/app/oracle下这本身不是不可以用但不要和 ORACLE_BASE 混在一起避免升级或卸载时目录纠缠不清。我个人的习惯是保持官方默认布局ORACLE_BASE/u01/app/oracleORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1oraInventory/u01/app/oraInventory。2.4 环境变量不仅是“写上”还要“生效”oracle 用户的.bash_profile里至少要配置以下内容export ORACLE_BASE/u01/app/oracle export ORACLE_HOME$ORACLE_BASE/product/19.3.0/dbhome_1 export ORACLE_SIDorcl export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:/lib:/usr/lib export LANGen_US.UTF-8注意LANGen_US.UTF-8很关键。如果你的系统默认 locale 是zh_CN.UTF-8安装界面会显示中文某些 OUI 检查和错误信息在中文 locale 下会出现编码异常严重时直接闪退或误报错误。我在安装时报过几次诡异的 INS-06006切回英文 locale 就正常了。配置完环境变量后建议重新ssh oraclelocalhost登录一次别用source ~/.bash_profile糊弄过去因为你当前 shell 的环境变量即使刷新了可能还有残留值。3. 实操现场完整解决 INS-06006 / INS-44000 / INS-32070如果安装程序已经在报错了不要慌也不需要卸载重来。按下面步骤操作处理后重新跑 runInstaller 即可。下面以 RHEL/CentOS 7.9 Oracle 19.3 单机安装为例。3.1 第一步手工创建 oraInventory 并修正权限首先检查/etc/oraInst.loc是否存在cat /etc/oraInst.loc如果文件不存在Oracle 会让你指定 inventory 目录。但为了避免 OUI 在创建时因权限或路径问题再次报 INS-44000我建议直接手工把目录和配置文件都建好mkdir -p /u01/app/oraInventory chown -R oracle:oinstall /u01/app/oraInventory chmod -R 775 /u01/app/oraInventory cat /etc/oraInst.loc EOF inventory_loc/u01/app/oraInventory inst_groupoinstall EOF chown root:oinstall /etc/oraInst.loc chmod 664 /etc/oraInst.loc/etc/oraInst.loc的权限建议是 664属主为 root、属组为 oinstall这是 Oracle 官方要求的默认权限。如果权限太松比如 777一些安全扫描工具会报风险如果太紧oracle 用户可能读不到 inventory_loc 路径。这一步做完后可以先用./runInstaller再试一次。如果报错还是 INS-44000大概率是 SELinux 或文件系统特殊挂载导致的写入/读取限制检查一下/var/log/messages中有没有 avc denied 记录再决定是临时setenforce 0还是加 SELinux 模块放行。我一般不推荐直接关 SELinux但测试环境倒也没必要较真关闭后安装确实顺畅很多。3.2 第二步核对用户组归属并刷新会话执行id oracle观察输出uid54321(oracle) gid54321(oinstall) groups54321(oinstall),54322(dba),54323(oper)重点看 gid 和 groups。如果你的输出里主组是 oracle 而不是 oinstall或者 groups 里没有 dba那 INS-32070 就在这等着你。修正方法usermod -g oinstall -G dba,oper oracle执行完usermod后坑就来了oracle 用户当前打开的会话不会自动更新组信息必须完全退出重登。你可以执行exit退出 SSH再重新登录一次然后再次id oracle确认。如果你是用 su 切换的也要退出 su 再切一次或者执行newgrp dba临时刷新当前会话的组身份。我自己有次就是漏了这一步改完组直接在当前会话里重跑 runInstaller连续三次报 INS-32070最后才发现 OUI 读到的还是旧组信息。这个细节特别容易让人怀疑是不是安装包的问题。另外如果你所在环境有 NIS/LDAP 集中账号管理/etc/group里可能查不到 oinstall 和 dba这种情况下要确认网络域认证服务是否正常OUI 需要能正常解析组名。内网环境里我遇过一次 LDAP 临时抖动导致 INS-32070等 LDAP 恢复后重跑就过了。3.3 第三步安装依赖包并处理系统检查中的“隐藏失败项”依赖包最简单直接 yum 装yum install -y ksh libaio libaio-devel libXp libXtst libXext sysstat unixODBC装完后用which ksh验证which ksh /bin/ksh如果which ksh没输出说明 ksh 没装上。检查一下 yum 是否报错比如某个依赖被exclude了。很多整理过内核的服务器会在/etc/yum.conf里配置excludekernel*这不会影响 ksh但如果你之前有人配置过excludeksh*那确实会拦下来。依赖包处理完后如果你重跑 OUI 还是报 INS-06006就需要打开日志找具体失败项了。日志位置通常在$ORACLE_HOME/cfgtoollogs/oui/installActions*.log用 grep 过滤关键字grep -iE error|failed|expected|required installActions2024-xx-xx_xx-xx-xxPM.log我看到过一个很典型的例子日志里写着Expected value: CentOS Linux release 7.9.2009 (Core) Actual value: CentOS Stream release 8这就是操作系统版本不匹配导致的 INS-06006。OUI 有一个检查项是对比当前系统/etc/redhat-release和官方支持的版本列表。CentOS Stream 8 本身能装 19c但 OUI 的认证列表里没有它于是判定失败。解决方式有两个一是修改/etc/redhat-release的显示内容“骗过”OUI二是在安装时加上-ignorePrereq参数跳过预检。我个人不推荐修改/etc/redhat-release虽然网上很多人这么做但 Oracle 的relink和opatch在某些阶段还是会读取系统版本改过之后可能引发后续 bug。更稳妥的方式是使用响应文件静默安装并加-ignorePrereq下面一节会细说。3.4 第四步用静默安装绕开图形界面“假故障”图形界面的 OUI 在不同桌面环境下X11、VNC、MobaXterm表现不太一样字体、中文 locale、窗口渲染都可能导致一些莫名其妙的检查失败。所以如果你已经反复处理过依赖、组、目录问题最后还是卡在 INS-06006我建议你直接切换到静默安装模式。先生成响应文件模板cd $ORACLE_HOME ./runInstaller -silent -responseFile /tmp/db_install_19c.rsp如果没有现成的 rsp 文件可以从安装包解压目录里找模板。我自己通常先编辑一个最小可用版本核心参数如下oracle.install.responseFileVersion/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0 oracle.install.optionINSTALL_DB_SWONLY UNIX_GROUP_NAMEoinstall INVENTORY_LOCATION/u01/app/oraInventory ORACLE_BASE/u01/app/oracle ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 oracle.install.db.InstallEditionEE oracle.install.db.OSDBA_GROUPdba oracle.install.db.OSOPER_GROUPoper oracle.install.db.OSBACKUPDBA_GROUPdba oracle.install.db.OSDGDBA_GROUPdba oracle.install.db.OSKMDBA_GROUPdba oracle.install.db.OSRACDBA_GROUPdba oracle.install.db.CLUSTER_NODES oracle.install.db.isRACOneInstallfalse oracle.install.db.ConfigureAsOracleHomefalse oracle.install.db.config.starterdb.typeGENERAL_PURPOSE oracle.install.db.ConfigureASMfalse oracle.install.db.config.starterdb.memoryOptionfalse oracle.install.db.config.starterdb.installExampleSchemasfalse SECURITY_UPDATES_VIA_MYORACLESUPPORTfalse DECLINE_SECURITY_UPDATEStrue然后执行./runInstaller -silent -ignorePrereq -responseFile /tmp/db_install_19c.rsp-ignorePrereq的意思不是忽略所有检查而是让 OUI 跳过非关键性的前置检查像系统版本认证这类“软性检查”就会被放行。依赖包缺失这种“硬性检查”依然会被卡住所以前面该装的依赖还是得装。静默安装执行后观察输出日志。它会在最后提示你以 root 用户执行两个脚本/u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/19.3.0/dbhome_1/root.sh这两个脚本必须用 root 执行否则软件安装不会完整收尾。我之前在自动化脚本里漏跑了root.sh结果 sqlplus 能启动但监听始终起不来排查了半天教训很深刻。3.5 第五步验证安装结果软件安装完成后先确认主要进程和版本su - oracle sqlplus / as sysdba如果 SQL*Plus 能进入SQL提示符说明软件层没问题。然后执行CREATE DATABASE; -- 或者用 DBCA 建库建议用 DBCA 的静默模式建一个 CDB 测试dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname orcl -sid orcl \ -responseFile NO_VALUE \ -characterSet AL32UTF8 \ -memoryPercentage 40 \ -emConfiguration NONE \ -sysPassword Oracle_123 \ -systemPassword Oracle_123建库命令执行时间取决于机器配置一般 10 到 20 分钟。期间可以在另一个终端用tailf观察 DBCA 的日志确认有没有报错。4. 常见问题与排查技巧实录这一节把我在不同环境下碰过的、以及群友问过的高频问题整理成一个速查表给以后再遇到类似报错的人快速定位用。现象可能原因解决办法INS-44000 反复出现/u01/app/oraInventory 属主不对chown -R oracle:oinstall /u01/app/oraInventoryINS-44000 SELinux 拦截SELinux enforcing 拦截 OUI 创建目录临时setenforce 0或配置放行规则INS-32070 提示组不存在没创建 oinstall/dba 组或拼写错误groupadd oinstallgroupadd dbaINS-32070 提示用户不在组中usermod 后没重新登录退出会话重新 SSH或用newgrp dbaINS-06006 日志显示 ksh 缺失没安装 kshyum install -y kshINS-06006 日志显示版本不支持系统版本不在认证列表比如 CentOS Stream静默安装加-ignorePrereqINS-06006 显示 SSH 免密失败多节点环境未配互信单机环境可忽略检查 /etc/hosts 主机名图形界面 OUI 乱码/闪退locale 非英文、字体不全设置LANGen_US.UTF-8重跑静默安装卡住不结束磁盘空间不足或 tmp 分区太小df -h /tmp清理空间监听启动失败listener.ora 主机名解析不了检查/etc/hosts主机名不要带下划线4.1 日志排查别靠猜直接看 installActions我见过不少新手卡在一个错误码上反复重装系统太冤了。其实 OUI 在预检失败时已经把详细原因写在installActions.log里了。文件位置一般在$ORACLE_HOME/cfgtoollogs/oui/installActions*.log或者/tmp/InstallActions*。排查动作就三步先找到日志文件再按时间戳定位到报错段最后 grepINFO:和ERROR:两种级别的上下文。举个例子grep -n INS-06006 installActions2025-xx-xx_xx-xx-xxPM.log你会看到类似这样的内容INFO: Prerequisite check CheckSystemRequirements failed. INFO: Expected value: ksh INFO: Actual value: isnt installed看到Expected value: ksh / Actual value: isnt installed事情就清楚了装 ksh 完事。日志里不会直接写“请安装xxx”但 Expected/Actual 的对比就是检查项判定的核心逻辑熟练之后排查起来非常快。4.2 中文 locale 造成的误报这个问题很长一段时间都排在 Oracle 安装出错榜前列。CentOS 7 经典的中文环境问题是安装界面乱码但 19c 的 OUI 在中文环境下不只是乱码它还会影响某些检查项的判定结果甚至引发异常退出。如果你要用图形界面安装强烈建议先执行export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8再启动 runInstaller。如果系统里没有 en_US.UTF-8 这个 locale可以用localedef生成或者干脆装一下glibc-langpack-en包。用英文界面安装很多看着摸不着头脑的报错会少一大半。4.3 修改 /etc/redhat-release 的副作用刚才说过不推荐伪造系统版本。但内网测试环境里有些同学为了走完安装流程还是会改这个文件。改完确实能让 INS-06006 的版本检查通过但副作用体现在后面Oracle 的 opatch补丁工具和 relink重新链接可执行文件会读取系统信息如果它发现自己在一个“假版本”的系统上执行可能拒绝工作。一个相对安全的替代方案是不改系统文件而是先备份再修改安装完成、打补丁之前恢复原文件。但这个方法依然有风险我更推荐在静默安装时加-ignorePrereq它只跳过当前这次安装的预检不会污染系统文件。4.4 一个小脚本30 秒自查环境最后分享一个我常用的环境自检脚本把前面所有关键点一次性扫完省得一项项敲命令#!/bin/bash # Oracle 19c 环境自检脚本CentOS/RHEL 7/8 echo 1. 用户组检查 id oracle 2/dev/null || echo oracle 用户不存在 echo 2. inventory 检查 cat /etc/oraInst.loc 2/dev/null || echo /etc/oraInst.loc 不存在 ls -ld /u01/app/oraInventory 2/dev/null || echo oraInventory 目录不存在 echo 3. 依赖包检查 rpm -q ksh libaio libaio-devel libXp sysstat unixODBC 2/dev/null echo 4. 内核参数检查 sysctl kernel.sem fs.file-max fs.aio-max-nr net.ipv4.ip_local_port_range 2/dev/null echo 5. 磁盘空间检查 df -h /u01 /tmp | awk {print $1, $4, $6} echo 6. 主机名检查 hostname grep $(hostname) /etc/hosts || echo /etc/hosts 中找不到本机主机名把这个脚本保存为oracle_precheck.sh用 root 执行它会自动把最常见的环境问题暴露出来。我在每台新机器上装 Oracle 前都会跑一遍基本能做到“一次过”。最后说点体己话这三个错误码看着唬人实际上就是 Oracle DBA 入门路上的一道家常菜。我后来在内部培训时经常跟新人说遇到安装报错先忍住“重装系统”的冲动学会看日志、理解检查项比记住十个错误码的答案重要得多。因为这些检查项的逻辑是通用的今天你能解决 INS-06006明天遇到类似的 INS-30131 或者 OUI-10035排查思路是一样的看日志找 Expected 和 Actual 的差异再对症下药。另外趁这个机会把静默安装的响应文件留好以后批量部署或者无人值守安装都能直接复用省下的时间远不止这次排查的工夫。