简介：一份面向Linux平台数据库运维人员与Oracle初学者的11gR2安装图解文档，聚焦单机环境部署，围绕依赖包检查、用户与组创建、环境变量配置、安装程序启动、Inventory目录指定、安装检查日志解读、root脚本执行、监听配置及数据库配置助手建库等关键环节展开，适合需要按图操作并理解安装逻辑的初中级技术人员。压缩包共1个doc文件，约1.73MB，文档将系统准备、软件安装与建库配置分阶段说明，以图文步骤串联从前期准备到数据库创建完成的流程，并对虚拟机分辨率、依赖缺失、空间不足、服务名与ORACLE_SID一致、UTF-8字符集选择等易错点作出提示，便于在本地或测试环境中逐步实践、对照排查与复盘。已有134人学习，可作为Oracle 11gR2安装过程的操作参考与过程记录。
1. 一台老业务机上的 Oracle 11gR2：为什么还要在 Linux 上手工装一遍
去年冬天接手一台跑某行业管理系统的老服务器，硬盘上只有一个 oracle 用户和一个 orcl 实例，谁装的、装到哪一步、改过哪些参数，全都没有记录。数据库崩掉之后要原地重装，翻遍内部文档，只剩一份「Linux 下安装 Oracle 11gR2 详细图解」能对照着做。这份资料的定位很明确：面向在 Linux 上做单机部署的运维和 DBA，从建用户、装依赖包，一路带到跑完 netca、dbca。它解决的是「手上只有一台干净系统，怎么把单实例库装起来并连得上」，而不是「怎么学 Oracle」。适合的人也窄：要维护存量 11gR2 环境，或者需要在隔离网里搭一套和老系统一致的测试库的人。新项目选型不必再考虑 11gR2，但接盘老系统时，这几步一个都躲不掉。
2. 装之前把地基打平：依赖包、内核参数与 oracle 用户环境
runInstaller本身并不难，难的是它在启动前那几分钟的检查——缺一个 libaio、shmmax少写一个零，安装器多半不会当场报错，而是把问题拖到链接阶段或者实例启动阶段才炸出来。所以这一章按「系统层 → 内核层 → 用户层」三层推进，每一层都给可抄的命令，装完再往下走。
2.1 依赖包：缺一个 libaio 能让安装器卡在链接阶段
11gR2 对包的依赖属于「少一个就活不下去」的类型。最常见的组合是一批编译工具链加几个运行库，其中compat-libstdc++-33和libaio这两块最容易漏——前者在较新的发行版默认仓库里已经改名或者被裁剪，后者在最小化安装的系统上压根没装。我一般会先把清单一次性补齐：
# 一次性补齐 11gR2 单机安装需要的最小依赖集合 yum install -y binutils \ compat-libstdc++-33 \ compat-libcap1 \ elfutils-libelf elfutils-libelf-devel \ gcc gcc-c++ make \ glibc glibc-common glibc-devel glibc-headers \ libaio libaio-devel \ libgcc libstdc++ libstdc++-devel \ libXp libXt libXtst \ sysstat unixODBC unixODBC-devel这段命令里，glibc-devel和gcc是给安装过程中编译 PL/SQL 原生组件用的，缺了会在链接阶段报cannot find -lclntsh；libaio和libaio-devel支撑异步 I/O，缺了实例能起来但后台会持续刷ORA-27302；libXp、libXt、libXtst这一组只有跑图形界面时才需要，用静默安装可以省掉；unixODBC-devel是给后续接异构数据源留的口子，现在不装，以后补装还得重新链接。compat-libcap1在部分新发行版上确实找不到，yum 直接报No package available，这种情况跳过就行，不影响单机安装。
装完不要凭感觉，用 rpm 反过来核一遍，把缺失项打出来比人眼扫快得多：
# 逐个核对，只输出没装上的包名 for p in binutils compat-libstdc++-33 gcc gcc-c++ glibc-devel \ libaio libaio-devel libstdc++-devel make sysstat unixODBC-devel; do rpm -q "$p" >/dev/null 2>&1 || echo "缺失: $p" done这里的rpm -q只做查询不做安装，返回非零就说明这个包名在当前系统上不存在。注意包名和实际安装的 RPM 名可能不一致，比如装了libstdc++-devel之后查compat-libstdc++-33依然是缺失，这不是命令写错，是两个包本来就不是一回事。
2.2 内核参数与 limits.conf：shmmax 到底该按什么算
共享内存这块是最容易被「抄参数」抄出问题的地方。网上流传的一份 sysctl 配置到处被复制，但里面的kernel.shmmax往往是某个特定内存规格机器上的值，换台机器直接不匹配。正确的做法是先看物理内存和页大小，再决定数值。
# 先确认两个基数：物理内存字节数、系统页大小 free -b | awk '/Mem:/{print "物理内存字节:", $2}' getconf PAGE_SIZE # /etc/sysctl.conf 追加以下内容（数值按上面两个基数换算） fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.shmall = 2097152 kernel.shmmax = 4294967296 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参数之间的关系必须说清楚，否则改完还是错：
| 参数 | 含义 | 取值方法 |
|---|---|---|
kernel.shmmax | 单个共享内存段的最大字节数 | 取物理内存的一半，但不能超过系统上限；32 位系统上不去 4G |
kernel.shmall | 所有共享内存段合计的页数 | shmmax / PAGE_SIZE，注意单位是页不是字节 |
kernel.shmmni | 共享内存段的最大个数 | 一般 4096 够用，SGA 拆分多的时候才需要调 |
kernel.sem | 信号量四元组 | 250 32000 100 128是 11gR2 的推荐值，别只写前三项 |
fs.aio-max-nr | 异步 I/O 事件上限 | 1048576，低于这个值实例启动时会警告 |
shmall和shmmax单位不同这一点，是踩过的坑：shmmax写字节，shmall写页数。如果页大小是 4096、shmmax是 4G，那shmall至少得是 1048576，写 2097152 留了一倍余量，属于比较稳妥的做法。
紧接着是文件句柄和进程数限制，这一块 11gR2 的安装器不会直接检查，但实例跑起来之后会咬人：
# /etc/security/limits.conf 追加 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768顺手确认/etc/pam.d/login里有session required pam_limits.so这一行。少了它，limits.conf写得再对也不生效，表现就是登录之后ulimit -n还是 1024。另外注意新一点的发行版会在/etc/security/limits.d/下放一个20-nproc.conf，它会在limits.conf之后加载并覆盖同名条目，nproc被改回去多半是这个原因，改完记得顺手看一眼。
改完统一生效：
sysctl -psysctl -p会把/etc/sysctl.conf重新读一遍，输出里每个键值都应该和你写的一致，有不一致的说明被别处的配置覆盖了。
2.3 oracle 用户、组与环境变量：ORACLE_SID 从这一步就定死
用户和组这一步没什么技术含量，但它的结果会被后面所有环节引用，包括root.sh往oratab里写的路径、dbca建库时读的 SID。所以顺序是：先建组，再建用户，再建目录，最后写环境变量。
# 组和用户：oinstall 是软件属主组，dba 是实例管理组，两个都要 groupadd -g 54321 oinstall groupadd -g 54322 dba useradd -u 54321 -g oinstall -G dba -m -s /bin/bash oracle # 目录：ORACLE_BASE 和 ORACLE_HOME 的上级目录一次建好 mkdir -p /u01/app/oracle/product/11.2.0/dbhome_1 chown -R oracle:oinstall /u01 chmod -R 775 /u01 # 密码单独交互设置，不要写进脚本 passwd oracleuseradd里的-g oinstall是主组、-G dba是附加组，两个都要给。oinstall决定软件文件属于谁，dba决定谁能用sysdba身份连库，缺了dba的话后面sqlplus / as sysdba会直接报权限不足。
环境变量写在oracle用户的~/.bash_profile里，注意ORACLE_SID在这个阶段就要定下来，因为后面dbca建库时会要求 SID 和它一致：
# ~/.bash_profile（oracle 用户） export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export DISPLAY=:0.0ORACLE_HOME里那一层dbhome_1不是随便写的，它是 11gR2 安装器默认生成的目录名，手工提前建好可以让安装器直接选中。LD_LIBRARY_PATH里的/lib:/usr/lib是兜底，防止$ORACLE_HOME/lib下某个符号找不到时整个进程起不来。NLS_LANG用AL32UTF8是为了让客户端字符集和服务端对齐，后面建库选字符集时如果不一致，中文就会变成问号。
还有一处不在 Oracle 文档里、但每次都会出问题的地方：/etc/hosts里必须有主机名到 IP 的解析。11gR2 的监听器启动时会解析主机名，如果只写了127.0.0.1而没写实际 IP，netca生成监听配置时会把地址写成回环地址，外面就连不上。
# /etc/hosts 示例，主机名必须是 hostname 命令输出的那个 127.0.0.1 localhost localhost.localdomain 192.168.10.20 dbhost dbhost.local这里的dbhost来自hostname的实际输出，两边必须完全一致。改完/etc/hosts之后建议用hostname -i验一下，能返回192.168.10.20就对了。
3. runInstaller 的图形界面走位：从解压到 root.sh 的完整路径
环境配完，安装过程本身反而是最省事的一段。但省事的前提是前面每一步都对——11gR2 的安装器有个特点，先决条件检查这一屏会把所有问题攒在一起报出来，检查项过了，后面基本一路 Next。这一章按「解压 → 交互选择 → root.sh」三段走，重点放在几个真正需要动脑的选项上。
3.1 两个压缩包解压到同一目录：目录结构对不对一眼能看出来
11gR2 的介质拆成两个压缩包，必须解到同一个父目录下，这是安装过程中「找不到文件」类错误的头号来源。解压完的正确结构是database/下同时有install/、stage/、runInstaller三样东西，stage/Products.xml之类的元数据在第二个包里，少了就会在安装中段报Unable to find the file。
# 两个包解到同一个父目录，-d 指定的是父目录不是子目录 mkdir -p /u01/soft chown -R oracle:oinstall /u01/soft unzip -q linux.x64_11gR2_database_1of2.zip -d /u01/soft/ unzip -q linux.x64_11gR2_database_2of2.zip -d /u01/soft/ # 验证：三样东西必须同时存在 ls /u01/soft/database/ # 期望看到 runInstaller install/ stage/ response/ rpm/ ...-q是静默解压，避免几万行文件名刷屏。-d /u01/soft/里的尾斜杠建议统一加上，防止两个包解到/u01/soft和/u01/soft2这种不一致的位置。验证那一步别看文件名差不多就放过去，install/和stage/缺任一个都是第二个包没解全的表现。
解压完把目录属主改给oracle，安装器运行时会往stage/下写临时日志，用 root 解压后不给权限，安装器会直接闪退且不给任何提示。
3.2 交互流程里真正要动脑的只有四个选择
以oracle用户身份进图形界面启动安装器：
# 切到 oracle 用户，进入解压目录启动 su - oracle cd /u01/soft/database ./runInstaller如果界面显示不全，先把分辨率调到 1024×768 以上；虚拟机环境里显示不全通常是缺少图形驱动支持，把窗口模式切一下基本能解决。整个流程大部分是 Next，真正需要判断的只有下面几处：
| 界面步骤 | 建议选择 | 为什么这么选 |
|---|---|---|
| 配置安全更新 | 取消勾选 | 内网环境无法外联，勾了只会在检查阶段卡住 |
| 安装选项 | 仅安装数据库软件 | 软件和库分开做，建库失败不用重装软件 |
| 系统类 | 单实例数据库安装 | 非 RAC 场景，选错后面会多出一堆集群检查项 |
| 产品语言 | 英文 + 简体中文 | 英文日志便于对照检索，中文界面便于核对提示 |
| 数据库版本 | 企业版 | 分区表、并行查询这些特性只有企业版有 |
| 安装位置 | 与ORACLE_HOME一致 | 和.bash_profile里写的必须一字不差 |
| 清单目录 | /u01/app/oraInventory | 与ORACLE_BASE分开，重装软件时不用动它 |
| 操作系统组 | oinstall（清单）/dba（数据库） | 与建用户时给的组对上 |
| 先决条件检查 | 忽略并继续 | 检查项会写进日志，装完再回头核对 |
「仅安装数据库软件」这一项值得多说一句。安装器在这里给的两个选项，一个是软件加库一起装，一个是只装软件。选后者的好处是把「软件安装」和「建库」两件事解耦——软件装坏了重装一次十几分钟，库建坏了用dbca删掉重建也就几分钟。生产环境按这个顺序做，出问题时的回滚成本低很多。
先决条件检查那一屏会给出所有检查项的结果，缺包、内存不足、内核参数不对都会在这里列出来。当时我那台机器因为内存低于推荐值报了警告，这个可以忽略；但如果是缺 package 或者shmmax不够，建议退回去补完再继续，别硬闯。全部检查项的结果会落在/u01/app/oraInventory/logs/下，文件名带时间戳，装完之后有问题回头翻这一份比翻屏幕截图靠谱。
点 Finish 进入真正的文件复制和链接阶段，这一步耗时取决于磁盘，SSD 上大概十分钟出头。结束后会弹出一个对话框，提示用 root 执行两个脚本。
3.3 root.sh 与安装后校验：别急着点 Close
弹窗里的两个脚本有先后顺序，先oraInstRoot.sh再root.sh，两个都以 root 身份执行：
# root 身份执行，注意先用 root.sh 前先确认路径 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/11.2.0/dbhome_1/root.shorainstRoot.sh干的事是把清单目录的权限改成oinstall:dba 775，并写/etc/oraInst.loc指向清单位置。root.sh干的事更多：写/etc/oratab、给部分可执行文件加 suid 位、配置/etc/init.d下的启停脚本。所以这两个脚本必须以 root 执行，以 oracle 身份跑会静默跳过大部分内容，表面上不报错，后面netca起不来才发现问题。
执行完别急着关窗口，先做三项校验：
# 1. oratab 里应该有刚装的实例条目 grep -v '^#' /etc/oratab # 2. 软件版本能打印出来 su - oracle -c "\$ORACLE_HOME/bin/sqlplus -V" # 3. 清单注册信息能列出来 su - oracle -c "\$ORACLE_HOME/OPatch/opatch lsinventory | head -20"/etc/oratab里那一行的格式是SID:ORACLE_HOME:Y/N，末尾的Y表示允许dbstart自动拉起，装完默认是N，按需改。sqlplus -V能输出Release 11.2.0.x.0就说明软件层已经完整；opatch lsinventory能列出 patch 信息说明清单注册成功，后面打补丁全靠它。
这一步全过了，软件安装就算结束。接下来是监听和建库，那是另外两件事，放到后面单独讲。
4. 避坑与排查：装 Oracle 11gR2 最常见的五个翻车点
11gR2 的报错有个共性：现象和原因隔得很远，报错信息还偏笼统。下面这五条是我在不同机器上真遇到过、并且每次重装都要重新确认一遍的东西，按「现象 → 原因 → 解决」写，遇到类似的直接对号入座。
4.1 现象：安装界面只显示半屏、按钮点不到
现象：./runInstaller能起来，但窗口只占屏幕左上角一小块，底部的 Next 按钮直接看不见，拖也拖不动。
原因：安装器对分辨率有最低要求，低于 1024×768 时会按固定尺寸绘制窗口而不做自适应。虚拟机里默认的 800×600 正好卡在这个坎上，而且虚拟机的显示驱动没装全的话，改分辨率也不生效。
解决：先把分辨率调到 1024×768 或更高。虚拟机环境里如果调不动，说明图形驱动缺组件，装上对应的增强工具再重启。还有一种更省事的做法是完全绕开图形界面，用响应文件做静默安装：
# 静默安装，跳过所有图形交互 ./runInstaller -silent -ignorePrereq \ -responseFile /u01/soft/database/response/db_install.rsp \ -waitforcompletion-ignorePrereq是忽略先决条件检查里失败的那些项，第一次装不建议直接加，先看检查结果。-waitforcompletion让命令在前台阻塞到安装结束，否则它会立刻返回，后面脚本跑起来找不到软件目录。响应文件里的ORACLE_HOSTNAME、ORACLE_BASE、ORACLE_HOME、oracle.install.db.config.starterdb.type这几项必须改，其余按默认走。
4.2 现象：先决条件检查报缺包，但 yum 说已经装了
现象：检查页列出七八个包「未安装」，按提示yum install之后重跑安装器，报的还是同一批。
原因：安装器检查的是 RPM 的精确包名和架构，yum install libstdc++-devel装上的可能是更新版本的包，包名变了但功能在，安装器认不出来。32 位兼容包缺失在 64 位系统上也属于这一类。
解决：先用rpm -qa | grep确认实际装上的包名，再判断能不能放行。功能上确实不缺的，直接选「忽略并继续」，检查结果会写进日志，事后能查到忽略了哪几项。真正缺的（比如libaio完全没装上）不能忽略，那会在实例启动阶段变成ORA-27302，排查起来比现在麻烦得多。
4.3 现象：root.sh 执行到一半报错退出
现象：以 root 执行root.sh，前几行正常，中间突然报Failed to create /etc/oratab，或者提示某个文件 permission denied。
原因：多半是$ORACLE_HOME的属主不对。前面如果用 root 解压并把文件留在了 root 名下，root.sh里的部分操作会以 oracle 身份回写文件，权限对不上就中断。另一个原因是root.sh被重复执行过，第二次跑的时候/etc/oratab已存在，脚本某些分支会直接报错退出。
解决：先确认属主，ls -ld $ORACLE_HOME应该显示oracle:oinstall：
# 属主不对的话整体改回来，再重新执行 root.sh chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u01/app/oracle /u01/app/oracle/product/11.2.0/dbhome_1/root.sh重复执行的情况不用慌，root.sh本身有一定幂等性，第二次跑会把已有条目跳过。真正要确认的是/etc/oraInst.loc的内容指向了正确的清单目录，这个文件错了后面opatch全部失效。
4.4 现象：以 root 身份跑 netca / dbca 起不来
现象：按某些资料的写法，装完之后切到 root 直接跑netca，窗口一闪就没了，终端里只有一行Xlib: connection refused或者干脆什么都不打印。
原因：netca和dbca都是 Oracle 自带的图形程序，它们读的是当前用户的环境变量。root 用户下没有ORACLE_HOME、LD_LIBRARY_PATH、DISPLAY，程序找不到库也找不到显示目标，自然起不来。而且就算能起来，以 root 创建的监听配置文件和数据库文件属主会是 root，后续 oracle 用户读写全部受限。
解决：这两个工具必须以 oracle 身份、在图形环境下运行，root 只负责执行root.sh，不碰这两个工具。正确的调用方式是：
# 以 oracle 身份，在带图形环境的会话里执行 su - oracle export DISPLAY=:0.0 # 本地图形界面；远程则改成 客户端IP:0.0 $ORACLE_HOME/bin/netca # 配置监听器 $ORACLE_HOME/bin/dbca # 创建数据库DISPLAY的值取决于你是本地终端还是远程连进来的。远程场景下需要在客户端侧允许 X11 转发，并且DISPLAY要写成客户端的 IP 加显示号。这一步如果折腾不通，netca和dbca都支持静默模式（-silent -responseFile ...），命令行参数和图形界面一一对应，反而更可控。
4.5 现象：库建好了，插中文变问号
现象：dbca建库一路顺利，sqlplus连进去insert一条中文，再select出来是???。
原因：字符集在建库那一刻就定死了，之后改库字符集基本等于重建。建库时如果选了默认字符集（通常是WE8MSWIN1252或AL32UTF8之外的某个单字节集），中文直接存不进去。另一个常见原因是客户端NLS_LANG和服务端字符集不一致，数据存进去了但显示成乱码。
解决：建库时字符集选AL32UTF8，这个在dbca的最后几屏里，默认值不是它，必须手动改。已经建错的话，用dbca删库重建比改字符集快得多：
# 确认服务端实际字符集 sqlplus -S / as sysdba <<'EOF' select parameter, value from nls_database_parameters where parameter in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET'); EOF输出里NLS_CHARACTERSET应该是AL32UTF8。客户端侧则确认NLS_LANG的第三段与之一致，AMERICAN_AMERICA.AL32UTF8对应服务端的AL32UTF8，两边对齐之后中文才不会在传输层被二次编码。
5. netca 与 dbca 的收尾技巧：把 SID、服务名和字符集一次对齐
软件装完只是半成品，能不能连、连上之后中文对不对，全看监听和建库这两步。这两件事单独看都不复杂，但它们共享同一批标识符——SID、服务名、字符集——任何一个对不上，后面排查起来都要绕一大圈。
5.1 监听器：netca 生成的 listener.ora 什么时候需要手改
netca走完默认流程，会在$ORACLE_HOME/network/admin/下生成listener.ora和tnsnames.ora，监听名默认是LISTENER、端口 1521。单机场景下这份默认配置基本够用，唯一值得动的是监听地址。默认配置会监听所有网卡，但如果你在/etc/hosts里没写主机名解析，生成的HOST会是回环地址，外部客户端连不上。
# 启动监听并查看实际监听地址 lsnrctl start lsnrctl statuslsnrctl status的输出里，「监听端点摘要」那一段的HOST就是实际绑定的地址。如果是127.0.0.1或者主机名解析不出来，需要手工把listener.ora里的(HOST = ...)改成实际 IP，然后lsnrctl reload。改完再用tnsping从客户端侧验一次连通性，比在服务端自测有意义。
5.2 建库时把 SID、服务名、字符集三个值钉死
dbca的交互步骤很多，但真正影响后续使用的只有三个值，建议在建库之前就写在纸上：
| 值 | 来源 | 常见错误 |
|---|---|---|
| SID | .bash_profile里的ORACLE_SID | 建库时随手改成别的名字，导致sqlplus / as sysdba连不上 |
| 服务名 | 一般与 SID 相同，也可以不同 | 客户端tnsnames.ora里写的是服务名，两边不一致就连不上 |
| 字符集 | AL32UTF8 | 用默认值，中文丢失 |
SID 和ORACLE_SID一致这一条是硬约束。sqlplus / as sysdba走的是操作系统认证，它会读当前 shell 的ORACLE_SID去找实例，两者不同就会报ORA-01034: ORACLE not available——这个报错的字面意思容易让人以为实例没启动，实际是找错了实例。
5.3 一条从监听状态到中文插入的验证链路
装完之后我固定会跑一条验证链路，从网络层一路验到数据层，四步全过才算这套环境可用：
# 1. 监听状态：确认监听已起、服务已注册 lsnrctl status | grep -E "READY|Service" # 2. 本地连接：走操作系统认证，不依赖监听 sqlplus -S / as sysdba <<'EOF' select instance_name, status from v$instance; exit EOF # 3. 网络连接：走监听，验证客户端配置 sqlplus -S system/密码@orcl <<'EOF' select sysdate from dual; exit EOF # 4. 中文往返：建表、插中文、读回来 sqlplus -S system/密码@orcl <<'EOF' create table t_zh (id number, name varchar2(50)); insert into t_zh values (1, '测试中文'); commit; select * from t_zh; drop table t_zh; EOF四步的失败位置直接指向不同层：第 1 步失败是监听没起或者listener.ora有问题；第 2 步失败是实例没起或者ORACLE_SID不对；第 3 步失败是监听注册或客户端tnsnames.ora的问题；第 4 步只有中文出问题，那就是字符集或者NLS_LANG。这条链路的价值在于把「连不上」这个笼统现象拆成了四个可以独立定位的环节。
血泪经验是第 2 步和第 3 步一定要分开测。很多人图省事直接用sqlplus system/密码@orcl测，一旦失败就分不清是实例的问题还是网络的问题，最后把监听配置改了三遍才发现实例压根没起来。从那以后我每次装完 11gR2，都必须把这条链路从头到尾走一遍才敢交付，宁可多花十分钟，也不要在业务上线当天被叫起来查ORA-12541。希望帮到你。
本文还有配套的精品资源，点击获取
