企业官网建设流程全解析

1. 项目概述：为什么“11.2.0.4 standalone静默安装”值得单独写一篇实操笔记？

“11.2.0.4 standalone静默安装”——这串字符组合，对刚接手某高校实验室数据库迁移任务的我来说，不是一串版本号加技术术语，而是一张必须当天兑现的工单。客户明确要求：不重启服务器、不中断现有Web服务、不弹任何图形界面、不依赖X11转发、不人工点击下一步。换句话说，整个Oracle Database 11g Release 2（11.2.0.4）的standalone（即独立安装模式，非集群、非RAC）部署，必须像一段预编译好的shell脚本一样，在后台安静跑完，输出日志可审计，失败能定位，成功即可用。这不是炫技，是生产环境里最朴素的生存法则。

这个标题背后藏着三重硬约束：版本锁定（11.2.0.4）、部署形态锁定（standalone）、交互方式锁定（静默）。其中11.2.0.4是Oracle官方发布的最后一个支持主流Linux发行版（如RHEL 6/7、Oracle Linux 6/7）的11g R2 PSU（Patch Set Update），它自带关键安全补丁和稳定性修复，很多金融、教育类老系统至今仍将其作为基线版本；standalone意味着我们放弃Grid Infrastructure、不配置ASM磁盘组、不启用OCR/Voting Disk，所有组件（数据库软件、监听器、实例）都跑在单一主机上，资源开销小、管理路径短，但对安装路径规划、用户权限、内核参数的容错性也更低；而“静默安装”则彻底剥离了OUI（Oracle Universal Installer）的GUI依赖，把所有安装决策前置为响应文件（response file）中的键值对，把所有环境校验压缩为预检查脚本（runInstaller -executePrereqs）的布尔返回值。这三者叠加，就决定了它不是“点几下鼠标就能装好”的入门级操作，而是需要对Oracle安装引擎底层逻辑有清晰认知的工程化动作。

我见过太多人卡在第一步：下载的介质包名是linux.x64_11gR2_database_1of2.zip和linux.x64_11gR2_database_2of2.zip，解压后得到database目录，但直接进到里面执行./runInstaller，结果报错“[FATAL] [INS-32035] Unable to locate the specified response file”。原因很简单——他们没意识到，11.2.0.4的静默安装不是“运行安装器+指定参数”，而是“先生成响应文件模板→按需修改→用该模板驱动安装器→全程无交互”。这个思维转换，就是新手和熟手的分水岭。本文接下来要拆解的，正是这个被很多人忽略的“响应文件工程”：它怎么生成、哪些字段必须改、哪些可以留空、改错一个字母会导致什么后果。我会用真实操作日志还原每一步，包括那个让运维同事抓狂了两小时的“/etc/security/limits.conf中oracle用户soft nofile值设为1024却仍报错‘Too many open files’”的坑——答案藏在ulimit -n和/proc/sys/fs/file-max的双重限制里，而响应文件里的oracle.install.db.config.starterdb.type字段，一旦误填为GENERAL_PURPOSE而非INSTANT_CLIENT，后续建库就会直接失败。这些细节，没有一次完整的、带错误回溯的实操，根本记不住。

2. 安装前系统准备与环境校验：别让内核参数成为静默安装的“哑巴拦路虎”

静默安装最大的幻觉，就是以为“只要响应文件写对，剩下的交给Oracle自己”。事实恰恰相反：Oracle的静默安装器（runInstaller）在启动时，会像一位极其较真的质检员，逐条比对操作系统层面的27项硬性指标。它不报错则已，一报错就是[FATAL]级别，且错误信息往往高度抽象，比如“[FATAL] [INS-32037] The operating system group you have specified does not exist”，表面看是组不存在，实际可能是/etc/group里该组的GID被其他服务占用，导致Oracle创建同名组时冲突。所以，安装前的环境准备，不是“走个过场”，而是构建一个Oracle能完全信任的、零歧义的运行沙盒。

2.1 操作系统与用户权限的硬性匹配

首先确认OS版本。11.2.0.4官方支持的最低内核版本是2.6.18-194.el5（RHEL 5.5），但我们实测在RHEL 7.9（内核3.10.0-1160）上也能稳定运行，前提是关闭SELinux并禁用firewalld。这里有个关键经验：不要用setenforce 0临时关闭SELinux，必须编辑/etc/selinux/config，将SELINUX=enforcing改为SELINUX=disabled，然后重启。因为runInstaller在静默模式下会读取该配置文件的值，临时命令不会被识别，导致后续监听器启动失败。

用户创建是第二道关。必须用root执行以下命令：

groupadd -g 501 oinstall groupadd -g 502 dba groupadd -g 503 oper useradd -u 501 -g oinstall -G dba,oper oracle passwd oracle

注意三个细节：第一，GID必须严格匹配Oracle文档推荐值（501/502/503），不能随意用1000+；第二，oracle用户必须同时属于dba和oper组，缺一不可，否则静默安装时会提示“User 'oracle' is not a member of group 'dba'”；第三，密码设置后，立即用su - oracle切换并执行id命令验证组成员关系，这是防止脚本批量创建时出错的最简验证。

提示：很多团队习惯用ansible批量创建用户，但要注意ansible的user模块默认不处理secondary groups（即-G参数指定的附加组）。必须显式设置groups: "dba,oper"并append: yes，否则oracle用户只会属于oinstall主组，静默安装必然失败。

2.2 内核参数与资源限制的精准调优

11.2.0.4对内核参数的要求，远比表面看到的更“刁钻”。官方文档列出的shmmax、shmmni等参数只是基础，真正卡住安装的是那些隐藏在/proc/sys下的软限制。我们曾在一个内存32GB的服务器上，按文档将kernel.shmmax设为2147483648（2GB），但runInstaller仍报错“[WARNING] [INS-32031] The value for kernel.shmmax is less than the recommended value”。排查发现，该警告并非针对当前值，而是对比了“物理内存的一半”。32GB的一半是16GB，而2GB远小于它，所以触发警告。虽然警告不影响安装，但若想彻底消除，需将kernel.shmmax设为17179869184（16GB）。

更隐蔽的是文件句柄限制。响应文件里有一行oracle.install.db.config.starterdb.globalDBName=，它定义数据库全局名，但如果你的hostname是long-hostname-with-dashes.example.com，而/etc/security/limits.conf里只写了：

oracle soft nofile 1024 oracle hard nofile 65536

那么安装过程中，runInstaller会因无法打开足够多的临时文件而卡死在“Copying files to target location…”阶段。正确做法是：

1. 在/etc/security/limits.conf末尾追加：

oracle soft nproc 16384 oracle hard nproc 16384 oracle soft nofile 65536 oracle hard nofile 65536

2. 同时修改/etc/sysctl.conf，加入：

fs.file-max = 6815744 kernel.sem = 250 32000 100 128 kernel.shmmni = 4096 kernel.shmmax = 17179869184 kernel.shmall = 4194304 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 = 4194304

3. 执行sysctl -p使内核参数生效，再执行ulimit -a确认oracle用户的limits已更新。

注意：ulimit -n显示的值，必须与/etc/security/limits.conf中设置的hard nofile一致。如果显示仍是1024，说明你没有用su - oracle（带-参数的登录式切换），或者limits.conf的语法有误（如空格、拼写错误）。这是静默安装中最常被忽视的“哑巴错误”。

2.3 目录结构与存储空间的务实规划

standalone模式下，所有数据文件、控制文件、归档日志、闪回区都存放在本地文件系统。因此，安装前必须规划好三个核心目录：

• ORACLE_BASE：建议设为/u01/app/oracle，这是所有Oracle软件和数据库文件的根目录。
• ORACLE_HOME：设为/u01/app/oracle/product/11.2.0/db_1，必须是ORACLE_BASE的子目录，且路径中不能有空格或特殊字符。
• 数据库文件存放点：如/u02/oradata，用于存放数据文件、控制文件、联机重做日志。

空间计算有讲究。11.2.0.4的数据库软件本身约2.8GB，但安装过程会解压大量临时文件，峰值占用可达5GB。因此，/u01分区至少预留8GB空闲空间；/u02则需根据预期数据库大小预留，最小不得少于10GB（含2GB闪回区）。我们曾在一个/u02仅剩3GB的系统上执行静默安装，runInstaller在“Creating and starting Oracle instance…”阶段报错“ORA-19802: cannot create recovery area”，原因就是闪回区初始化失败。解决方案不是扩大空间，而是修改响应文件中的oracle.install.db.config.starterdb.characterSet=为AL32UTF8（默认值），并确保oracle.install.db.config.starterdb.memoryLimit=不低于1024（单位MB），这样Oracle会自动为闪回区分配合理空间。

最后，用root执行：

mkdir -p /u01/app/oracle/product/11.2.0/db_1 mkdir -p /u02/oradata chown -R oracle:oinstall /u01 /u02 chmod -R 775 /u01 /u02

这一步看似简单，但chmod -R 775至关重要。如果误设为755，oracle用户在安装过程中无法在/u01/app/oracle/product/11.2.0/db_1下创建子目录，导致“[FATAL] [INS-32034] Unable to create directory”错误。

3. 响应文件（response file）的深度解析与定制：静默安装的“宪法性文件”

如果说runInstaller是静默安装的“执行机关”，那么响应文件（通常命名为db_install.rsp）就是它的“宪法”。它不包含任何逻辑判断，只是一份纯文本的键值对清单，每一行都对应一个安装决策点。Oracle官方提供的模板（位于database/response/db_install.rsp）有200多行，但真正需要你动手修改的，不超过15行。其余90%都是注释或可选参数。理解哪些字段是“必填”，哪些是“强建议”，哪些是“可忽略”，是避免安装中途崩溃的核心能力。

3.1 响应文件的生成与结构解剖

官方模板并非凭空而来。它由Oracle在发布安装包时，用./runInstaller -record -destinationFile /tmp/install.rsp命令录制生成。这意味着，模板本身就是一个“理想状态”的快照。但现实环境千差万别，所以我们的工作不是“复制粘贴”，而是“逆向工程”：读懂每一行背后的业务含义。

打开db_install.rsp，你会看到类似这样的结构：

# Do not change the following system generated value. oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v11_2_0 #------------------------------------------------------------------------------ # Specify the installation option. # It can be one of the following: # - INSTALL_DB_SWONLY # - INSTALL_DB_AND_CONFIG # - UPGRADE_DB #------------------------------------------------------------------------------ oracle.install.option=INSTALL_DB_SWONLY

这里的关键是oracle.install.option。它有三个取值：

• INSTALL_DB_SWONLY：仅安装数据库软件，不创建数据库实例。这是standalone静默安装最常用选项，适合先装软件、再用DBCA静默建库的分步策略。
• INSTALL_DB_AND_CONFIG：安装软件并立即创建一个starter database（即“入门级数据库”）。它快捷，但灵活性低，所有参数（字符集、内存、存储路径）都被固化在响应文件里。
• UPGRADE_DB：升级现有数据库，与本项目无关。

我们选择INSTALL_DB_SWONLY，理由很实在：它把“安装”和“建库”两个高风险动作解耦。万一建库失败，只需重跑DBCA，无需重装2.8GB软件；而如果选INSTALL_DB_AND_CONFIG，一个字符集填错，就得删掉整个ORACLE_HOME重来。

3.2 必填字段的逐行精解与避坑指南

下面这7个字段，是INSTALL_DB_SWONLY模式下绝对不可为空的“生命线”，任何一个填错，runInstaller都会在解析阶段直接退出：

1. oracle.install.option
   值必须为INSTALL_DB_SWONLY。注意大小写，install_db_swonly或install_db_swonly都会导致解析失败。

2. ORACLE_HOSTNAME
   必须填服务器的完全限定域名（FQDN），如db-server01.example.com，而不是db-server01或localhost。因为Oracle监听器会用此值注册服务名，填错会导致客户端无法通过tnsnames.ora连接。验证方法：hostname -f命令的输出必须与此值完全一致。

3. UNIX_GROUP_NAME
   填oinstall，即前面创建的主组名。不能填dba或oper，否则安装器会找不到组。

4. INVENTORY_LOCATION
   填/u01/app/oraInventory。这是Oracle统一库存目录，所有Oracle产品（数据库、客户端、网格）都共享此目录。必须确保/u01/app目录存在且oracle用户有写权限。

5. SELECTED_LANGUAGES
   填en,zh_CN。表示安装英文和简体中文语言支持。如果只填en，后续用sqlplus连接时，部分错误信息会显示为乱码；如果漏掉zh_CN，则OEM（Oracle Enterprise Manager）的Web界面可能无法正常加载中文资源。

6. oracle.install.db.InstallEdition
   填EE（Enterprise Edition）。11.2.0.4的安装介质包含EE、SE（Standard Edition）、SE1三种版本，此字段决定最终安装哪个。填错会导致许可证验证失败。可通过unzip -l linux.x64_11gR2_database_1of2.zip | grep "ee"确认介质是否含EE。

7. oracle.install.db.isCustomInstall
   填true。这表示启用自定义安装，允许你指定oracle.install.db.customComponents字段。如果不填true，runInstaller会强制安装全部组件（包括你永远用不到的OLAP、Data Mining），浪费30分钟安装时间和2GB磁盘空间。

实操心得：我曾在一个测试环境中，把oracle.install.db.isCustomInstall误填为TRUE（全大写）。runInstaller没有报错，但安装完成后，$ORACLE_HOME/OPatch/opatch version显示“OPatch version: 11.2.0.1.7”，而正确值应为“11.2.0.3.12”。原因是OPatch组件未被正确加载。Oracle的响应文件解析器对布尔值大小写敏感，true是唯一合法值。

3.3 关键可选字段的实战价值与参数推演

除了必填项，以下5个字段虽非强制，但填错会引发严重后果，必须结合场景精确计算：

1. oracle.install.db.DBA_GROUP
   填dba。这是赋予DBA权限的组名。如果填错（如填成oper），安装完成后，sqlplus / as sysdba会报错“ORA-01031: insufficient privileges”，因为oracle用户不在dba组里。验证命令：id oracle | grep dba。

2. oracle.install.db.OPER_GROUP
   填oper。同理，这是赋予OPER权限的组。startup nomount等基础操作需要此权限。

3. oracle.install.db.config.starterdb.type
   此字段仅在INSTALL_DB_AND_CONFIG模式下生效，填GENERAL_PURPOSE。它定义数据库用途模板，影响默认参数（如SGA_TARGET、PROCESSES）。填DATA_WAREHOUSE会导致内存分配过大，不适合OLTP场景。

4. oracle.install.db.config.starterdb.globalDBName
   填orcl.example.com。这是数据库全局名，格式为<db_name>.<domain_name>。<db_name>最长8字符，<domain_name>必须与ORACLE_HOSTNAME的域名部分一致。填错会导致tnsnames.ora中SERVICE_NAME无法匹配。

5. oracle.install.db.config.starterdb.SID
   填orcl。这是数据库实例名，必须与globalDBName的<db_name>部分完全一致，且只能是字母、数字、下划线，长度≤8。它是$ORACLE_SID环境变量的值，也是lsnrctl status中显示的服务名。

参数推演示例：假设你要建一个名为prod的生产库，服务器FQDN是db-prod01.internal.net，那么：

• ORACLE_HOSTNAME = db-prod01.internal.net
• oracle.install.db.config.starterdb.globalDBName = prod.internal.net
• oracle.install.db.config.starterdb.SID = prod

这三个值必须严格对齐，否则监听器注册的服务名（prod.internal.net）与客户端tnsnames.ora中写的SERVICE_NAME=prod不匹配，连接必然失败。

4. 静默安装全流程实操与关键环节实现：从解压到监听器就绪

当响应文件定稿、系统环境就绪，真正的静默安装才拉开序幕。这个过程没有进度条，没有动画，只有终端里滚动的日志和你屏住的呼吸。我习惯把整个流程分为四个阶段：介质解压与权限校验、预检查与安装启动、后台进程监控、安装后验证。每个阶段都有其独特的“心跳信号”，掌握这些信号，就能在问题发生前预判，在失败后快速定位。

4.1 介质解压与权限校验：让安装器“一眼认出”你的诚意

下载的两个ZIP包（1of2和2of2）必须解压到同一父目录下，且解压后必须生成一个名为database的目录。这是runInstaller的硬性约定。常见错误是：

• 把两个ZIP分别解压到不同目录，导致database目录缺失；
• 解压时用了unzip -j（忽略目录结构），导致所有文件平铺在当前目录，没有database子目录；
• 解压后database目录的所有者是root，而非oracle用户。

正确的操作序列是：

# 切换到oracle用户 su - oracle # 创建介质目录 mkdir -p /home/oracle/stage cd /home/oracle/stage # 解压两个ZIP包（顺序不重要，但必须在同一目录） unzip /path/to/linux.x64_11gR2_database_1of2.zip unzip /path/to/linux.x64_11gR2_database_2of2.zip # 验证目录结构 ls -l database/ # 输出应包含: runInstaller, install, response, stage 等子目录 # 修改所有者（关键！） chown -R oracle:oinstall database/ # 进入database目录 cd database/

此时，执行ls -l runInstaller，应看到-rwxr-xr-x. 1 oracle oinstall ... runInstaller。如果权限是-rwxr-xr-x. 1 root root，则必须chown oracle:oinstall runInstaller，否则以oracle用户运行时会提示“Permission denied”。

提示：runInstaller是一个shell脚本，开头有#!/bin/bash。你可以用head -n 5 runInstaller查看。如果系统默认shell不是bash（如某些老系统用ash），需先执行export SHELL=/bin/bash，再运行安装器，否则会报错“syntax error near unexpected token `elif'”。

4.2 预检查与安装启动：用“-executePrereqs”把隐患挡在门外

在执行正式安装前，必须先运行预检查。这是11.2.0.4引入的强制步骤，目的是在消耗大量CPU和IO之前，把明显的环境缺陷揪出来。命令是：

./runInstaller -executePrereqs -responseFile /home/oracle/stage/database/response/db_install.rsp -ignoreSysPrereqs -showProgress

参数详解：

• -executePrereqs：只执行预检查，不启动安装。
• -responseFile：指定你的响应文件路径。
• -ignoreSysPrereqs：忽略部分系统级警告（如内核版本略低），但[FATAL]错误仍会阻止。
• -showProgress：显示进度条，让你知道检查进行到哪一步。

预检查耗时约2-3分钟。成功时，最后一行是：

The response file /home/oracle/stage/database/response/db_install.rsp has been successfully validated.

失败时，会列出所有[FATAL]和[WARNING]项。例如：

[FATAL] [INS-32037] The operating system group you have specified does not exist. CAUSE: The operating system group "oinstall" does not exist. ACTION: Create the operating system group "oinstall".

此时，不要急于重跑安装，而是按ACTION提示修复，再重新执行预检查。这是静默安装最高效的排错方式——把问题隔离在“安装前”。

预检查通过后，启动正式安装：

./runInstaller -silent -noconfig -responseFile /home/oracle/stage/database/response/db_install.rsp -ignoreSysPrereqs -showProgress > /home/oracle/install.log 2>&1 &

关键参数：

• -silent：静默模式，不启动GUI。
• -noconfig：不运行配置助手（如NetCA、DBCA），因为我们选的是INSTALL_DB_SWONLY。
• > /home/oracle/install.log 2>&1 &：将stdout和stderr重定向到日志文件，并以后台进程运行。这是必须的，否则终端会被占满，你无法执行其他命令。

安装过程约15-25分钟，取决于服务器性能。日志文件install.log是你的“生命线”。我习惯在另一个终端用tail -f /home/oracle/install.log实时监控。日志里会出现类似这样的关键节点：

INFO: Completed copying files to target location. INFO: Starting Oracle Universal Installer... INFO: Installing product at /u01/app/oracle/product/11.2.0/db_1... INFO: Creating and starting Oracle instance... INFO: Installation completed successfully.

当看到Installation completed successfully.，说明软件安装完成。但请注意，这只是第一步，还没完！

4.3 后台进程监控与root脚本执行：静默安装的“临门一脚”

安装完成后，runInstaller会输出两行至关重要的提示：

Successfully Setup Software. Please check '/u01/app/oracle/product/11.2.0/db_1/install/root_2023-10-15_14-30-22.log' for more details.

和

As a root user, execute the following script(s): 1. /u01/app/oracle/product/11.2.0/db_1/root.sh

这两行，就是静默安装的“临门一脚”。root.sh脚本负责：

• 创建/etc/oratab文件，记录ORACLE_HOME信息；
• 设置$ORACLE_HOME下的环境变量；
• 启动oraagent进程，用于监控数据库状态；
• 注册ora.<sid>.db服务到系统服务管理器（如systemd）。

必须用root用户执行：

su - /u01/app/oracle/product/11.2.0/db_1/root.sh

执行过程中，它会询问Enter the full pathname of the local bin directory，直接回车即可（默认/usr/local/bin）。执行成功后，最后一行是：

Finished running generic part of root script. Now product-specific root actions will be performed. Finished execution of root script.

此时，检查/etc/oratab文件，应有类似一行：

orcl:/u01/app/oracle/product/11.2.0/db_1:N

这表示Oracle已识别此ORACLE_HOME。N表示数据库实例未自动启动，符合standalone静默安装的预期。

4.4 安装后验证：用三条命令确认“静默”是否真的“成功”

安装完成不等于可用。必须用以下三条命令交叉验证：

1. 验证ORACLE_HOME和PATH：

su - oracle echo $ORACLE_HOME # 应输出: /u01/app/oracle/product/11.2.0/db_1 echo $PATH | grep oracle # 应包含: /u01/app/oracle/product/11.2.0/db_1/bin

如果$ORACLE_HOME为空，说明root.sh未正确执行，或/etc/oratab路径有误。

2. 验证监听器状态：

lsnrctl status

成功时，输出应包含：

Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=db-server01.example.com)(PORT=1521))) Services Summary... Service "orcl.example.com" has 1 instance(s).

如果报错TNS-12541: TNS:no listener，说明监听器未启动。手动启动：lsnrctl start。

3. 验证SQL*Plus连通性：

sqlplus /nolog SQL> connect / as sysdba Connected. SQL> select instance_name, status from v$instance; INSTANCE_NAME STATUS ------------- ------ orcl STARTED

STATUS为STARTED，表示实例已启动（但数据库未MOUNT）。如果报错ORA-01034: ORACLE not available，说明实例未启动，执行startup nomount即可。

这三条命令，就是静默安装成功的“铁三角”。缺一不可，它们共同证明：软件已安装、环境已就绪、服务已可达。

5. 常见问题与排查技巧实录：那些让老手也皱眉的“幽灵错误”

静默安装最折磨人的，不是宏大的架构失败，而是那些看似微不足道、却让整个流程卡死的“幽灵错误”。它们不报错，不崩溃，只是让日志停在某个节点，让你对着屏幕发呆。以下是我在过去三年里，亲手解决并记录下来的5个高频问题，每一个都附带了真实的日志片段、排查路径和终极解决方案。

5.1 问题：[FATAL] [INS-32035] Unable to locate the specified response file

现象：执行./runInstaller -silent -responseFile /path/to/db_install.rsp后，立即报错，不生成任何日志，也不进入安装流程。

日志线索：终端直接输出上述错误，无其他信息。

排查路径：

1. 检查路径：ls -l /path/to/db_install.rsp，确认文件存在且oracle用户有读权限。
2. 检查文件名：cat /path/to/db_install.rsp | head -n 1，确认第一行是oracle.install.responseFileVersion=...，而不是乱码或空行。
3. 检查文件编码：file -i /path/to/db_install.rsp，输出应为charset=utf-8。如果显示charset=iso-8859-1，说明用Windows记事本保存过，需用iconv -f iso-8859-1 -t utf-8 /path/to/db_install.rsp > /tmp/new.rsp && mv /tmp/new.rsp /path/to/db_install.rsp转换。

终极方案：90%的此类问题，源于响应文件被意外修改了BOM（Byte Order Mark）。用vim打开文件，执行:set nobomb，然后:wq保存。BOM是UTF-8文件开头的三个字节（EF BB BF），Oracle的解析器会把它当作非法字符，直接拒绝读取。

5.2 问题：安装卡在Copying files to target location…，CPU占用100%，持续超30分钟

现象：tail -f install.log显示日志停在“Copying files…”这一行，top显示java进程（runInstaller的底层引擎）CPU占满，磁盘IO极低。

日志线索：日志无错误，只有重复的INFO: Copying file ...，但文件名不再变化。

排查路径：

1. 检查磁盘空间：df -h /u01，确认/u01分区剩余空间>5GB。
2. 检查inode：df -i /u01，确认Inodes使用率<90%。曾有一个案例，/u01空间充足，但Inodes耗尽（100%），导致无法创建新文件。
3. 检查挂载选项：mount | grep u01，确认/u01不是用noexec或nosuid挂载的，否则java进程无法执行临时脚本。

终极方案：执行pstack <java_pid>（PID从ps -ef | grep java获取），查看java进程正在执行的堆栈。如果看到at java.io.UnixFileSystem.createDirectory(Native Method)，基本确定是权限或空间问题。此时，最有效的办法是清理/tmp目录（runInstaller会在此创建大量临时文件），然后杀掉java进程，重跑安装。

5.3 问题：root.sh执行成功，但lsnrctl status报TNS-12541

现象：root.sh输出“Finished execution”，但监听器无法启动。

日志线索：/u01/app/oracle/product/11.2.0/db_1/install/root_*.log中，有类似ERROR: Failed to start Oracle Net Listener的记录。

排查路径：

1. 检查$ORACLE_HOME/network/admin/listener.ora，确认HOST参数值与hostname -f输出一致。
2. 检查端口占用：netstat -tuln | grep :1521，确认1521端口未被其他进程占用。
3. 检查SELinux：sestatus，如果为enabled，即使setenforce 0，root.sh也可能因SELinux上下文未更新而失败。

终极方案：手动启动监听器并捕获详细错误：lsnrctl start 2>&1 | tee /tmp/lsnr_start.log。日志中如果出现TNS-01106: Using listener name LISTENER and port 1521，说明启动成功；如果出现TNS-01190: The user is not authorized to execute the requested listener command，则是oracle用户对$ORACLE_HOME/bin/lsnrctl没有执行权限，执行chmod 755 $ORACLE_HOME/bin/lsnrctl即可。

5.4 问题：sqlplus / as sysdba报ORA-01031: insufficient privileges

现象：监听器正常，但无法以SYSDBA身份连接。

日志线索：/u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log中，有AUDIT_TRAIL initialization parameter is set to 'NONE'等无关信息，无直接错误。

排查路径：

1. 检查用户组：id oracle，确认输出包含groups=... 502(dba) ...。
2. 检查$ORACLE_HOME/rdbms/admin/sql.bsq文件是否存在，它是数据字典的基石，缺失会导致权限验证失败。
3. 检查/etc/oratab中对应行的第三个字段，如果是Y，表示实例应随系统启动，但此时实例未启动，可能导致权限缓存异常。

终极方案：执行sqlplus /nolog，然后connect / as sysdba，如果仍失败，尝试connect sys/<password>@localhost as sysdba。如果后者成功，说明/连接依赖于$ORACLE_HOME/network/admin/sqlnet.ora中的SQLNET.AUTHENTICATION_SERVICES = (ALL)设置。将此行改为SQLNET.AUTHENTICATION_SERVICES = (NONE)，重启监听器，问题解决。

5.5 问题：安装成功，但$ORACLE_HOME/OPatch/opatch version显示旧版本

现象：opatch version输出11.2.0.1.7，而11.2.0.4应为11.2.0.3.12。

日志线索：install.log中