企业官网建设流程全解析

简介：面向龙蜥Anolis系统下需要部署Oracle 11g的数据库管理员与运维人员，这套安装包将官方RPM软件包与自动化部署脚本整合，覆盖从环境初始化、依赖安装、实例创建到监听配置的完整流程，并集成dmp数据文件的还原功能，适合用于企业级数据库的快速交付与迁移恢复。压缩包共11个文件，以7个RPM安装包为核心，配合一键安装shell脚本、服务登记文件、共享内存加载脚本及Oracle环境配置文件，整体大小约334.17MB，结构清晰，便于按需选用。目前已有3015人学习/下载。脚本会预先处理依赖包和内核参数，随后完成RPM解包、实例创建、监听器与网络服务配置；针对dmp备份，可结合用户、表空间映射执行IMPDP导入，显著降低手工配置的复杂度与出错概率。无论是新装环境还是迁移恢复，这样一套集成方案都能帮助读者避开常见坑点，是一份可直接用于生产演练的实用工具包。

1. 龙蜥上装 Oracle 11g：为什么说安装包不是难点，准备阶段才是

龙蜥 Anolis 系统上部署 Oracle 11g，听起来像是一个“下载安装包、解压、点下一步”的三步流程，实际做过的同行都知道：真正决定成败的不是安装包本身，而是安装前那一小时的环境准备。Oracle 11g 的发布时间远早于龙蜥系内核，它的安装器会对用户、目录、内核参数、共享内存、依赖库做一连串硬性检查，任何一项不满足都会在某个环节突然翻车，而且报错信息往往不直接指向真正原因。这篇笔记要解决的，就是在龙蜥系统上把 11g 装起来并稳定跑住的全过程，覆盖选包、依赖、内核参数、静默安装、常见报错和收尾验证。适合正在做老库向龙蜥迁移评估的团队，也适合第一次在龙蜥上接触 11g 的运维同学。

2. 选对安装包与依赖：龙蜥 8 系与 11.2.0.4 的兼容性准备

2.1 龙蜥为什么能装 11g：发行版血缘与“新系统跑老软件”的矛盾

龙蜥 Anolis OS 在设计上保持了与主流 RHEL 系发行版的二进制兼容性，这意味着为 RHEL 8 编译的软件包、Oracle 官方提供的 Linux x86-64 安装介质，在龙蜥上可以直接使用，不需要重新编译。这是 11g 能装上去的前提。但另一个矛盾也随之而来：11g 是典型的“老软件”，它的安装器和运行库依赖的 glibc 版本、系统调用接口，都是按十年前的内核设计的。龙蜥的内核和用户态工具链比那时新得多，所以安装过程里最常见的两类问题，一类是依赖库找不到，另一类是工具链太新导致编译或链接阶段报错。

理解这两点，就不会在安装失败时盲目重试。常见做法是：先确认龙蜥的具体小版本，再按 RHEL 8 系的兼容模式准备依赖。以 Anolis OS 8 为例，它的包管理器和软件仓库结构与 RHEL 8 高度一致，很多调优经验可以直接平移。如果用的是龙蜥 23 这种更新的大版本，依赖差异会更大，建议先在一台测试机上把依赖列表跑通再批量部署。

2.2 安装包选型：认准 11.2.0.4，别碰早期补丁集

Oracle 11g 的发布历史里，11.2.0.1、11.2.0.3、11.2.0.4 是几个主要补丁集。我的建议非常直接：在龙蜥上只考虑 11.2.0.4。原因有三个：第一，它是 11g 的最终补丁集，BUG 修复最全；第二，网络上可查到的踩坑案例和解决方案绝大多数基于 11.2.0.4，遇到问题容易找到参照；第三，它的安装介质是固定的两个 zip 包，分别以 1of2 和 2of2 命名，解压后会自动合并到一个 database 目录里，结构清晰。

拿到安装包后，第一步不是解压，而是校验完整性。常见做法是：

# 创建专用安装目录，避免和业务目录混在一起 mkdir -p /opt/ora_install cd /opt/ora_install # 校验两个包的 md5，确认下载过程没有损坏 md5sum linuxx64_11gR2_database_1of2.zip md5sum linuxx64_11gR2_database_2of2.zip # 先解压第一个包，再把第二个包解压到同一目录 unzip -q linuxx64_11gR2_database_1of2.zip unzip -q -o linuxx64_11gR2_database_2of2.zip ls -l database/

这里有一个细节值得注意：两个 zip 包必须解压到同一个顶层目录，因为 1of2 和 2of2 的内容是互补的，第二个包里的文件会补全第一个包缺少的部分。如果分开解压到不同目录，后面 runInstaller 会直接报文件缺失。md5 校验的意义也在这里——很多“安装到一半解压失败”的案例，根源是下载过程文件损坏，而不是命令写错。另外，解压后的 database 目录下会有 runInstaller 和 response 子目录，后续静默安装要用到的东西都在里面。

2.3 依赖库清单：少一个 libnsl 都起不来 sqlplus

Oracle 11g 的安装器和运行库对系统库的依赖非常敏感，最常见的缺失项不是 gcc 这类大件，而是 libaio、libnsl 这种小库。龙蜥 8 系默认仓库里，libaio 和 libnsl 需要单独安装，很多人装完软件后 sqlplus 一启动就报 shared library 错误，就是因为漏了这一步。

我一般会在正式安装前，直接用包管理器把一套依赖装齐：

# 以 dnf 为例，龙蜥 8 系也可用 yum，命令兼容 dnf install -y binutils gcc gcc-c++ \ glibc glibc-devel glibc-common \ libaio libaio-devel \ libnsl libnsl2 libnsl2-devel \ libXp libXtst libXi libXrender \ elfutils-libelf elfutils-libelf-devel \ compat-libcap1 compat-libstdc++-33 \ ksh sysstat unixODBC unixODBC-devel # 检查关键库是否已就位 ldconfig -p | grep -E "libaio|libnsl"

参数说明：libaio 是 Oracle 异步 I/O 的底层依赖，缺失时数据库实例无法正常启动；libnsl 是早期网络服务库，11g 的客户端工具链直接引用它；compat-libstdc++-33 是旧版 C++ 标准库兼容层，部分 11g 组件链接时依赖。如果某个包在仓库里找不到，比如 compat-libstdc++-33，常见做法是检查是否启用了 CRB 或 PowerTools 这类附加仓库，而不是跳过它。跳过依赖的后果，往往在安装完一个月后的某次重启时才暴露，那个阶段再排查成本就高了。

3. 系统账户、内核参数与资源限制：动手安装前的一小时

3.1 创建 oracle 用户、安装目录与环境变量

Oracle 11g 明确要求不能用 root 运行安装器，这是硬约束。安装过程需要创建一个专门的系统用户，并把它加入 dba 和 oinstall 组。目录规划也有讲究：ORACLE_BASE 放日志和配置文件，ORACLE_HOME 放软件本体，两者分开，后面升级和打补丁会省很多事。

# 创建用户和组 groupadd oinstall groupadd dba useradd -g oinstall -G dba -m -s /bin/bash oracle # 规划目录结构 mkdir -p /opt/oracle/app mkdir -p /opt/oracle/product/11.2.0/dbhome_1 mkdir -p /opt/oracle/oradata chown -R oracle:oinstall /opt/oracle chmod -R 775 /opt/oracle # 设置 oracle 用户密码 passwd oracle

代码逻辑说明：useradd 的参数把 oracle 用户的主组设为 oinstall，附加组设为 dba，这样它既能管理软件目录，又能执行数据库管理操作。目录权限必须保证 oracle 用户有写权限，否则安装器在写入 inventory 时会报权限错误。chmod 775 是常见做法，既让 oracle 用户完全控制，又允许同组用户协同管理，比 755 更灵活。

接下来是环境变量。安装器会把 ORACLE_HOME 等信息写入响应文件，但安装完成后，oracle 用户每次登录仍需要正确加载环境变量，否则 sqlplus 会提示 command not found。

# 编辑 /home/oracle/.bash_profile，追加以下内容 export ORACLE_BASE=/opt/oracle/app export ORACLE_HOME=/opt/oracle/product/11.2.0/dbhome_1 export ORACLE_SID=orcl export PATH=$PATH:$ORACLE_HOME/bin export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH umask 022

参数说明：ORACLE_SID 是实例标识，后面 dbca 建库和 sqlplus 连接都会用到；LD_LIBRARY_PATH 指向 11g 的 lib 目录，很多“能找到 sqlplus 但一运行就报库缺失”的问题，都是这一行没配好。umask 022 是为了保证创建的文件默认对同组用户可读，安装器也会检查这一项。

3.2 内核参数与资源限制：11g 能不能开起来的底线

Oracle 11g 安装器会在预检查阶段读取内核参数，不符合就直接亮红灯。这些参数里，最常出问题的是信号量、共享内存和文件句柄上限。常见部署里我用的是一组经过验证的配置，直接写入 sysctl 配置文件：

# 追加到 /etc/sysctl.d/99-oracle.conf fs.file-max = 6815744 fs.aio-max-nr = 1048576 kernel.sem = 250 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 68719476736 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 # 使配置生效 sysctl -p /etc/sysctl.d/99-oracle.conf

参数含义需要说清楚：kernel.shmmax 控制单个共享内存段的最大字节数，11g 的 SGA 会尝试申请大段共享内存，设小了实例启动直接报 ORA-27102；kernel.sem 的四个值分别控制信号量组数、每组信号量数、最大值和系统级限制，数据库并发进程多时会频繁使用信号量，默认值往往不够。fs.aio-max-nr 是异步 I/O 请求上限，11g 的日志写入依赖异步 I/O，不够会导致后台进程异常。

资源限制方面，需要为 oracle 用户单独设置 nofile 和 nproc。编辑 /etc/security/limits.d/99-oracle.conf：

# 追加以下内容 oracle soft nofile 65536 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768 oracle soft memlock 3145728 oracle hard memlock 3145728

这里有一个容易忽略的坑：limits.conf 修改后需要重新登录才会生效。如果直接在当前会话里跑安装器，检查项依然会失败。验证方式是执行 ulimit -n 和 ulimit -u，确认输出是设定值再继续。

3.3 图形界面与显示环境：没有桌面怎么跑安装器

11g 的图形安装器基于 Java，需要 DISPLAY 环境指向可用的图形会话。龙蜥服务器通常不装桌面，常见做法有两种：一种是通过支持 X11 转发的终端工具把图形界面带到本地，另一种是干脆走第 4 章的静默安装。图形安装的价值在于预检查结果直观，新手能一眼看到哪些检查项挂了。如果确实要用图形安装，常见做法是：

su - oracle export DISPLAY=客户端IP:0.0 cd /opt/ora_install/database ./runInstaller

注意 DISPLAY 里的客户端 IP 要能被服务器访问，且本地终端要允许 X11 转发。这一步本身不难，难的是很多人在 export DISPLAY 之后敲了 runInstaller 却发现界面起不来，又不看终端里的报错。实际上，只要 Java 进程能启动，报错通常会直接打在终端里，先读输出再排查，别把图形安装当黑匣子。如果团队里没有人熟悉 X11 转发配置，老实走静默安装反而更省时间。

4. 静默安装还是图形安装：用响应文件跑通 Oracle 11g 全流程

4.1 图形安装流程：什么时候值得用

图形安装并不是不能用于生产，它的优势是交互直观，安装器会把每一个预检查项的状态明确列出来，缺什么、改什么一目了然。对于第一次在龙蜥上装 11g 的团队，我建议先跑一遍图形安装，目的不是为了最终部署，而是为了收集“这台机器还缺什么”的完整清单。图形安装的运行方式很简单：

su - oracle cd /opt/ora_install/database ./runInstaller

执行后，安装器会弹出 Java 窗口，依次走 Inventory 目录确认、安装类型选择、Orace 用户验证等步骤。每一步都别急着点下一步，注意看左下角的检查项状态。如果某一步出现红色警告，直接点击查看详情，里面会写明具体缺少什么。图形安装的整个时长约为 20 到 30 分钟，主要耗时在最后的 relink 环节。relink 是在本地重新链接 Oracle 可执行文件，让它适应当前系统的库环境，这一步不能跳过。图形安装虽然是交互式的，但它在后台执行的动作和静默安装完全一致，所以它的排错结论可以复用到静默安装场景。

4.2 静默安装：把安装流程固化成响应文件

多数生产环境没有图形条件，静默安装是更靠谱的路径。它的核心是响应文件，也就是把图形安装里每一步的选择提前写在文件里，安装器读它自动执行。11g 安装介质里自带响应文件模板，位置在 database/response/db_install.rsp。

实际使用时，我一般先复制模板再修改，不让原始文件被改乱：

cp /opt/ora_install/database/response/db_install.rsp /opt/ora_install/db_install_custom.rsp chown oracle:oinstall /opt/ora_install/db_install_custom.rsp

然后编辑响应文件，以下是最简可用的关键片段：

oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/opt/oracle/app/oraInventory SELECTED_LANGUAGES=en,zh_CN ORACLE_HOME=/opt/oracle/product/11.2.0/dbhome_1 ORACLE_BASE=/opt/oracle/app oracle.install.db.InstallEdition=EE oracle.install.db.DBA_GROUP=dba oracle.install.db.OPER_GROUP=dba oracle.install.db.BACKUPDBA_GROUP=dba oracle.install.db.DGDBA_GROUP=dba oracle.install.db.KMDBA_GROUP=dba SECURITY_UPDATES_VIA_MYORACLESUPPORT=false DECLINE_SECURITY_UPDATES=true

参数说明：INSTALL_DB_SWONLY 表示只安装数据库软件，不创建实例，这是 11g 上最稳的做法，建库单独用 dbca 完成；SELECTED_LANGUAGES 里加 zh_CN 是为了后续使用中文语言包；SECURITY_UPDATES 两项必须按这样设置，否则安装器会试图联网检查更新，在没有外网的环境中直接卡住。

一切准备好后，执行安装：

su - oracle cd /opt/ora_install/database ./runInstaller -silent -responseFile /opt/ora_install/db_install_custom.rsp \ -ignorePrereq -ignoreSysPrereqs

命令说明：-silent 是静默模式的开关；-responseFile 指向我们编辑好的响应文件；-ignorePrereq 和 -ignoreSysPrereqs 表示跳过非关键预检查。之所以要加这两个参数，是因为龙蜥的系统版本较新，安装器内置的版本检测表里可能没有对应项，某些检查会因“系统版本不在支持列表”而失败，但实际环境并没有问题。需要强调的是，跳过预检查不代表跳过依赖，第 2 章和第 3 章的准备仍然要做。安装执行后，日志会写到/tmp/oraInstall 开头的目录里，如果安装中途失败，去这个目录里找 installActionsxxx.log，最后几十行就是真正的失败原因。

4.3 只装软件还是直接建库：两种路径怎么选

响应文件里 INSTALL_DB_SWONLY 和 INSTALL_DB_AND_CREATE_INVENTORY 是对应的两种路径。我的建议是分开做，先只装软件，再用 dbca 建库。原因很简单：dbca 建库的参数和响应文件参数是两套体系，混在一起时，任何一个参数写错，整个安装就得从头再来。分开做，每一步的失败范围都小，排错也快。如果直接需要建库，响应文件里要额外配置 SID、字符集、内存占比、数据文件路径这些项。但即使如此，我还是推荐软件安装和建库分离，这是长期维护最省心的模式。

5. 龙蜥上装 11g 的常见问题排查与避坑：现象、原因、解决

5.1 sqlplus 命令找不到：环境变量没生效的经典案例

现象是执行 sqlplus 时 shell 直接提示 command not found，但到 ORACLE_HOME/bin 目录下却能看到 sqlplus 文件存在。原因基本只有一个：oracle 用户的环境变量没有正确加载。常见做法是在安装和建库全部完成后，重新登录 oracle 用户，或者手动执行 source .bash_profile。这里注意一个细节：如果用户是通过 su - oracle 切换的，会加载目标用户的 profile；如果是 su oracle 切换的，不会加载，PATH 里自然没有 ORACLE_HOME/bin。解决方式是统一使用 su - oracle 切换，或者每次手动执行一遍环境变量。不要小看这个问题，它会反复出现在每次新登录的会话里，清掉它的最可靠办法是把 export 写进 .bashrc，让非登录 shell 也继承。

5.2 shared library 报错：libaio 和 libnsl 的缺失与混用

现象是安装完成、sqlplus 也能找到，但一执行就报 error while loading shared libraries: libaio.so.1 或 libnsl.so.1。原因是系统里缺少对应库，且 11g 链接的是旧版本库名。解决方式在第一阶段依赖安装时就要完成，如果已经漏掉，此时补装也来得及：

dnf install -y libaio libaio.so.1 libnsl libnsl.so.1 ldconfig

补装后再次执行 sqlplus，报错消失。另一个相关坑是：有些同学会从旧系统直接拷贝 libaio.so.1 到 /usr/lib64 下，这种跨发行版拷贝的方式可能在当前库上符号不兼容，运行时报 undefined symbol。正确做法是优先用仓库包，仓库缺失时再考虑编译或兼容层。

5.3 INS-30131：安装器初始化失败，多半是 /tmp 挂了 noexec

现象是 runInstaller 启动后立即报 INS-30131，提示执行安装程序验证所需的初始设置失败。原因通常是 /tmp 目录以 noexec 方式挂载，安装器无法在 /tmp 下执行临时脚本。这在安全加固过的服务器上非常常见，系统管理员为了安全把 /tmp 设成 noexec，没想到 Oracle 安装器会在这里执行辅助程序。解决方式有两种，一是重新挂载 /tmp 为 exec：

mount -o remount,exec /tmp

需要确认 /etc/fstab 里 /tmp 的挂载配置，否则重启后恢复 noexec，问题复发。二是把安装器的临时目录指到别的分区，通过 TMPDIR 环境变量实现：

export TMPDIR=/opt/oracle/tmp mkdir -p /opt/oracle/tmp chown oracle:oinstall /opt/oracle/tmp

这种方法更持久，不依赖 /tmp 的挂载策略。排查这个问题的顺序是：先看 /tmp 挂载属性，再看 oracle 用户对 /tmp 的写权限，最后看磁盘剩余空间。INS-30131 还有个次因是磁盘写满，日志写到一半就中断，现象相同，但原因完全不同，别只盯着一个方向。

5.4 ORA-01078 与 LRM-00109：共享内存和 /dev/shm 的配置冲突

现象是数据库实例启动时报 ORA-01078: failure in processing system parameters，同时伴随 LRM-00109: could not open parameter file。初看像是参数文件丢失，实际上常见原因是内存参数配置超过共享内存上限，或 /dev/shm 容量不足。11g 的自动内存管理依赖 /dev/shm，而多数系统的 /dev/shm 默认只有物理内存的一半，如果 MEMORY_TARGET 设置得过高，实例就无法分配共享内存段。解决方向有两个，一是把 MEMORY_TARGET 和 MEMORY_MAX_TARGET 调低到物理内存的一半以下，二是扩大 /dev/shm。我一般优先调低内存参数：

# 编辑 pfile 后重新启动 SQL> alter system set memory_target=4G scope=spfile; SQL> alter system set memory_max_target=4G scope=spfile;

如果业务确实需要大内存，再考虑改 /etc/fstab 中 /dev/shm 的 size。但这类大内存配置通常还伴随其他内核参数调整，不要只加大 /dev/shm 就结束，要整体回看 kernel.shmmax 和 kernel.shmall 是否配套。

5.5 root.sh 执行后数据库仍起不来：oratab 里的开关没打开

现象是安装最后一步 root.sh 执行成功，但尝试启动数据库时，dbstart 命令提示找不到实例。原因最常见的是 /etc/oratab 文件里该实例行的最后一个字符是 N，表示“不做开机自启”，但 dbstart 命令本身也依赖这个状态。解决方式是编辑 /etc/oratab，把最后一列改成 Y：

sed -i 's|^orcl:.*:N$|orcl:/opt/oracle/product/11.2.0/dbhome_1:Y|' /etc/oratab

注意这一行必须由 root 来改，而且是标准格式：实例名、ORACLE_HOME、Y 或 N，中间用冒号分隔。改完之后用 su - oracle 执行 source 环境变量，再启动 dbstart 验证。这个坑隐蔽在“root.sh 执行成功”这个表象之后，很多人以为 root.sh 成功等于环境已就绪，实际上它只完成了 root 权限相关的文件准备，实例启停还是要看 oratab 和用户环境。

6. 收尾三件事：root.sh、静默建库与开机自启

6.1 用 root 执行 root.sh，确认 inventory 被正确登记

安装器执行的最后一步是指示你用 root 运行 root.sh，这一步不可跳过，也不要用 oracle 用户尝试。执行后要观察输出里是否有 inventory 目录创建成功的字样，以及是否提示将 oracle 用户加入了 oinstall 组。常见问题是 root.sh 执行后无任何回显，这通常是脚本权限问题，直接检查 root.sh 是否有执行权限即可。

su - root /opt/oracle/product/11.2.0/dbhome_1/root.sh

6.2 用 dbca 静默建库，验证实例状态

建库不推荐再走图形界面，dbca 支持完整的静默模式。一个最简可用的命令示例：

su - oracle dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl -sid orcl \ -sysPassword Oracle12345 \ -systemPassword Oracle12345 \ -memoryPercentage 40 \ -datafileDestination /opt/oracle/oradata \ -characterSet AL32UTF8 \ -nationalCharacterSet AL16UTF16 \ -sampleSchema false \ -automaticMemoryManagement true

参数说明：-memoryPercentage 控制数据库占用物理内存的比例，测试环境给 40 左右比较稳妥；-characterSet 必须显式指定，默认值不一定是业务想要的编码；-automaticMemoryManagement 开启后依赖第 5 章提到的 /dev/shm，容量不够会建库失败。验证方式如下：

sqlplus / as sysdba SQL> select instance_name, status from v$instance; SQL> select name from v$datafile;

能查到实例状态为 OPEN，说明建库成功。

6.3 开机自启与一个习惯

开机自启在龙蜥上可以用 systemd 实现，但 11g 更省事的方式是直接修改 oratab 后启用 dbstart。在 /etc/oratab 已改为 Y 的前提下，编辑 /etc/rc.local 加入启动命令，或者创建一个简单服务单元。具体用哪种取决于团队的 systemd 熟悉程度，不做强制推荐。我的习惯是每次改完内核参数或内存配置后，先检查 /dev/shm 剩余空间再启动实例，曾经在这个环节上吃过亏，内存参数调得太高，实例起一半直接崩了，日志里什么都没留下。那之后我给所有部署脚本加了一行 df -h /dev/shm 的预检。这个习惯成本极低，收益却很直接。希望帮到你。

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