企业官网建设流程全解析

简介：本资源是一份面向Linux系统管理员与Oracle数据库初学者的实战安装指南，聚焦在CentOS/Red Hat等主流Linux发行版上部署Oracle 11g Release 2单机数据库的全流程图解。内容覆盖从系统环境准备（如gcc、glibc-devel等依赖包安装）、Oracle用户与环境变量配置，到runInstaller启动、Inventory目录设置、监听器netca与数据库dbca创建等关键环节，并特别说明虚拟机分辨率调整、错误日志解读及常见忽略项（如内存/空间不足提示）等实操细节。资源为1个1.73MB的Word文档（.doc），图文并茂，步骤编号清晰，含界面截图与命令行注释，便于边学边练。目前已有133人学习下载，适合需快速落地部署、理解安装逻辑而非仅抄脚本的中级运维与DBA入门者，尤其利于排查安装卡点、建立标准化部署认知。

1. “[INS-30011] The specified Oracle base is not empty” 报错卡死在第一页：别急着删文件，90%的人根本没看懂这个提示在警告什么

你刚解压完linux.x64_11gR2_database_1of2.zip和2of2.zip，cd database && ./runInstaller一敲，图形界面刚弹出来，还没点 Next，就弹出一个红框警告：[INS-30011] The specified Oracle base is not empty。你下意识去/u01/app/oracle看了一眼——空的啊？连目录都没建！再刷新、重开终端、换用户、甚至重启虚拟机……全没用。更玄学的是，有人把整个/u01格了重来，结果安装到第 15 步“系统检查”时又冒出PRVF-7532 : Sufficient space is not available on mount point "/u01"，明明df -h /u01显示还有 20G。这类问题不是配置漏了，也不是权限错了，而是 Oracle 11gR2 安装器自己在“说人话”和“说 Oracle 话”之间反复横跳——它口中的 “Oracle base” 不是你mkdir -p /u01/app/oracle那个路径，而是它内部状态机里一个带校验逻辑的抽象概念；而它报的 “not empty”，往往指的不是目录非空，而是上一次失败安装残留的 inventory 注册信息、或/etc/oraInst.loc里指向了一个已损坏的 oraInventory 路径。我踩过三次这个坑：第一次重装 7 小时，第二次发现是oraInst.loc指向了被rm -rf过半的旧路径却没清注册表，第三次才摸清它底层依赖oracle/install/inventory/ContentsXML/comps.xml的完整性校验。这不是新手手生，是 Oracle 把安装前校验做成了黑匣子，而文档里只写“确保 Oracle base 为空”，却从不告诉你它怎么定义“空”。如果你正被这个红框卡在第一步，别删目录、别改权限、更别重装系统——先停在这里，往下看。

2. Oracle base 与 oraInventory：两个路径，三种状态，一个校验链

Oracle 11gR2 的安装不是“把文件拷进去就完事”，而是一套强状态管理流程：它要同时维护Oracle base（软件根目录）、oraInventory（全局安装注册中心）和ORACLE_HOME（实例运行环境）三者的一致性。三者关系不是父子，而是“注册+引用+挂载”：oraInventory记录所有已安装的 Oracle 产品（包括 11gR2、OPatch、甚至旧版 10g），Oracle base是这些产品的统一存放根目录，ORACLE_HOME则是具体某套软件的绝对路径（比如/u01/app/oracle/product/11.2.0/db_1）。它们的绑定靠两个关键文件维系：/etc/oraInst.loc（声明 oraInventory 位置）和$ORACLE_BASE/oraInventory/ContentsXML/comps.xml（声明该 Inventory 下注册了哪些组件）。一旦其中任一环节断裂或内容损坏，./runInstaller就会在启动瞬间读取失败，直接抛[INS-30011]或[INS-32031] Unable to locate Oracle base。这不是 bug，是设计——Oracle 要确保你不会在同一个系统里混装多个冲突版本，也不会让 DBA 在不知情时覆盖掉生产库的补丁记录。

2.1 检查/etc/oraInst.loc：那个被忽略的“总开关”

这个文件是整个 Oracle 安装生态的入口。它只有两行：

inventory_loc=/u01/app/oraInventory inst_group=oinstall

但它的作用远超字面：inventory_loc告诉runInstaller“去哪找我的安装注册中心”，而inst_group决定了谁有权限读写它。如果这个路径不存在、权限不对、或内容被手动改乱（比如多加了个空格、路径末尾多了/），runInstaller会直接放弃加载 Inventory，转而尝试创建新 Inventory——但创建前它必须校验目标Oracle base是否“干净”，于是就报[INS-30011]。注意：这个文件的权限必须是644，属主必须是root，且inst_group指定的组（如oinstall）必须存在且包含当前安装用户。

提示：执行ls -l /etc/oraInst.loc确认权限和属主；用grep oinstall /etc/group确认组存在；若文件丢失，可手动重建，但必须确保inventory_loc指向一个全新、空、且属主为oinstall组可写的目录，例如：

sudo mkdir -p /u01/app/oraInventory sudo chown root:oinstall /u01/app/oraInventory sudo chmod 755 /u01/app/oraInventory echo "inventory_loc=/u01/app/oraInventory" | sudo tee /etc/oraInst.loc echo "inst_group=oinstall" | sudo tee -a /etc/oraInst.loc

2.2 校验$ORACLE_BASE/oraInventory：不是空目录就行，得是“合法空”

假设/etc/oraInst.loc没问题，runInstaller会去inventory_loc指向的目录下读取ContentsXML/comps.xml。这个 XML 文件是 Inventory 的“户口本”，记录了所有已注册组件的名称、版本、路径。如果该文件损坏（常见于强制中断安装、磁盘满导致写入截断）、或目录结构不完整（比如只有logs/没有ContentsXML/），runInstaller会认为该 Inventory “不可信”，于是拒绝复用，转而要求你指定一个全新的、未被注册过的 Oracle base——但它又不会告诉你“我怀疑你这个 Inventory 坏了”，只冷冷甩一句[INS-30011]。所以，真正的“空”是指：目录存在、权限正确、且ContentsXML/comps.xml是一个格式正确、能被解析的 XML 文件（哪怕里面<COMP>节点数为 0）。

验证方法（以inventory_loc=/u01/app/oraInventory为例）：

# 1. 检查目录是否存在且权限正确 ls -ld /u01/app/oraInventory # 应输出类似：drwxr-x--- 4 root oinstall 4096 ... /u01/app/oraInventory # 2. 检查 ContentsXML 目录及 comps.xml 是否存在 ls -l /u01/app/oraInventory/ContentsXML/ # 必须看到 comps.xml，且大小 > 0 # 3. 尝试解析 comps.xml（验证 XML 格式） xmllint --noout /u01/app/oraInventory/ContentsXML/comps.xml 2>/dev/null || echo "comps.xml 格式错误！" # 若报错，说明 XML 损坏，需重建 Inventory

若comps.xml损坏，不要手动编辑它。正确做法是备份后彻底清理并重建：

sudo mv /u01/app/oraInventory /u01/app/oraInventory.bak sudo mkdir -p /u01/app/oraInventory sudo chown root:oinstall /u01/app/oraInventory sudo chmod 755 /u01/app/oraInventory # 此时再运行 ./runInstaller，它会自动初始化一个干净的 Inventory

2.3 Oracle base 的“空”：不是ls看不到文件，而是runInstaller认为它没被“注册”

很多人以为Oracle base就是ORACLE_BASE环境变量指向的路径（如/u01/app/oracle），只要ls -la /u01/app/oracle返回 nothing 就算空。错。runInstaller判断Oracle base是否“已被占用”，依据是：该路径下是否存在一个有效的oraInventory子目录，且该oraInventory的comps.xml中注册了任何组件。也就是说，即使/u01/app/oracle目录本身是空的，但如果/u01/app/oracle/oraInventory/ContentsXML/comps.xml里写着<COMP NAME="oracle.rdbms" VERSION="11.2.0.1.0"/>，runInstaller就认定此 base “已被使用”，从而报[INS-30011]。这也是为什么你rm -rf /u01/app/oracle后重装仍失败——因为/etc/oraInst.loc还指着/u01/app/oraInventory，而那个 Inventory 里还存着旧注册信息。

解决方案很直接：要么清空oraInventory（见 2.2），要么换一个全新的Oracle base路径，并在安装界面第 10 步“Specify Installation Location”中明确输入，例如/u01/app/oracle_new。注意：新路径的父目录（如/u01/app）必须存在、权限正确（属主oracle，属组oinstall，权限755），且不能是软链接。

3. 内核参数与 package 缺失：日志里写的“忽略”是毒药，不是安慰剂

安装界面第 14 步“Prerequisite Checks”弹出的红色警告框，常被新手当作“Oracle 小题大做”。尤其当它说 “Check complete. Some checks have failed.” 并列出kernel.sem,fs.file-max,net.ipv4.ip_local_port_range等内核参数不达标，或pdksh,sysstat,unixODBC等包缺失时，文档里那句“内存或硬盘空间不足的错误可以直接忽略”像一颗后悔药，让人忍不住点 “Yes, continue”。但血泪经验是：这些检查项里，95% 的后续失败（监听起不来、DBCA 创建库卡死、sqlplus 连接报 ORA-12547）都源于此处被“忽略”的某一项。Oracle 不是矫情，是它的后台进程（oraagent.bin,tnslsnr,oracle二进制）在启动时会硬性读取这些参数值，一旦超出预设阈值或找不到依赖库，进程直接exit(1)，连日志都不写全。所谓“忽略”，只是让安装器跳过校验继续走流程，但问题依然在，只是延后爆发。

3.1 内核参数：不是改了/etc/sysctl.conf就生效，得sysctl -p且验证

Oracle 11gR2 要求的内核参数（以 RHEL/CentOS 6 为例）如下：

关键陷阱：

• 修改/etc/sysctl.conf后，必须执行sudo sysctl -p才能加载，否则sysctl命令查到的仍是旧值；
• sysctl -p可能报错（如error: "net.core.wmem_default" is an unknown key），说明内核不支持该参数（较老内核），此时应注释掉该行，而非强行设置；
• kernel.shmall和kernel.shmmax在 11gR2 中已非强制，但若物理内存 ≥ 4G，建议设为shmall = 2097152,shmmax = 2147483648（2G），否则 SGA 分配可能失败。

验证是否生效的终极命令（必须返回0）：

# 检查所有关键参数是否达到最小值 ( [ $(sysctl -n kernel.sem | awk '{print $1}') -ge 250 ] && [ $(sysctl -n fs.file-max) -ge 6815744 ] && [ $(sysctl -n net.ipv4.ip_local_port_range | awk '{print $1}') -le 9000 ] && [ $(sysctl -n net.ipv4.ip_local_port_range | awk '{print $2}') -ge 65500 ] && [ $(sysctl -n net.core.rmem_default) -ge 262144 ] && [ $(sysctl -n net.core.wmem_default) -ge 262144 ] ) && echo "✅ All kernel params OK" || echo "❌ Kernel param check failed"

3.2 Package 依赖：rpm -q查缺，yum install补全，别信“缺少的包不影响核心功能”

Oracle 11gR2 安装依赖的 RPM 包清单（RHEL/CentOS 6）：

避坑重点：

• pdksh已被ksh取代，安装ksh即可，无需找旧版pdksh；
• unixODBC在 11gR2 中非必需，但若计划用 ODBC 连接，建议yum install unixODBC unixODBC-devel；
• rpm -q检查时，务必加-q参数，rpm -qa | grep xxx可能漏掉精确版本匹配；
• 若yum install报No package xxx available，说明仓库未启用，需sudo yum repolist确认base和updates仓库已开启。

一键检查并安装缺失包（推荐保存为check-oracle-deps.sh）：

#!/bin/bash PACKAGES="binutils compat-libcap1 compat-libstdc++-33 gcc glibc ksh libgcc libstdc++ make sysstat" MISSING=() for pkg in $PACKAGES; do if ! rpm -q "$pkg" &>/dev/null; then MISSING+=("$pkg") fi done if [ ${#MISSING[@]} -ne 0 ]; then echo "Missing packages: ${MISSING[@]}" sudo yum install -y "${MISSING[@]}" else echo "✅ All required packages installed" fi

3.3 用户与组权限：oinstall和dba不是摆设，是安全隔离的基石

Oracle 强制要求两个 OS 组：oinstall（用于安装和 Inventory 管理）和dba（用于数据库管理）。安装用户（如oracle）必须同时属于这两个组，且oinstall组必须是其主组（primary group）。否则，runInstaller会报[INS-32031]或在执行 root 脚本时失败。

验证命令：

# 查看 oracle 用户的组成员关系 id oracle # 正确输出应包含：uid=500(oracle) gid=501(oinstall) groups=501(oinstall),502(dba) # 若主组不是 oinstall，需修改（-g 指定主组，-G 指定附加组） sudo usermod -g oinstall -G dba oracle # 验证主组是否生效（需重新登录或 su - oracle） groups oracle # 输出应为：oinstall dba

注意：修改用户组后，必须完全退出当前 shell 并重新以oracle用户登录，否则groups命令仍显示旧组。这是 Linux PAM 机制决定的，不是 Oracle 的锅。

4. 避坑：那些让你重装三次的“小问题”，其实都有固定解法

安装 Oracle 11gR2 最折磨人的，从来不是大框架，而是几个看似微不足道、却能让整个流程崩在最后一秒的细节。这些坑我全踩过，也总结出了可复制的解决路径。以下 5 条，按发生频率排序，每一条都对应一个真实故障场景、根因和一行命令级的解决动作。

4.1 现象：./runInstaller启动后黑屏或窗口一闪而逝

原因：X11 转发未启用，或本地 DISPLAY 变量未正确设置。在 SSH 连接时，若未加-X或-Y参数，或本地 X Server（如 Xming、MobaXterm）未运行，图形界面无法渲染。
解决：

# 本地 Windows 用 MobaXterm 连接时，确保勾选 "X11 forwarding"； # Linux/macOS 终端连接：ssh -X oracle@server_ip； # 连接后执行：echo $DISPLAY；应输出 localhost:10.0 或类似； # 若为空，手动设置：export DISPLAY=localhost:10.0； # 再运行 ./runInstaller。

4.2 现象：安装到第 17 步，root.sh执行时报错ORA-01034: ORACLE not available

原因：root.sh脚本会尝试启动oraagent进程并连接数据库，但此时数据库尚未创建（你选了“只安装软件”），因此连接失败。这不是错误，是预期行为。
解决：忽略该报错，继续完成安装。root.sh的核心任务是设置权限和链接，只要最后输出Successfully executed the script root.sh，即可认为成功。后续用dbca创建库后，再运行root.sh一次（如有必要）。

4.3 现象：netca配置监听时，服务名填orcl，但lsnrctl status显示Service "orcl" has 1 instance(s)，sqlplus / as sysdba却报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

原因：监听器已启动，但数据库实例未注册到监听器。常见于数据库未启动，或local_listener参数未设置。
解决：

# 1. 确保数据库已启动 sqlplus / as sysdba <<EOF startup exit EOF # 2. 检查数据库是否注册到监听器 lsnrctl status | grep -A 5 "Services Summary" # 3. 若无服务，手动注册（在 sqlplus 中执行） alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))'; alter system register;

4.4 现象：dbca创建数据库时，字符集选 UTF8，但建库完成后SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';返回AL32UTF8

原因：Oracle 中 “UTF8” 是旧版编码（已废弃），而 “AL32UTF8” 是其现代替代，完全兼容且推荐。dbca界面显示的 “UTF8” 实际映射到AL32UTF8。
解决：无需处理。AL32UTF8是 Oracle 对 Unicode UTF-8 的标准实现，支持所有汉字和 emoji，比旧UTF8更健壮。这是设计，不是 bug。

4.5 现象：安装完成后，sqlplus / as sysdba报ORA-01031: insufficient privileges

原因：oracle用户未加入dba组，或ORACLE_HOME、ORACLE_SID环境变量未正确设置，导致连接到了错误的实例或无实例。
解决：

# 1. 确认用户组 id oracle | grep -q 'dba' || echo "❌ oracle not in dba group" # 2. 检查环境变量（应在 ~/.bash_profile 中永久设置） echo $ORACLE_HOME # 应输出如 /u01/app/oracle/product/11.2.0/db_1 echo $ORACLE_SID # 应输出如 orcl # 3. 若变量为空，临时设置并测试 export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH sqlplus / as sysdba

5. 快速定位：从报错日志、进程树、网络端口三路并进，5 分钟锁定根因

当你再次面对一个陌生的 Oracle 11gR2 安装失败，别从头重读文档，也别盲目 Google 错误码。我给自己定了一套铁律：任何安装问题，必须在 5 分钟内，通过三个独立证据源交叉验证，才能下结论。这套方法救了我十几次，它不依赖 Oracle 文档的模糊描述，也不靠运气重启，而是直击 Linux 系统层的事实。

5.1 第一路：$ORACLE_BASE/cfgtoollogs—— Oracle 自己写的“事故报告”

runInstaller的所有操作，无论成败，都会在$ORACLE_BASE/cfgtoollogs下生成详细日志。这不是可选项，是强制行为。最核心的日志是：

• $ORACLE_BASE/cfgtoollogs/installActions<timestamp>.log：安装全过程流水账，包含每一步的命令、返回码、stdout/stderr；
• $ORACLE_BASE/cfgtoollogs/oui/：OUI（Oracle Universal Installer）自身的调试日志，含 GUI 初始化失败详情；
• $ORACLE_BASE/cfgtoollogs/dbca/：DBCA 创建库的日志，含 SQL 执行错误。

快速定位法：

# 进入日志目录（假设 ORACLE_BASE=/u01/app/oracle） cd /u01/app/oracle/cfgtoollogs # 找到最新的 installActions 日志（按时间排序） ls -t installActions*.log | head -1 # 搜索 ERROR、FATAL、Exception 关键字（注意大小写） grep -i "error\|fatal\|exception" installActions$(date +%Y-%m-%d)*.log | tail -20 # 若报 `[INS-30011]`，直接搜它出现的位置，看前 10 行在做什么 grep -A 10 -B 5 "\[INS-30011\]" installActions$(date +%Y-%m-%d)*.log

日志里最值钱的信息，永远是那一行INFO: Executing command: ...后面跟着的SEVERE: ...。它告诉你 Oracle 刚才试图执行什么命令，以及为什么失败。比如SEVERE: Error while executing command: /bin/sh -c "ulimit -s"，说明是栈大小限制导致，立刻去/etc/security/limits.conf加oracle soft stack 10240。

5.2 第二路：ps auxf | grep -E "(ora|tns)"—— 看进程是否真在跑

Oracle 的很多“失败”，其实是进程没起来，但你没意识到。比如netca说监听配置成功，但ps aux | grep tnslsnr没输出，说明监听器根本没启动；dbca说库创建成功，但ps aux | grep pmon没pmon_orcl进程，说明实例根本没起来。Linux 进程树是铁证，比任何 GUI 状态栏都可靠。

标准化检查脚本（保存为ora-check.sh）：

#!/bin/bash echo "=== Oracle Process Check ===" echo "1. Listener:" ps aux | grep tnslsnr | grep -v grep echo -e "\n2. Database Processes (pmon, smon, dbw0):" ps aux | grep -E "(pmon|smon|dbw0|lgwr|ckpt)" | grep -v grep echo -e "\n3. Oracle Agent:" ps aux | grep oraagent | grep -v grep echo -e "\n4. Port 1521 (Listener):" netstat -tuln | grep :1521 echo -e "\n5. Port 1521 (Listener) via ss:" ss -tuln | grep :1521

运行它，结果一目了然：如果tnslsnr进程没有，netstat也没监听 1521，那netca配置就是假成功，必须重配；如果pmon有但smon没有，说明实例启动卡在恢复阶段，立刻查alert_orcl.log。

5.3 第三路：tail -f $ORACLE_BASE/diag/rdbms/<sid>/<sid>/trace/alert_<sid>.log—— 数据库的“黑匣子”

alert_<sid>.log是 Oracle 实例的中枢日志，记录所有启动、关闭、错误、检查点事件。它不像installActions.log那样告诉你“安装器做了什么”，而是告诉你“数据库自己经历了什么”。90% 的 DBCA 创建失败、SQL*Plus 连接失败、监听无法注册，根源都在这里。

高效查看法：

# 假设 SID=orcl, ORACLE_BASE=/u01/app/oracle ALERT_LOG="/u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log" # 1. 检查文件是否存在且可读 [ -f "$ALERT_LOG" ] && echo "✅ Alert log exists" || echo "❌ Alert log missing" # 2. 实时跟踪最新错误（Ctrl+C 退出） tail -f "$ALERT_LOG" | grep -i "error\|ora-\|fatal\|shutdown" # 3. 查看最近 10 个 ORA- 错误（带时间戳） grep -i "ora-" "$ALERT_LOG" | tail -10

典型线索举例：

• ORA-00845: MEMORY_TARGET not supported on this system→/dev/shm太小，sudo mount -o remount,size=4G /dev/shm；
• ORA-27102: out of memory→kernel.shmmax设置过小，sudo sysctl -w kernel.shmmax=2147483648；
• Errors in file .../rdbms/orcl/orcl/trace/orcl_m000_12345.trc→ 进入该 trace 文件，看具体 SQL 或内部错误。

5.4 三路交叉验证表：把现象、日志、进程、端口串成证据链

从那以后我每次开始安装 Oracle 11gR2，第一件事不是解压，而是打开三个终端窗口：一个tail -f installActions.log，一个watch 'ps aux \| grep -E "(tns\|pmon)"'，一个tail -f alert_orcl.log。三路日志实时滚动，任何异常都在秒级暴露。这习惯让我再没为“为什么失败”纠结超过五分钟——因为答案就写在屏幕上，只是以前我没学会同时看三块屏幕。希望帮到你。

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