Oracle 11gR2 Linux安装卡点：图形、介质、前置检查与监听

简介：面向Linux平台数据库运维人员与Oracle初学者的图解式安装文档，聚焦Oracle 11g Release 2单机环境部署中依赖检查、用户组与环境变量配置、安装向导选项判断等易错环节。文档以1个doc文件交付，压缩包约1.73MB，体积轻便，便于在实施现场离线查阅与对照操作。内容围绕runInstaller启动、安装类型与组件选择、Inventory目录和OS组指定、系统安装检查、root脚本执行，以及netca监听配置和dbca建库等流程展开，并提示分辨率调整、双盘解压到同一目录、空间不足报错可忽略等实践细节。文中还强调数据库服务名需与ORACLE_SID保持一致、字符集可选UTF-8以支持中文等关键点，可作为安装前检查清单和过程排错参考。已有134人学习，适合需要按图解逐步完成单机部署并减少配置返工的读者。

1. 装了三遍才明白：11gR2 卡住人的地方不在点 Next

第一次在 Linux 上装 Oracle 11gR2，./runInstaller敲下去，终端刷了两行就退回提示符了，连个报错窗口都没留下。第二次界面出来了，装到一半跳出“找不到某个文件”。第三次装完了，sqlplus / as sysdba进去直接 ORA-01034。三次失败，没有一次是因为点错 Next——全卡在图形环境、安装介质和前置配置上。Oracle 11gR2 在 Linux 上的安装流程本身不复杂，难的是它把几乎所有配置错误都推迟到某个看似无关的步骤才暴露。这篇按故障类型拆：每一类报错先讲触发条件，再讲怎么查，最后给能直接抄的命令。适合第一次在 Linux 上装 11gR2 被卡住的人，也适合装过几次但每次都要重新翻手册的人。

2. runInstaller 起不来：DISPLAY、分辨率与乱码的排查顺序

runInstaller是整套安装里第一个拦路虎，也是最容易被误判的一步。它本质是个 Java 图形程序，依赖 X11 通道。只要 X 通道不通，它不会给你一个像样的错误提示，而是打印几行堆栈就退出，看上去像是“安装程序坏了”。判断顺序应该是：先确认当前 shell 有没有可用的 DISPLAY，再确认分辨率够不够放得下安装窗口，最后才怀疑 Java 本身。

2.1 敲完命令就退回：先用 xdpyinfo 判断 X 通道

典型现象是在 SSH 会话里执行./runInstaller，终端输出类似java.lang.NoClassDefFoundError或者干脆只有Exception in thread "main"，然后回到提示符。很多人第一反应是 JDK 版本不对、包没装全，其实九成以上是 DISPLAY 没设或者 X 转发没开。

排查不要靠猜，按下面三条依次验证：

# 1. 当前 shell 里到底有没有 DISPLAY echo $DISPLAY # 正常输出形如 :0.0（本机图形桌面）或 192.168.1.20:10.0（X 转发） # 2. X 通道是否真的可用，能输出版本和分辨率就说明通 xdpyinfo | head -5 # 3. 如果是以 root 登录再 su 到 oracle，X 授权需要显式放开 xhost +

第一行是判断有没有设置，第二行是判断设置得对不对。很多情况下echo $DISPLAY有值，但xdpyinfo报unable to open display，这说明显示变量存在、通道不存在——常见于用su oracle切换用户后环境变量被清掉，或者 X 服务端没允许该用户连接。第三行的xhost +只是临时放开访问控制，装完记得用xhost -收回，别长期开着。

如果确认安装在虚拟机里，直接在虚拟机自带的图形桌面里打开终端跑runInstaller，比折腾 X 转发省事得多。DISPLAY=:0.0这种情况在本地桌面会话里几乎总是有效的。

2.2 界面出来了但按钮点不到：分辨率、VMware 与滚动

第二个高频现象更隐蔽：安装界面能弹出来，但窗口比屏幕大，底部的 Next 按钮被截在屏幕外，鼠标滚轮也滚不动。Oracle 的 OUI 窗口写死了最小尺寸，分辨率低于 1024×768 时就会出现这个问题。

处理方式分两层。先在当前会话里临时改分辨率验证：

# 查看当前支持的分辨率模式 xrandr # 临时切到 1024x768，验证是不是分辨率问题 xrandr -s 1024x768

xrandr不带参数会列出所有可用模式，带-s是立即切换。如果列表里根本没有 1024×768，说明虚拟显卡驱动没装好，这才是根因。在虚拟机里跑的场景，装完 VMware Tools（或对应的增强工具）之后，分辨率列表才会出现足够多的选项；没装工具时通常只有 800×600 一档，怎么调都不够。

还有一个小技巧：窗口拖不动的时候，按住 Alt 再拖动鼠标左键，可以把窗口整体往上推，把底部按钮挪进可视区域。这招在临时救急时很好用，但别指望它解决根本问题——分辨率不够时，某些对话框的输入框会被挤压到无法输入，装到一半还是会卡住。

2.3 中文全是方块：LANG、字体包与安装语言

第三个现象是界面能显示，但中文全是小方块，或者安装过程中出现大量乱码。这不是 Oracle 的问题，是系统缺中文字体，或者 LANG 和实际字体不匹配。

安装前可以先看一眼当前语言环境：

echo $LANG # 常见值：en_US.UTF-8、zh_CN.UTF-8、C locale | head -3

如果LANG是zh_CN.UTF-8但系统没装中文字体包，Java 找不到对应字形，就会渲染成方块。两种处理方式：要么把语言切成英文再装，要么补齐字体包。切英文最省事，安装过程中选择“English”作为安装语言，装完再按业务需要设字符集，两者互不影响。

这里有个容易被混淆的点：安装界面语言和数据库字符集是两回事。界面选英文只是让 OUI 用英文显示，最终建库时字符集仍然要选UTF-8（准确说是AL32UTF8），否则后面存中文会出问题。这两个设置在不同的步骤里，别因为界面切了英文就以为字符集也变了。

2.4 实在没有图形界面：静默安装的响应文件

有些环境确实给不了图形界面，比如只有字符界面的测试机。这时候不要硬折腾 X，直接走静默安装。核心是准备一份响应文件，把原本在界面上点选的选项全部写进去：

# response/db_install.rsp 关键段落，其余保持默认 UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory SELECTED_LANGUAGES=en,zh_CN ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 ORACLE_BASE=/u01/app/oracle oracle.install.option=INSTALL_DB_SWONLY INSTALL_DB_AND_CONFIG=false ORACLE_EDITION=EE ORACLE_HOSTNAME=db01.localdomain

oracle.install.option=INSTALL_DB_SWONLY对应界面上的“只安装软件”，装完再用 DBCA 单独建库，和图形安装路径完全一致。ORACLE_EDITION填EE是企业版。ORACLE_HOSTNAME必须和hostname命令的输出一致，不一致会在检查阶段报主机名解析失败。

执行方式：

# 用响应文件静默安装，日志会实时打印，出错时看最后 50 行定位 ./runInstaller -silent -responseFile /home/oracle/response/db_install.rsp \ -ignorePrereq -waitforcompletion

-ignorePrereq是跳过前置检查，只在明确知道缺什么、且不影响安装的情况下用，正常首次安装不要加。-waitforcompletion让命令阻塞到安装结束，方便脚本里判断退出码，不加的话它会后台跑，容易误判成失败。

3. 安装介质与路径：INS-32025、找不到文件与 Inventory 权限

图形界面走通之后，第二个大坑在介质和目录上。11gR2 分两张盘，很多人图省事只解压了第一张，或者两张解到了不同目录，安装进行到某个组件时突然报“找不到文件”。这类错误的特点是：报错位置和真正的原因相隔很远，看到报错时已经装了十几分钟。

3.1 两张盘要解到同一个目录：中途报“找不到文件”的根因

安装程序在运行过程中会从stage/Components下按需读取组件包，这些包分散在两份介质里。如果只解压了第一张，第一阶段能顺利走完，到选择组件时才开始报错，日志里类似INS-32025或者直接抛出某个.jar路径不存在。

正确的做法是把两张盘解压到同一个父目录，让它们的内容合并：

# 建一个统一的解压目录 mkdir -p /u01/soft/database # 第一张盘解压进来 unzip linux.x64_11gR2_database_1of2.zip -d /u01/soft/database/ # 第二张盘解压到同一个目录，遇到重复询问时选择覆盖目录结构 unzip linux.x64_11gR2_database_2of2.zip -d /u01/soft/database/ # 验证：stage/Components 下应该有两张盘各自的组件目录 ls /u01/soft/database/database/stage/Components | wc -l

第三个命令是验收动作。只解一张盘时这个数字会明显偏小，解全之后组件目录数量会翻倍。安装前花十秒看一眼，能省掉半小时重装。

如果目录已经解错了，不要试图删掉重解导致半途而废的安装——先把u01/app/oracle和u01/app/oraInventory清掉，再重新解压、重新跑runInstaller。Oracle 的安装程序对残留目录很敏感，上一次的半成品会让下一次报INS-32025: The chosen installation conflicts with software already installed in the given Oracle home。

3.2 Inventory 目录与 oraInst.loc：oinstall 组、属主和权限

安装走到第 12 步左右会要求填 Inventory Directory，界面上的默认值通常是/u01/app/oraInventory。这个目录存的是 Oracle 软件的清单信息，权限错了后面所有脚本都会失败。

必须满足三条：属主是oracle:oinstall，目录权限 755 以上，路径所在的分区有足够空间。检查命令：

# 建目录并设属主，注意用 oracle 用户所属的主组 oinstall mkdir -p /u01/app/oraInventory chown -R oracle:oinstall /u01/app/oraInventory chmod -R 775 /u01/app/oraInventory # 确认 oraInst.loc 指向了正确的清单目录 cat /etc/oraInst.loc # 期望内容： # inventory_loc=/u01/app/oraInventory # inst_group=oinstall

/etc/oraInst.loc是个容易被忽略的文件。如果之前装过别的 Oracle 产品，或者手工拷贝过环境，这个文件可能指向一个已删除的旧路径，安装程序读不到就会报权限错误或者直接跳过清单初始化。发现路径不对，直接改这个文件，两行内容，改完再装。

权限问题上还有一个细节：/u01这一层如果是 root 建的、权限 755，oracle 用户在里面创建子目录是没问题的；但如果/u01被设成了750且属主不是 oracle 所属组，第一步 mkdir 就会失败。遇到“无法创建目录”的报错，往上逐层ls -ld看权限，别只盯着最里层。

3.3 ORACLE_BASE 与 ORACLE_HOME：路径规划错了后面全是坑

路径规划看着是小事，实际上是后面所有问题的源头。11gR2 的标准分层是：

关键约束是ORACLE_HOME必须位于ORACLE_BASE之下，且路径里不要出现空格、中文、大小写混用。这一点在界面上不会强校验，填错了照样能装完，但后面dbca建库、netca配监听时会因为路径解析问题报各种莫名其妙的错。

另一个常见误操作是把ORACLE_HOME直接设成/u01/app/oracle，和ORACLE_BASE同名。这种配置在单实例下勉强能跑，但一旦要装第二个实例或者打补丁，清单会混乱到无法收拾。从第一次安装就按标准三层结构来，不要图省事压平。

4. 前置检查红叉：包的缺失、内核参数与 root.sh 执行失败

走到安装检查那一步，界面上会列出十几项检查结果，有的打勾有的打叉。这一屏是整场安装里信息量最大的地方，但也是最容易被“先忽略试试”糊弄过去的地方。我的经验是：红叉分两类，一类可以忽略，一类忽略之后一定在更靠后的步骤炸出来，而且报错和原因完全对不上。

4.1 先找到那份检查报告，别对着界面猜

OUI 界面上只显示一行简短描述，完整原因在日志里。安装过程中会生成一个临时目录，路径形如/tmp/OraInstall20240101_101010/，里面有installActions*.log和oraInstall*.err。安装结束后，同样的日志会被归档到oraInventory/logs下。

# 找到本次安装的日志目录 ls -dt /tmp/OraInstall* | head -1 # 直接在日志里搜检查项，PRVF 前缀的是前置检查 grep -i "prvf\|check failed\|not found" /tmp/OraInstall*/installActions*.log | head -20

PRVF是 pre-requisite validation failure 的缩写，打出这些行之后基本就能对上是缺包、缺内存还是参数不对。养成先看日志再动手的习惯，比在界面上逐条猜快得多。

4.2 package 缺失与 swap 不足：哪些能忽略，哪些不能

11gR2 依赖的包不算多，但漏一个就可能在检查阶段红一片。批量核对比逐个rpm -q高效：

# 逐个核对 11gR2 必需包，MISS 的就是要补的 for pkg in binutils compat-libstdc++-33 elfutils-libelf elfutils-libelf-devel \ gcc gcc-c++ glibc glibc-common glibc-devel libaio libaio-devel \ libgcc libstdc++ libstdc++-devel make sysstat unixODBC unixODBC-devel; do rpm -q "$pkg" >/dev/null 2>&1 && echo "OK $pkg" || echo "MISS $pkg" done

输出里出现MISS的行，用yum install -y 包名补齐即可。注意compat-libstdc++-33在较新的发行版仓库里可能已经改名，找不到时先yum search libstdc++看看对应版本。

swap 检查是另一个高频红叉。官方建议 swap 大小和物理内存挂钩，内存 2G 到 8G 之间时 swap 建议等于内存大小。检查：

free -m # 看 Swap 那一行，为 0 或者明显偏小时需要补

如果机器上确实没配 swap，检查会报错但允许忽略。我的建议是不要忽略，因为 11gR2 的内存分配器在建库阶段会申请较大的共享内存段，swap 太小容易在建库时直接 OOM 杀掉进程，报错信息只有一句 ORA-27102，排查起来很费劲。临时补一个 swap 文件：

# 建一个 4G 的 swap 文件并启用 dd if=/dev/zero of=/swapfile bs=1M count=4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 写入 /etc/fstab 保证开机生效 echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

4.3 内核参数与 ORA-27125：shmmax、sem 和 limits.conf

内核参数是检查项里最容易被“忽略”按钮放过去、然后在建库阶段以 ORA-27125 形式炸出来的东西。ORA-27125 的完整信息是unable to create shared memory segment，根因就是kernel.shmmax或kernel.shmall太小。

推荐配置写进/etc/sysctl.conf：

# Oracle 11gR2 推荐值，物理内存 8G 以内基本通吃 kernel.shmmax = 4294967295 kernel.shmall = 1073741824 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 fs.file-max = 6815744 fs.aio-max-nr = 1048576 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生效。kernel.shmmax的单位是字节，4294967295 约等于 4G 减 1，是 32 位时代的经典值，64 位机器上按物理内存的一半设置也可以，但不要超过物理内存。kernel.sem四个数字分别是SEMMSL SEMMNS SEMOPM SEMMNI，写成一行，中间用空格分隔，写错分隔符会直接导致 sysctl 加载失败。

同时要配 oracle 用户的资源限制，写进/etc/security/limits.conf：

oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240

这里有个细节：limits.conf对通过 SSH 登录的会话生效，但对su - oracle这种切换方式不一定生效——取决于 PAM 配置。判断方法是切过去之后执行ulimit -n，看输出是不是 65536。如果不是，说明限制没进去，需要检查/etc/pam.d/su里有没有启用pam_limits.so。

4.4 root.sh 执行报错与环境变量没生效

安装到最后，OUI 会弹出一个小窗口，要求用 root 执行两个脚本：oraInstRoot.sh和root.sh。路径通常在$ORACLE_HOME下。这一步的报错往往是环境问题导致的。

# 用 root 执行，注意顺序：先 oraInstRoot.sh 再 root.sh /u01/app/oraInventory/oraInstRoot.sh /u01/app/oracle/product/11.2.0/db_1/root.sh

root.sh执行时会提示输入ORACLE_HOME之外的本地 bin 目录，直接回车走默认/usr/local/bin即可。它做的事情是把dbhome、oraenv、coraenv这几个脚本软链到系统路径，并初始化/etc/oratab。失败最常见的原因是/usr/local/bin不可写，或者之前装过 Oracle 残留了同名软链。

环境变量这一块，很多人是在当前 shell 里export一遍就开始装，装完关掉终端全丢。正确做法是写进~/.bash_profile：

# ~/.bash_profile 追加，注意 ORACLE_SID 要和后面建库时填的服务名一致 export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

改完source ~/.bash_profile，然后执行env | grep ORA确认四个变量都在。LD_LIBRARY_PATH特别关键，缺了它sqlplus会报error while loading shared libraries: libclntsh.so，这个报错看上去像是库文件丢失，其实就是路径没配。

5. 装完连不上：监听、建库与环境变量的避坑清单

装完软件不代表能用。11gR2 把软件安装和数据库创建拆成了两步，中间还夹着监听配置。这三步里任何一步的配置不一致，表现出来的结果都是同一个：sqlplus连不上。下面这几条是我和身边人反复踩过的，按“现象 → 原因 → 解决”整理。

5.1 ORACLE_SID 对不上，dbca 建完库 sqlplus 也进不去

现象：dbca显示建库成功，紧接着执行sqlplus / as sysdba，报ORA-01034: ORACLE not available和ORA-27101: shared memory realm does not exist。

原因：dbca建库时填的“全局数据库名 / SID”和~/.bash_profile里的ORACLE_SID不是同一个值。sqlplus / as sysdba走的是操作系统认证，它按ORACLE_SID去找共享内存段，找不到就报 27101。这是最典型的“两个配置项各写各的”。

解决：建库前先把ORACLE_SID定死，dbca里填写时逐字对照。建完用下面两条验证：

# 确认当前 shell 认的 SID echo $ORACLE_SID # 确认实例真的起来了 ps -ef | grep pmon # 输出里应该有一行 ora_pmon_orcl，orcl 必须和上面的 SID 一致

如果pmon进程存在但sqlplus还是连不上，多半是ORACLE_SID大小写问题——Oracle 的 SID 在多数场景下不区分大小写，但在/etc/oratab和环境变量里混用会导致oraenv找错条目。

5.2 netca 起不来监听：1521 端口与 hosts 解析

现象：netca执行后走完向导，lsnrctl status却报TNS-12541: TNS:no listener，或者直接TNS-12560: TNS:protocol adapter error。

原因通常有两个。一是/etc/hosts里没有把主机名解析到本机 IP，监听器启动时要绑定地址，解析不到就起不来；二是 1521 端口被占用，或者防火墙挡了外部访问（本地lsnrctl status一般不受防火墙影响，但客户端连不上会先怀疑监听）。

解决：

# 1. 确认主机名能解析到本机地址 hostname grep "$(hostname)" /etc/hosts # 期望有一行形如 192.168.1.20 db01.localdomain db01 # 2. 确认端口没被占 netstat -tlnp | grep 1521 # 3. 手动起监听并看详细输出 lsnrctl start lsnrctl status

lsnrctl status的输出里会列出监听地址和已注册的服务。如果服务列表是空的但监听是 running，说明数据库实例还没注册上去，等几十秒或者执行alter system register;手动注册。

5.3 字符集选错，中文写进去变成问号

现象：建库时字符集选了默认值，之后往表里插中文，查出来全是???。

原因：dbca建库向导里字符集那一屏如果没手动改，默认可能是WE8MSWIN1252或WE8ISO8859P1，这两个都不支持中文。安装时正文里明确写了要选 UTF-8，对应到 11gR2 里就是AL32UTF8。

解决：如果库刚建、还没数据，直接删库重来最省事。已经跑起来有数据的，改字符集要通过ALTER DATABASE CHARACTER SET或者导出重建，代价大得多。验证当前字符集：

-- 登录后查询数据库字符集 select parameter, value from nls_database_parameters where parameter in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

NLS_CHARACTERSET应该是AL32UTF8。同时NLS_LANG环境变量要和它匹配，结尾那段写成AL32UTF8，两处一致才不会出现“库里存对了、客户端显示乱码”的情况。

5.4 环境变量只写在当前 shell 里，重开终端就丢

现象：装完之后一切正常，第二天重新登录，sqlplus提示 command not found。

原因：安装时是临时export的，没有写进 shell 的启动文件，或者写进了.bashrc但用的是非交互式登录（su - oracle读的是.bash_profile）。

解决：统一写进~/.bash_profile，并且确认登录方式读的是这个文件。验证方法很直接——退出当前会话，重新ssh登录一次，执行which sqlplus，能输出路径就说明生效了。如果输出空，echo $PATH看有没有$ORACLE_HOME/bin，没有就是启动文件没被读。

5.5 装到一半中断：怎么清干净再重装

现象：安装过程中断（断网、磁盘满、手误关闭），重新跑runInstaller报INS-32025，或者卡在某个步骤无限等待。

原因：ORACLE_HOME和oraInventory里有上次的残留，安装程序检测到非空目录就拒绝继续。

解决：彻底清空再重来。

# 停掉可能残留的进程 ps -ef | grep -i oracle | grep -v grep # 确认没有 pmon/tnslsnr 之后，删除安装目录 rm -rf /u01/app/oracle/product/11.2.0/db_1 rm -rf /u01/app/oraInventory # 如果有残留的 oraInst.loc，一并处理掉再重新初始化 rm -f /etc/oraInst.loc /etc/oratab

删除前务必确认这几个目录里没有别的东西，尤其/etc/oratab如果被别的实例共用，删掉会导致已有实例的oraenv失效。清理完重新解压介质、重新跑runInstaller，不要在残留目录上强行续装。

6. 快速定位：两分钟判断卡在哪一层

装到后面你会发现，11gR2 的报错有个共同特点：报错位置和真正原因相隔一到两个步骤。所以快速定位的核心不是记住所有错误码，而是按层排除。

我一般按这个顺序过一遍，基本两分钟内能确定是哪一层的问题：

搭配两个动作一起用。第一个是看pmon进程：只要ps -ef | grep pmon的输出里有ora_pmon_实例名，说明实例层面是活的，问题在客户端连接或监听上；没有这个进程，问题在实例启动或 SID 配置上。第二个是看日志尾部：安装阶段的日志在/tmp/OraInstall*/，建库阶段的日志在$ORACLE_BASE/cfgtoollogs/dbca/，出问题先tail -50，比在界面上逐条点“忽略”有用得多。

还有一个习惯值得养：每改一处配置（sysctl、limits.conf、.bash_profile），改完立刻验证一遍再往下走。sysctl -p之后sysctl kernel.shmmax看一眼实际生效值，source之后env | grep ORA看一眼变量——很多“明明配了还是报错”的情况，都是配置文件写对了但没生效，或者生效在另一个用户下。

从那以后我每次装 11gR2，跑runInstaller之前都会强制走一遍三件事：确认xa通道、清点包缺失、核对 SID 和字符集。这三步花不了五分钟，但能挡掉后面绝大多数返工。希望帮到你。

本文还有配套的精品资源，点击获取