企业官网建设流程全解析

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 图形化安装最后阶段到底在干什么。

当你看到安装界面走到“最后一步”的时候，其实安装程序正在执行以下操作：

1. 启动集群就绪服务（CRS），包括cssd、evmd、diskmon这些守护进程。
2. 注册并启动 ASM 实例所需资源（ora.asm、ora.oc4j等）。
3. 尝试通过srvctl或者crsctl工具启动资源。
4. 一旦 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文件。

具体来说，我一般按下面的顺序翻日志：

1. 先看crsConfig目录下的日志文件，比如crsConfig_oracle.log，里面记录的是配置 CRS 时执行的命令行和输出。
2. 找到 PRCR-1079 出现的位置，往前翻十几行，你会看到具体执行了哪条命令，比如crsctl start resource ora.asm -init，以及这条命令的输出。
3. 找到 CRS-5017 对应的crsd.log或alert.log，查看资源启动失败的技术细节。
4. 如果是 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，把SELINUX=enforcing改成SELINUX=disabled，然后重启生效。

第五步：确认主机名解析。

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，或者权限不是 660，ASM 实例会起不来，然后连带着报 ORA-12547。

检查方式：

ls -l /dev/asm* # 或者你给共享磁盘起的设备名

如果发现属主不对，需要修正udev规则，给这些设备文件设置正确的属主和权限。这在多数 Linux 发行版上是通过编辑/etc/udev/rules.d/下的规则文件实现的。

这个环节很多人栽过跟头，因为共享磁盘在安装过程中是正常的，安装程序在前期检查时会读写这些磁盘，但没有启动 ASM 实例，所以权限问题不会暴露。到了最后一步，ASM 实例需要真正“接管”这些磁盘时，权限问题才显现出来。

4. 实操修复：逐步执行，彻底解决 PRCR-1079 / CRS-5017 / ORA-12547

4.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 常见问题的快速定位表

5.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。

我拿到问题后的处理路径是这样的：

1. 打开$ORACLE_BASE/cfgtoollogs/crsConfig/crsConfig_oracle.log，发现在报错前执行的命令是crsctl start resource ora.asm -init，输出包含一段CRS-5017: Resource 'ora.asm' failed to start。
2. 继续翻日志，发现起 ASM 实例时执行的sqlplus / as sysasm失败，错误是ORA-12547: TNS: lost contact。
3. 手动执行sqlplus / as sysasm，确认这个错误能稳定复现。
4. 查$ORACLE_HOME/rdbms/log/alert_+ASM.log，发现实例初始化到某个阶段被中止，后面跟了一行操作系统层面的错误日志。
5. 查dmesg和/var/log/messages，发现进程启动时被 SELinux 拦截，getenforce返回Enforcing。
6. 将 SELinux 设置为permissive，重新执行rootcrs.sh -deconfig -force清理环境，再重新执行rootcrs.sh -verbose。
7. 检查crsctl stat res -t，ora.asm状态为 ONLINE。
8. 重跑安装程序最后步骤，顺利通过。

整个过程耗时大约四十分钟，其中大部分时间花在翻日志定位 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 问题，重启安装程序后发现又报了环境变量问题，再修复后，又暴露了一个防火墙问题。

这不是你操作失误，而是因为安装程序在资源启动阶段会逐层暴露环境中的隐藏问题。每一次修复都是在替系统“拆弹”，拆完一颗才发现下一颗。所以，保持耐心，按照我上面的排查路径走，你最终会得到一条干净的错误链：从三个错误码逐步收敛到一个明确的根因。

我个人在实际操作中体会到，遇到这类繁琐的报错时，最忌讳的是“改一下试试，不行再改回来”，这种操作方式会把环境搞得更乱。正确做法是：先完整地走一遍排查路径，收集到足够的日志信息，再一次性把所有确定有问题的点修复掉，最后才重新执行安装步骤。按照这个节奏走，多数情况下一次就能通过。