Oracle安装报错PRCR-1079/CRS-5017/ORA-12547根因排查与修复

发布时间：2026/10/13 17:04:23
Oracle安装报错PRCR-1079/CRS-5017/ORA-12547根因排查与修复
1. 图形化安装 Oracle 最后一公里的典型崩溃现场别笑这三个错误码凑在一起出现几乎是每个装 Oracle RAC 或者单机 ASM 的人都会撞上的“劝退套餐”。尤其是图形化安装走到最后一步进度条卡在“启动集群资源”或者“配置 Oracle 高可用服务”时弹窗里冒出 PRCR-1079、CRS-5017、ORA-12547 这一串组合很多人第一反应是重新装一遍或者去搜“PRCR-1079 解决办法”但搜出来的答案往往只讲表面不解释底层逻辑。先简单给新手定个位这三个错误码不是一个层面的问题它们是连锁反应。PRCR-1079意思是“无法启动指定的资源”。在图形化安装的最后阶段安装程序会调用集群工具去启动资源比如ora.asm、ora.cssd、ora.evmd如果这些核心资源没起来安装程序就会把这个错误抛给你。CRS-5017意思是“资源操作失败”。这通常是伴随 PRCR-1079 出现的它表示具体的资源启动动作没有成功比如进程起不来、或者起来之后马上又挂了。ORA-12547这个最迷惑它叫 “TNS: lost contact”但实际场景里经常不是网络断了而是后台进程崩溃或者权限不对导致客户端连接被强制断开。在安装阶段它通常意味着sqlplus / as sysdba连不上实例或者 ASM 实例没起来。你看到这三兄弟一起出现基本可以断定集群关键资源启动链路断了导致 ASM 实例无法拉起进而数据库实例无法创建或连接。这不是你那一步操作错了而是前面某个环节埋了雷到这一步才炸。这篇文章我会从排错方法论讲起把这个组合错误的根因、排查路径、修复步骤全部拆开揉碎。内容基于我自己踩坑的经验和一些常见实践适合刚接触 Oracle 安装的人也适合那些已经装了三遍还在报同样错误的“受害者”。2. 错误码解读与排错思路为什么是这三兄弟同时出现2.1 三个错误码之间的因果链要把问题讲清楚先得理解 Oracle 图形化安装最后阶段到底在干什么。当你看到安装界面走到“最后一步”的时候其实安装程序正在执行以下操作启动集群就绪服务CRS包括cssd、evmd、diskmon这些守护进程。注册并启动 ASM 实例所需资源ora.asm、ora.oc4j等。尝试通过srvctl或者crsctl工具启动资源。一旦 ASM 实例就绪安装程序会尝试连接实例执行建库脚本。在这个链条里任何一个环节挂掉都会表现为“最后一步”失败。错误码的对应关系如下错误码含义在链路中的位置PRCR-1079资源启动命令执行失败发生在资源注册与启动阶段CRS-5017资源操作start/stop失败的具体反馈伴随 PRCR-1079说明具体哪个资源没起来ORA-12547客户端连接被中断发生在 ASM 实例仍未就绪导致后续连接失败很多时候安装日志会把这三个错误依次记录下来先是 PRCR-1079 告诉你“有个资源起不来”然后 CRS-5017 告诉你“就是这个资源启动动作执行了但失败”最后 ORA-12547 告诉你“因为前面那个资源没起来所以 ASM 连接不上后续依赖它的操作全部报错”。所以排错的时候你不需要同时解决三个错误你需要找到第一个错误引发的位置把那个根因解决掉后续两个错误码自然消失。2.2 第一优先级的排查方向资源启动失败的真实原因既然是“资源启动失败”那问题的核心就落在“资源为什么起不来”上。根据我的项目经验最常见的根因集中在以下四个方向第一权限问题。这个占比最高。Oracle 安装过程中会创建大量目录和文件如果在安装前的系统准备工作里某个目录的属主或权限设置不对进程启动时就会失败。最典型的是/u01/app/oracle目录的属主不是oracle:oinstall或者/tmp/.oracle目录权限异常。这个小问题在安装早期不会爆雷因为安装程序只在最后阶段才以特定用户身份去启动资源。第二环境变量问题。图形化安装时如果你没有在oracle用户的环境变量里正确配置ORACLE_HOME、ORACLE_BASE、PATH、LD_LIBRARY_PATH安装程序启动资源时就会找不到可执行文件或者加载不到需要的动态链接库。特别是ORACLE_HOME路径如果配错了资源启动时会直接失败。第三系统资源限制。比如/etc/security/limits.conf里没有给oracle用户配置足够的nofile文件句柄数和nproc进程数限制进程启动时可能因为资源不足被系统拒绝。第四SELinux 拦截。如果你用的是带 SELinux 的 Linux 发行版又没有关闭它安装过程中某些操作会被 SELinux 拦截表现出来就是资源启动失败而且不会给你任何明确提示。这是我见过的比较隐蔽的一个坑。2.3 一个隐藏的高频原因主机名解析异常除了上面四个还有一个很容易被忽略的问题/etc/hosts配置错误。Oracle CRS 在启动时会对主机名做正反向解析如果解析不通资源也会起不来。比如你的主机名配的是db1.example.com但/etc/hosts里写成了db1而不是db1.example.com安装程序最后阶段就会卡住。这类问题的排查思路我会在第 4 节详细展开但先记住一句话你看到三个错误时不要急着去处理任何一个错误码本身先去翻日志找到第一个失败动作。3. 修复前置条件与完整排查步骤从日志里挖出真正的根因3.1 如何拿到第一手错误日志排查 Oracle 安装问题最忌讳的是看着弹窗里的错误码就到处搜。弹窗只给了你一个缩写真正的详细日志藏在安装目录里。安装日志的位置通常在$ORACLE_BASE/cfgtoollogs/crsConfig/目录下安装程序会把 CRS 配置过程的所有输出写到这个目录。$ORACLE_HOME/cfgtoollogs/下的各种子目录。如果是图形化安装安装程序还会在$ORACLE_HOME/install/下保留*.log文件。具体来说我一般按下面的顺序翻日志先看crsConfig目录下的日志文件比如crsConfig_oracle.log里面记录的是配置 CRS 时执行的命令行和输出。找到 PRCR-1079 出现的位置往前翻十几行你会看到具体执行了哪条命令比如crsctl start resource ora.asm -init以及这条命令的输出。找到 CRS-5017 对应的crsd.log或alert.log查看资源启动失败的技术细节。如果是 ORA-12547去查$ORACLE_HOME/rdbms/log/下的alert_*.log看实例启动到一半挂掉的原因。3.2 完整排查路径从“错误列表”到“根因确认”我整理一个排查路径按照这个顺序走基本能定位 90% 的问题。第一步确认权限。ls -ld $ORACLE_BASE $ORACLE_HOME ls -ld /u01/app id oracle检查这些目录的属主和权限确保oracle:oinstall拥有完全控制权。如果发现属主不对直接执行chown -R oracle:oinstall /u01/app/oracle chown -R oracle:oinstall $ORACLE_HOME第二步确认环境变量。在oracle用户下执行echo $ORACLE_HOME echo $ORACLE_BASE echo $PATH正常情况下ORACLE_HOME应该指向你安装的 Grid 或 Database 主目录PATH应该包含$ORACLE_HOME/bin。如果发现环境变量不对编辑/home/oracle/.bash_profile或者.bashrc补上export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH然后重新登录oracle用户使环境变量生效。第三步确认系统资源限制。查看ulimit -n ulimit -u如果-n返回的值小于 65536或者-u返回值过小需要编辑/etc/security/limits.conf添加oracle soft nofile 65536 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384第四步确认 SELinux 状态。getenforce如果返回Enforcing要么临时关闭setenforce 0要么永久关闭编辑/etc/selinux/config把SELINUXenforcing改成SELINUXdisabled然后重启生效。第五步确认主机名解析。hostname cat /etc/hosts nslookup $(hostname)确保/etc/hosts里有一条记录把完整主机名和 IP 对应起来并且nslookup能正常解析。标准写法是192.168.1.100 db1.example.com db1注意主机名、完整域名、IP 三者要对应正确尤其不要把主机名写成一个不存在的域名。3.3 如果你用的是 RAC共享磁盘权限也要查如果你装的是 RAC 而不是单机还有一个隐蔽的坑udev规则或asmlib配置的共享磁盘权限不对。ASM 实例启动时需要访问共享磁盘如果磁盘设备文件的属主不是oracle:dba或者权限不是 660ASM 实例会起不来然后连带着报 ORA-12547。检查方式ls -l /dev/asm* # 或者你给共享磁盘起的设备名如果发现属主不对需要修正udev规则给这些设备文件设置正确的属主和权限。这在多数 Linux 发行版上是通过编辑/etc/udev/rules.d/下的规则文件实现的。这个环节很多人栽过跟头因为共享磁盘在安装过程中是正常的安装程序在前期检查时会读写这些磁盘但没有启动 ASM 实例所以权限问题不会暴露。到了最后一步ASM 实例需要真正“接管”这些磁盘时权限问题才显现出来。4. 实操修复逐步执行彻底解决 PRCR-1079 / CRS-5017 / ORA-125474.1 修复前必须做的三件事在动手修复之前有三个动作比任何修复步骤都重要第一备份现有配置。包括$ORACLE_HOME下的配置文件、/etc/oracle下的文件、/etc/hosts、/etc/security/limits.conf。Oracle 安装走到这一步你已经花了不少时间如果修复过程中把环境搞坏了至少还能回滚。第二确认安装日志里的失败命令。我前面讲了翻日志的方法现在再强调一遍找到 PRCR-1079 之前那个具体执行失败的命令因为不同的失败命令对应不同的根因修复方式完全不同。第三清理残留资源。修复之前最好先把安装过程中可能残留的半启动资源清理掉。这个步骤是为了避免“修复了 A结果 B 又报错”的连锁反应。4.2 通用的修复步骤附带说明以下步骤是我在实践中验证过的一整套标准修复流程适用于大多数情况。步骤一重置环境确保干净的起点。cd $ORACLE_HOME cd crs/install ./roothas.pl -deconfig -force如果是 RAC 安装执行cd $ORACLE_HOME/crs/install ./rootcrs.pl -deconfig -force -verbose执行这一步的目的是把之前没启动成功的 CRS 配置全部清掉让环境回到一个干净的状态。执行过程中如果遇到报错多半是因为部分资源还在运行可以先用crsctl stop has -f强制停止。步骤二修复所有基础环境问题。这一步就是把我前面讲到的四个方向全部过一遍权限确保$ORACLE_BASE、$ORACLE_HOME等关键目录属主为oracle:oinstall。环境变量确保ORACLE_HOME和PATH正确配置。系统资源限制确保limits.conf配置生效。SELinux确保关闭或设置为 permissive 模式。主机名解析确保/etc/hosts配置完整。共享磁盘权限RAC 适用确保设备文件属主和权限正确。检查完之后重新登录oracle用户让所有环境配置生效。步骤三尝试以 root 用户重新配置。cd $ORACLE_HOME/crs/install ./rootcrs.sh -verbose注意要用root用户执行这个脚本而不是oracle用户。安装程序在最后阶段执行的就是这条脚本的变体。如果这次执行成功了CRS 资源会全部正常启动后续的错误码就不会再出现。步骤四验证 CRS 资源状态。crsctl stat res -t查看ora.asm、ora.cssd、ora.evmd这些资源的状态正常情况下应该是ONLINE。如果哪个资源是OFFLINE或者UNKNOWN再用crsctl start resource手动启动观察输出信息。步骤五验证 ASM 实例连接。sqlplus / as sysasm如果这能顺利进入 SQL*Plus说明 ASM 实例已经正常ORA-12547 不再存在。如果还报 ORA-12547说明 ASM 实例本身起不来需要继续查alert_ASM.log里面会有更详细的报错。4.3 修复过程中最关键的细节roothas.pl 与 rootcrs.sh 的选择很多人分不清roothas.pl和rootcrs.sh到底该执行哪个这里的规则是如果你装的是Oracle Restart单机 ASM执行roothas.pl。如果你装的是Oracle RAC集群执行rootcrs.pl。选错脚本会导致资源注册方式不对看起来好像修复了但一到最后一步又报同样的错误。这个细节特别值得留意因为我见过几个同行在这个地方栽过反复安装了好几次才发现是脚本用错了。4.4 修复后的收尾操作别再装一遍修复成功之后不需要重新开始安装。你只需要回到安装程序界面选择“重试”或者直接重新执行最后一步配置即可。图形化安装程序在资源启动失败后通常允许你重新执行配置步骤而不会要求你从头再来。如果你已经把安装程序关掉了也可以用配置助手DBCA或者手动执行dbca来补建数据库实例但最稳妥的做法还是重跑安装程序里的最后一步。5. 常见问题速查表与避坑指南5.1 常见问题的快速定位表现象可能原因排查方式PRCR-1079 CRS-5017 ORA-12547 三连发资源启动链路断裂ASM 实例未就绪查 crsConfig 日志定位失败命令仅 PRCR-1079不伴随 ORA-12547特定资源如 ora.cssd未启动crsctl stat res -t查看具体状态ORA-12547 反复出现ASM 起不来共享磁盘权限 / SELinux 拦截 / 环境变量缺失ls -l /dev/asm*、getenforce、echo $ORACLE_HOMErootcrs.sh 执行到一半卡住主机名解析问题 / 资源残留cat /etc/hosts、ps -ef修复后重跑安装程序仍报同样错误环境变量没有重新加载 / ohasd 进程未完全停止source ~/.bash_profile、crsctl stop has -f5.2 避坑指南几个容易忽略的细节细节一不要在 root 和 oracle 用户之间来回切换时丢掉环境变量。很多教程会告诉你“用 root 执行 rootcrs.sh”但这个脚本内部会切换到oracle用户执行操作它依赖oracle用户的环境变量。如果你没有在/home/oracle/.bash_profile里配置好环境变量脚本执行时会找不到可执行文件报错信息却伪装成 PRCR-1079 的样子。细节二检查/tmp目录的写权限。安装过程中需要往/tmp写临时文件如果/tmp/.oracle目录被创建时属主不对或者/tmp空间不足也会引发资源启动失败。这个原因出现的概率不高但一旦出现查日志很难察觉因为报错信息在/var/log/messages或者dmesg里。细节三Oracle 19c 及以上版本需要额外的libnsl依赖。如果你装的是新版本比如 19c 或者 21c系统里缺少libnsl.so.1动态库资源启动时加载库会失败。这种情况在你手动执行sqlplus时不一定报错但通过集群启动 ASM 实例时就会报 ORA-12547。检查方式ldd $ORACLE_HOME/bin/oracle | grep nsl如果发现not found用包管理器安装libnsl即可。细节四绝对不要忽略防火墙。如果你是在有防火墙的环境里安装 RAC安装过程中节点之间的通信端口需要开通否则集群资源会周期性失败。这个问题的表现是资源启动后短暂 ONLINE然后又自动变 OFFLINE伴随 CRS-5017 错误。这跟其他根因不同不是一次性失败而是反复失败特别容易让人误判。5.3 一次典型的完整修复过程复盘我给一个我实际经历过的场景方便你对照环境一台服务器安装 Oracle 19c 单机 ASM走到最后一步时弹窗报出 PRCR-1079、CRS-5017、ORA-12547。我拿到问题后的处理路径是这样的打开$ORACLE_BASE/cfgtoollogs/crsConfig/crsConfig_oracle.log发现在报错前执行的命令是crsctl start resource ora.asm -init输出包含一段CRS-5017: Resource ora.asm failed to start。继续翻日志发现起 ASM 实例时执行的sqlplus / as sysasm失败错误是ORA-12547: TNS: lost contact。手动执行sqlplus / as sysasm确认这个错误能稳定复现。查$ORACLE_HOME/rdbms/log/alert_ASM.log发现实例初始化到某个阶段被中止后面跟了一行操作系统层面的错误日志。查dmesg和/var/log/messages发现进程启动时被 SELinux 拦截getenforce返回Enforcing。将 SELinux 设置为permissive重新执行rootcrs.sh -deconfig -force清理环境再重新执行rootcrs.sh -verbose。检查crsctl stat res -tora.asm状态为 ONLINE。重跑安装程序最后步骤顺利通过。整个过程耗时大约四十分钟其中大部分时间花在翻日志定位 SELinux 上。如果一开始就关闭 SELinux这个问题根本不会出现。6. 三种让你少走弯路的附加经验6.1 安装前的一小时检查胜过安装后的三天排错很多人在装 Oracle 时习惯“边装边踩坑”但 Oracle 安装对前置环境的要求极为苛刻与其等到最后一步报错才回来排查不如在安装前把环境检查到位。我个人的习惯是按下面这个清单逐项检查全部通过后才开始安装系统版本与 Oracle 版本的兼容性列表。/etc/hosts配置中主机名的正反向解析。所有依赖包安装完整包括那些“可选”的包。内核参数配置正确shmmax、shmall、semmsl、semmni等。oracle用户的limits.conf配置。SELinux 关闭或 permissive。防火墙规则正确。临时目录空间充足。如果使用共享存储确认设备文件的属主和权限。这套清单看着琐碎但每一条都对应着一个你可能遇到的坑。特别是内核参数我见过太多人因为kernel.sem配置得过小导致 Oracle 进程启动时创建信号量失败而系统日志里只会显示一个很模糊的错误排查起来极其痛苦。6.2 学会读日志而不是背错误码有同行问过我“PRCR-1079 到底怎么解决”我的回答是别背错误码学会读日志。Oracle 安装和运行过程中的错误码本质上是一个索引真正的信息在日志里。你如果只盯着错误码搜答案会把大量时间浪费在不匹配的方案上。以 PRCR-1079 为例这个错误码可以对应至少十种不同的根因权限、环境变量、内核参数、动态库缺失、防火墙、SELinux、共享磁盘、主机名解析、资源残留、软件氧化比如补丁没打全。每一种根因的修复方式都不同但它们的共同点是详细原因在crsd.log、alert日志或系统日志里。我的建议是排查 Oracle 问题时把 70% 的时间花在日志上30% 的时间花在执行修复命令上。不要反过来。6.3 保持耐心这类问题不是一次就能搞定的最后分享一个心态上的经验遇到 PRCR-1079 / CRS-5017 / ORA-12547 这类组合错误不要指望一次修复就能彻底解决。因为你修复了第一个根因后可能会暴露出第二个根因这在 Oracle 安装中是常态。比如你修复了 SELinux 问题重启安装程序后发现又报了环境变量问题再修复后又暴露了一个防火墙问题。这不是你操作失误而是因为安装程序在资源启动阶段会逐层暴露环境中的隐藏问题。每一次修复都是在替系统“拆弹”拆完一颗才发现下一颗。所以保持耐心按照我上面的排查路径走你最终会得到一条干净的错误链从三个错误码逐步收敛到一个明确的根因。我个人在实际操作中体会到遇到这类繁琐的报错时最忌讳的是“改一下试试不行再改回来”这种操作方式会把环境搞得更乱。正确做法是先完整地走一遍排查路径收集到足够的日志信息再一次性把所有确定有问题的点修复掉最后才重新执行安装步骤。按照这个节奏走多数情况下一次就能通过。