企业官网建设流程全解析

简介：面向在龙蜥Anolis操作系统上部署Oracle 11g的DBA、运维工程师与需要做数据库迁移还原的团队，这份安装包整合了自动安装脚本与配套组件，可大幅降低手动配置环境变量、处理依赖和创建实例的复杂度。压缩包约334MB，共11个文件，其中七个rpm安装包覆盖Oracle数据库核心组件与依赖包，install.sh负责自动化安装流程，chkconfig与S01shm_load、60-oracle.conf分别处理服务自启、共享内存加载及内核参数调优。脚本能够自动完成ORACLE_HOME等环境变量设置、解压安装RPM包、创建数据库实例（含设置SID、目录结构及初始化参数）、配置监听器和TNS连接；同时结合IMPDP/EXPDP工具支持dmp备份文件的还原，让数据迁移与故障恢复更高效。已有3015人学习下载，适合需要快速在龙蜥环境落地Oracle 11g并保障后续可维护性的DBA与运维工程师。脚本还保留了参数调整空间，便于按实际硬件与业务需求定制部署。

1. 龙蜥 Anolis 上装 Oracle 11g，先得认清这不是官方支持路径

很多人拿到龙蜥 Anolis 系统的机器，第一反应是把 Oracle 11g 的安装包传上去、解压、运行 runInstaller，结果界面还没亮就被系统版本检查拦下来。原因不复杂：Oracle 11g（尤其是 11.2.0.4）官方支持的是 Oracle Linux 6/7、RHEL 6/7 这一代，而 Anolis 系统的发行版标识和 glibc 版本都超出了官方支持范围。标题里说的「安装包」，一般就是指 11.2.0.4 的 Linux x86-64 介质，但光有安装包不够，真正要解决的是「让老数据库跑在新系统上」的兼容问题。这篇文章讲的就是一条可复现的路：从依赖准备、版本检查绕过、静默安装到建库后的启动验证，适合正在做存量 Oracle 11g 迁移、又不想因为系统版本被卡住进度的运维和 DBA 参考。新手能照着敲，熟手可以重点看第 3 章的边界处理和最后一章的收尾习惯。

2. 安装前系统准备：依赖包、运行用户与内核参数一次配齐

2.1 依赖包：先按清单装齐，再谈安装

Oracle 11g 的安装程序在图形界面和静默模式下都会做「系统依赖包预检查」（prereq checks），缺一个就报一个。很多人在 Anolis 8 上翻车，不是因为步骤不对，而是因为 11g 官方要求的包名是按 RHEL 6/7 时代的 yum 源命名的，到了 Anolis 8 上部分包改名或拆分了，直接用官方清单逐条安装时会找不到包。

我一般会按下面的清单装依赖。这些包覆盖了安装程序、SQL*Plus 和监听器运行时的基本库需求：

# Anolis 8 / 23 上安装 Oracle 11g 所需的依赖包 yum install -y \ binutils \ gcc \ gcc-c++ \ glibc \ glibc-devel \ libaio \ libaio-devel \ libgcc \ libstdc++ \ libstdc++-devel \ libXext \ libX11 \ libXtst \ libXau \ openmotif21 \ sysstat \ unixODBC \ unixODBC-devel \ elfutils-libelf \ elfutils-libelf-devel \ ksh

逻辑上这几组包分别对应不同用途：libaio和libaio-devel是 Oracle 异步 I/O 的底层库，缺了会在建库时报 ORA-27077 这类 I/O 相关错误；libX*系列是图形安装界面和 DBCA 绘图依赖，即使走静默安装，安装程序初始化时也可能引用这些库；unixODBC对应监听器和 Oracle Net 的 ODBC 驱动路径；ksh是 Oracle 自带脚本（如dbhome、oraenv）的解析器，官方脚本里默认调用 ksh 语法，缺了会有诡异的脚本报错。

参数说明：openmotif21在 Anolis 8 的 BaseOS 源里不一定存在，如果yum报找不到包，直接把这个包从清单里去掉即可，它不是硬依赖，只是安装界面主题库。另外，RHEL 7 官方清单里的compat-libstdc++-33在 Anolis 8 源里已经移除，不要死磕，11.2.0.4 在 glibc 2.28 以上的系统中并不强制需要它，后面第 4 章会讲这个坑。建议装完执行yum install -y oracle-database-preinstall-11g看看，但这个包只在 Oracle Linux 的源里有，Anolis 上装不了也不影响，关键是手工依赖别漏。

装完后用一个简单的命令验证关键库是否就位：

# 验证关键动态库存在，libclntsh 启动时依赖它们 ldconfig -p | grep -E 'libaio|libclntsh|libnnz11'

如果libclntsh这条没有输出是正常的，因为 Oracle 的库还没安装；但libaio必须有输出。看到libaio.so.1存在，依赖准备这一关就算过了。

2.2 oracle 用户、安装目录与内核参数

依赖归依赖，Oracle 11g 不允许用 root 用户安装，这在设计上就要求一个独立的运行用户。常见做法是创建oracle用户并归属oinstall、dba两个组，同时规划好安装目录。目录规划直接影响后续升级和维护，我一般习惯把软件目录和数据库文件目录分开，避免单盘被日志和归档占满。

# 创建用户和组 groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle # 创建目录结构，ORACLE_BASE 是根，ORACLE_HOME 是软件安装位置 mkdir -p /u01/app/oracle/product/11.2.0/dbhome_1 mkdir -p /u01/oradata/orcl chown -R oracle:oinstall /u01/app/oracle /u01/oradata chmod -R 775 /u01/app/oracle

核心逻辑：ORACLE_BASE是/u01/app/oracle，ORACLE_HOME是/u01/app/oracle/product/11.2.0/dbhome_1，这两个变量会在环境变量和响应文件里反复出现，建议目录现在就按这个结构建，不要装完再挪。ORACLE_SID我沿用最常见的orcl，如果你要管理多个实例，可以按业务命名，但要保证后面响应文件里的sid和建库参数一致。

内核参数是安装预检查里最容易被忽略的一块。11g 的预检查会读/etc/sysctl.conf里的当前值，如果kernel.sem或fs.file-max不达标，安装界面会直接标红。Anolis 8 默认参数里fs.file-max和端口范围通常够用，但信号量和共享内存段需要手工调整。

# 追加到 /etc/sysctl.conf cat >> /etc/sysctl.conf <<'EOF' fs.file-max = 6815744 kernel.sem = 250 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 net.ipv4.ip_local_port_range = 9000 65500 EOF # 立即生效 sysctl -p

参数含义：kernel.shmall表示共享内存页总数，kernel.shmmax是单个共享内存段的最大字节数，这两个值决定 Oracle 能否使用大 SGA；kernel.sem的四个数字依次是信号量数组最大值、系统内信号量总数、每个信号量数组的唤醒数、信号量数组个数，11g 的 AMM（自动内存管理）启动时要创建大量信号量，默认值 128 不够用；ip_local_port_range改成 9000-65500 是为了给 Oracle Net 和监听器留出足够的高位端口，避免连接数上来后端口冲突。改完务必执行sysctl -p，只写文件不生效是常见疏漏。

另外要把/dev/shm纳入检查范围。11g 默认启用内存自动管理，MEMORY_TARGET会从/dev/shm分配共享内存段，Anolis 8 默认/dev/shm只有物理内存的一半，如果内存 16G、MEMORY_TARGET给 8G 以上就可能触发 ORA-00845。检查方法很简单：

df -h /dev/shm mount -o remount,size=16G /dev/shm

临时 remount 只对当前启动生效，要持久化得改/etc/fstab，给/dev/shm加size=16G的挂载参数。这一步很多人不做，等到建库时报 ORA-00845 才回头查，属于典型的「排查半小时、改动两分钟」的问题。

3. 核心安装推进：绕过系统版本检查，用静默方式装完数据库

3.1 先把发行版标识备份并临时改成受支持版本

Anolis 系统在/etc/redhat-release或/etc/os-release里写的是自己的发行版名称，Oracle 11g 的安装程序runInstaller启动时会读取这些文件，发现不是 Red Hat Enterprise Linux 7 或 Oracle Linux 7，直接弹「This system is not certified for Oracle Database 11g」并退出。这个行为的本质是版本字符串匹配检查，不是真正的内核兼容性校验，所以绕过手段很明确：临时把发行版标识改成官方支持的版本，装完再改回来。

提示：这里改的是安装程序的「识别标签」，不涉及内核和系统库，改回原样后系统本身不受影响，不要在安装过程中重启机器。

# 备份原文件 cp /etc/redhat-release /etc/redhat-release.bak cp /etc/os-release /etc/os-release.bak # 临时改为 RHEL 7 的标识，Oracle 11g 认这个字符串 echo "Red Hat Enterprise Linux Server release 7.9 (Maipo)" > /etc/redhat-release # os-release 也一并改，安装程序部分组件会读它 cat > /etc/os-release <<'EOF' NAME="Red Hat Enterprise Linux Server" VERSION="7.9 (Maipo)" ID="rhel" VERSION_ID="7.9" PRETTY_NAME="Red Hat Enterprise Linux Server 7.9 (Maipo)" EOF

这里有个细节：光改/etc/redhat-release不一定够，部分版本的runInstaller会通过uname或者系统调用间接读取/etc/os-release，所以两份文件一起改更稳妥。一个容易忽略的点是ID="rhel"这行，如果保留ID="anolis"，某些检查脚本按ID变量取值判断时还是会拒绝。改完后可以执行cat /etc/redhat-release确认输出内容，再启动安装程序。

改完标识后不要再执行yum update或yum install，yum 在更新时会重新生成部分 release 相关文件，可能导致标识在安装中途变回去。安装完成后，记得第一时间恢复备份的文件：

cp /etc/redhat-release.bak /etc/redhat-release cp /etc/os-release.bak /etc/os-release

恢复标识这一步放在 root.sh 执行完毕、数据库建好之后做，不要提前。如果你忘了备份，可以根据 Anolis 8 的原始内容手写回去，但不同版本的 Anolis 发行版标识有差异，强烈建议按上面的命令先备份再动手。

3.2 静默安装响应文件：最关键的 10 个参数

图形界面安装在这套环境里最大的问题是 DISPLAY 转发和字体库，一旦 X 会话中断整个安装流程就得重来。静默安装（silent mode）是更稳的路径，核心是准备一份正确的响应文件db_install.rsp。这份文件的模板在安装包解压目录的response/下，直接把模板复制出来改参数即可。

# 解压安装包，注意替换为你实际的 zip 文件名 unzip -q p13390677_112040_Linux-x86-64.zip -d /tmp/oracle11g cd /tmp/oracle11g/database/response cp db_install.rsp /tmp/db_install_edit.rsp

响应文件里参数按段划分，避坑的关键是别漏掉oracle.install.option、UNIX_GROUP_NAME和ORACLE_HOSTNAME这三个，漏一个就会在静默安装中途报「缺失必需参数」。我整理了一份可对照编辑的最小参数清单，按重要性排列：

# 以 oracle 用户编辑响应文件（以下为关键参数，不是全部） oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory SELECTED_LANGUAGES=en,zh_CN ORACLE_HOSTNAME=your-hostname ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_BASE=/u01/app/oracle oracle.install.db.InstallEdition=EE oracle.install.db.DBA_GROUP=dba oracle.install.db.OPER_GROUP=dba oracle.install.db.BACKUP_GROUP=dba DECLINE_SECURITY_UPDATES=true

逐项说下这些参数的作用和取值逻辑：INSTALL_DB_SWONLY表示只装数据库软件、不建库，建库后面用 DBCA 单独做，这个选择能缩短安装时间，也便于把软件安装和建库两个环节分开排错；INVENTORY_LOCATION是 Oracle 资产清单目录，必须和响应文件里的一致，否则后续opatch打补丁时找不到中央清单；ORACLE_HOSTNAME会被写入监听器和实例的配置文件，必须填/etc/hosts里能解析到的主机名，填了 IP 或一个 hosts 里不存在的名字，后面监听器起不来是必然的；SELECTED_LANGUAGES建议带上en和zh_CN，否则 SQL*Plus 里的中文注释和 NLS 环境在客户端会有乱码风险。

特别提醒两个容易埋雷的参数：DECLINE_SECURITY_UPDATES必须为true，否则安装程序会卡在「是否接收安全更新」的交互确认上，导致静默安装无法继续；oracle.install.db.InstallEdition取EE还是SE，取决于你是否需要分区、备库等企业版特性，一般生产环境用EE，测试环境用SE足够，安装介质类型决定可选范围。

响应文件检查完，再用chown oracle:oinstall确保文件属主没问题，然后进入安装。

3.3 runInstaller 执行与 root.sh 的处理

以 oracle 用户执行安装命令，日志默认写在/tmp下。静默安装不像图形界面有进度条，判断是否成功只能看退出码和日志，这是它最大的盲区，所以执行前一定要找到日志文件位置。

# 以 oracle 用户执行，-ignorePrereq 用来跳过非关键预检查项的硬性拦截 su - oracle -c "cd /tmp/oracle11g/database && ./runInstaller -silent -responseFile /tmp/db_install_edit.rsp -ignorePrereq"

这里解释一下-ignorePrereq的取舍：不加它，预检查会把「系统版本不受支持」「缺少 compat-libstdc++-33」「缺少 openmotif21」等各项一并拦截报错，这些在 Anolis 系统上是无法通过装包解决的，属于「已知且可接受」的差异；加了它，安装程序跳过这些拦截项继续装，但不会跳过所有检查，磁盘空间、物理内存这类硬性条件依然会被校验。所以这个参数的本质是「让已知的非关键差异不阻断流程」，而不是「无脑放行」。

注意：-ignorePrereq只适用于软件安装阶段，建库阶段不适用。如果后面 DBCA 因为缺依赖失败，说明依赖问题没真正解决，不能再用跳过的方式绕。

安装过程一般持续 15 到 30 分钟，视机器性能而定。安装结束时终端会明确提示「请以 root 用户执行两个脚本」，分别是/u01/app/oraInventory/orainstRoot.sh和$ORACLE_HOME/root.sh。这一步很多人跳过或记错顺序，导致后续dbca建库时权限错乱。

# 切换到 root 执行，顺序不能颠倒 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/11.2.0/dbhome_1/root.sh

orainstRoot.sh负责给中央清单目录写权限，root.sh负责设置软件属主和创建/etc/oraInst.loc等系统级文件。两个脚本执行完，软件安装环节才算真正结束。如果你看到root.sh执行时提示找不到某个.0版本目录或ohome文件，多半是ORACLE_HOME环境变量没在 root 的 shell 里生效，回到第 2.2 节检查目录是否存在。

软件装完后，建库用 DBCA 静默模式。响应文件模板在$ORACLE_HOME/assistants/dbca/templates下，命令如下：

# 以 oracle 用户执行 DBCA 静默建库 su - oracle -c "\$ORACLE_HOME/bin/dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -sysPassword YourStrongPass_1 \ -systemPassword YourStrongPass_1 \ -datafileDestination /u01/oradata/orcl \ -memoryPercentage 40 \ -characterSet AL32UTF8"

建库参数的逻辑：-templateName General_Purpose.dbc是通用模板，能覆盖绝大多数业务场景；-datafileDestination指定数据文件目录，要和 2.2 节建好的目录一致；-memoryPercentage 40表示用物理内存的 40% 作为内存目标，这个比例在 16G 内存的机器上大概给到 6G，需要根据实际内存调整，给高了会触发 ORA-00845；-characterSet AL32UTF8决定数据库字符集，如果以后要迁老库，注意源库字符集是否为 ZHS16GBK，不一致要提前转换。建库过程顺利的话，日志末尾会看到「Database creation complete」字样，这时数据库已经在运行，可以做第一次连接验证。

4. 装 Oracle 11g 最容易翻车的 5 类问题与排查思路

4.1 预检查报某个包缺失，但包名在 Anolis 源里没有

现象：运行runInstaller预检查时，日志里报compat-libstdc++-33缺失，或者是openmotif21找不到，安装无法继续。

原因：这两个包在 RHEL 7 时代是独立包，到了 Anolis 8 的源里，一个被拆分进libstdc++高版本中，一个彻底不再维护。Oracle 11g 的预检查只是按固定包名查rpm -q，查不到就报错，它不关心功能是否已被其他包覆盖。

解决：这两个包和 Oracle 11g 核心运行没有强依赖，用-ignorePrereq跳过即可，不需要硬装。如果你想彻底消除告警，可以用rpm -ivh --nodeps --force强行安装从 RHEL 7 兼容源下载的 compat-libstdc++-33 包，但我实际测试下来装不装都不影响后续建库和运行，强行装反而可能覆盖系统里的部分库文件，不建议在生产上这么做。预检查通过后，重点看日志里是否有libaio、libXext这类真正影响运行的库报错，这些不能跳。

4.2 root.sh 执行失败，提示找不到 orainstRoot.sh 或权限拒绝

现象：安装程序提示执行$ORACLE_HOME/root.sh，但切到 root 执行时提示Permission denied或No such file or directory。

原因：常见原因有两个。一是/u01/app/oracle目录的属主不是oracle:oinstall，root.sh 里要对软件目录做chown和写操作，属主不对直接拒绝；二是执行顺序颠倒了，先跑了 root.sh 再跑 orainstRoot.sh，导致中央清单目录/u01/app/oraInventory还没写权限。

解决：先执行ls -ld /u01/app/oracle /u01/app/oraInventory检查属主，不是 oracle:oinstall 就用chown -R修正；再严格按照顺序执行两个脚本。如果 root.sh 中途报错中断，可以查看日志$ORACLE_HOME/cfgtoollogs/下的记录，确认是哪一步卡的。这个脚本不是幂等的，重复执行时如果之前执行了一半，建议先看日志再补执行，不要无脑重跑。

4.3 建库时报 ORA-00845：MEMORY_TARGET not supported on this system

现象：DBCA 建库进度到一半，日志里出现ORA-00845: MEMORY_TARGET not supported on this system，数据库实例无法启动。

原因：ORA-00845 的本质是共享内存文件系统（/dev/shm）空间小于MEMORY_TARGET的设定值。11g 默认开启自动内存管理，实例启动时要往/dev/shm里映射共享内存段，空间不够就直接拒绝启动。Anolis 8 默认/dev/shm只有物理内存的一半大小，内存配得越大越容易踩。

解决：两条路选其一。优先扩容/dev/shm，编辑/etc/fstab给/dev/shm挂载参数加上size=16G，然后mount -o remount /dev/shm生效；或者把实例改成手动内存管理，在init.ora里把MEMORY_TARGET去掉，改用SGA_TARGET和PGA_AGGREGATE_TARGET两个参数，两者之和不超过物理内存即可。生产环境我一般倾向后者，因为 SGA+PGA 的固定分配方式对内存控制更精确，不容易和系统其他进程抢内存。改完参数后重启实例，用show parameter memory_target确认取值变为 0。

4.4 SQL*Plus 启动报 libclntsh.so 加载异常或版本不匹配

现象：装完数据库后，执行sqlplus / as sysdba提示error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file，或者能打开但执行查询时报字符集相关的乱码。

原因：SQL*Plus 启动时通过LD_LIBRARY_PATH找$ORACLE_HOME/lib下的动态库，如果 oracle 用户的环境变量没配好，系统会去默认路径找，找不到就报错。另外NLS_LANG没设置时，客户端和数据库字符集不一致，中文显示成问号。

解决：把下面的环境变量写进 oracle 用户的~/.bash_profile，然后source一下：

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

注意LD_LIBRARY_PATH里$ORACLE_HOME/lib必须放在最前面，因为高版本 glibc 系统自带的 lib 目录里可能有同名库，顺序错了会加载错版本。NLS_LANG的值要和建库时指定的字符集一致，如果你建库用的是 ZHS16GBK，这里就改成AMERICAN_AMERICA.ZHS16GBK。这组变量是所有 Oracle 运维的开始，配一次以后所有命令都受益。

4.5 监听器起不来，lsnrctl status 报 TNS-12541 或 hostname 无法解析

现象：执行lsnrctl start后监听器进程起来，但客户端连接时报TNS-12541: TNS:no listener，或者监听日志里出现connect to host failed的错误。

原因：监听器默认绑定的是listener.ora里配置的HOST，这个值如果写成了无法解析的主机名或者 IP 与/etc/hosts不一致，监听器会启动失败或只监听在错误地址。很多人在静默安装响应文件里ORACLE_HOSTNAME填了一个当前 shell 里hostname显示之外的名字，问题当时不暴露，重启后才显现。

解决：打开$ORACLE_HOME/network/admin/listener.ora，把HOST改成/etc/hosts里能解析的主机名，推荐直接写成实际 IP，避免 hostname 解析链路出问题。同时检查/etc/hosts里是否把主机名映射到了127.0.0.1，如果是，监听器会只监听环回地址，外部连接全部失败。改成静态 IP 或正确的主机名映射后，重启监听器：lsnrctl stop再lsnrctl start，用lsnrctl status确认监听地址是网卡 IP 而不是localhost。这个坑在云主机和容器化环境里特别常见，因为镜像里主机名和实际网络配置经常不一致。

5. 收尾验证与后续维护：三条自检命令加一个日常习惯

安装和建库完成，还差最后一道把关。我的习惯是永远不信任安装日志里的「success」，而是用三条命令从用户态、系统态、网络态三个层面独立验证一次。

第一条命令验证数据库实例本身能启动：

su - oracle -c "sqlplus / as sysdba <<'EOF' startup select status from v\$instance; EOF"

startup输出Database opened.且v$instance.status为OPEN，说明实例和数据文件都正常。这里要留意v$instance前面的反斜杠，在 bash 双引号里$会被 shell 解释，必须转义，否则执行的是空变量。

第二条命令验证监听器在网卡地址上正常监听：

su - oracle -c "lsnrctl status"

关注输出里的Listening Endpoints Summary，地址应该是机器实际 IP 加端口 1521，而不是localhost或127.0.0.1。这条验证过了，应用服务器才能连上。

第三条命令验证数据库能接受远程连接。在另一台机器上执行：

sqlplus system/密码@机器IP:1521/orcl

能连上并执行任意一条select，说明从网络到监听到数据库的整条链路都通。这条很多人偷懒跳过，等到应用部署后才暴露连接问题，排查成本成倍增加。

这三条命令之外，我还有一个每次都要做的固定动作：记录安装时的内核参数、响应文件关键参数和listener.ora的改动，存成一份一页纸的交接文档。数据库跑半年后，谁也不会记得当时为什么把kernel.shmmax调成那个值，但下一任接手的人需要这个文档才能在扩容时做出正确判断。这个习惯帮我避免过很多次「翻旧账」式的排查，也让我自己半年后回看当时的安装决策时，能立刻想起哪些参数是踩过坑才改的。

如果你打算把 11g 长期跑在 Anolis 上，还有一个后续动作值得做：数据库启动脚本。11g 不自带 systemd 服务文件，重启机器后实例和监听器不会自动拉起，建议写一个简单的 systemd unit 或沿用dbstart脚本并放到开机自启里。这一步做完，整个安装才算真正收尾。希望帮到你。

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