企业官网建设流程全解析

简介：面向需要在龙蜥Anolis（Anolis OS）上部署Oracle 11g数据库的DBA与运维人员，这份资源提供了一整套自动化安装与数据恢复解决方案。包内包含Oracle 11g的RPM安装包及依赖、环境配置脚本、监听与服务初始化文件，可帮助用户快速完成从依赖检查、环境变量设置到数据库实例创建与监听配置的全流程部署，并支持通过IMPDP等方式还原dmp备份数据，有效简化手动安装流程、减少出错概率。整个压缩包共11个文件，以rpm包为主，附带sh脚本、conf配置及chkconfig服务文件等，总大小约334MB，结构清晰，便于按需取用。截至目前已有2994人学习下载，适合需要在内网或离线环境中批量安装Oracle 11g，或希望用脚本自动化解决部署难题的工程师参考。 如果你最近接到一个任务：把原来跑在CentOS上的Oracle 11g数据库迁移到龙蜥（Anolis OS）服务器上，你大概率做的第一件事是搜索“oracle11g安装包”。我在帮客户完成这套迁移时，发现网上教程几乎都是针对CentOS/RedHat的老路子，直接照搬到龙蜥上，连依赖包那一关都过不去。原因不复杂：龙蜥和RHEL确实是同一个生态，但包仓库、安全策略、内核参数都有差异，Oracle 11g这种十多年前的老软件，在新系统上非常挑剔。

这篇文章把我实测过的完整流程整理出来，包括安装包怎么选、环境准备要做哪些、静默安装怎么填响应文件、装完以后哪些报错最常见，以及对应的排查思路。无论你是刚接手这套老库的运维，还是准备在龙蜥上做Oracle 11g的测试环境，这篇都能帮你少走弯路。

1. 为什么非要在龙蜥上装Oracle 11g（以及哪个版本兼容性更好）

1.1 CentOS停更后，谁是Oracle 11g的“新宿主”

先说背景。很多企业的核心业务系统是多年以前搭建的，数据库用的是Oracle 11g，应用层代码也是围绕这个版本写的。数据库升级意味着应用要重新适配、数据要迁移、业务要停机验证，成本和风险都不小。于是 CentOS 7 停止维护之后，选择一个能继续提供长期更新、又跟RHEL系兼容的替代系统成了刚需，龙蜥就是其中一个很热门的选择。

这里我想强调一个容易被忽略的点：龙蜥虽然和CentOS/RHEL同源，但在安装Oracle 11g这件事上，它并不等于“换个logo的CentOS”。实际遇到的坑集中在三个地方：

• 依赖包名称和可用性不完全一样，比如compat-libstdc++-33在龙蜥默认源里经常没有。
• Oracle 11g官方根本没有声明支持这么新的系统，OUI（Oracle Universal Installer）的系统版本检查会直接拦截。
• 默认安全策略（SELinux、firewalld）比老系统更严格，不处理就会出现各种诡异的连接失败。

所以，如果你把CentOS那套操作原封不动搬过来，很容易卡在某个莫名奇妙的地方。但你只要理解了原因，龙蜥装Oracle 11g是完全可行的，生产环境也有大量案例验证过稳定性。

1.2 Anolis 7还是Anolis 8：选错版本后面全是坑

安装之前首先要确定龙蜥的版本。Anolis OS目前主要分成两条线：

我的建议很明确：生产环境如果必须装Oracle 11g，优先选Anolis OS 7.9。别去追求新版本，Oracle 11g R2发行于2009年，官方支持的最高系统版本也就是RHEL 6，在RHEL 7生态上本身就需要额外配置了，到了8代系统上，glibc和libstdc++的版本变化足以让OUI彻底罢工，即使强行装上，后续跑起来也不放心。

登录服务器后，先确认一下系统版本和内核：

cat /etc/anolis-release uname -r

如果输出里看到Anolis OS 7.9，继续往下走就有戏。如果已经是8.x，下面这套流程可以作为参考，但遇到兼容性报错时要做好折腾的心理准备。

2. 先别急着点下载：安装包选型与介质准备

2.1 两种主流的安装包形态

搜索“oracle11g安装包”的时候你会发现，网上流传的介质五花八门，但真正靠谱的只有两种形态：

第一种是Oracle官方的zip包。这是最标准的方式，文件名叫linux.x64_11gR2_database_1of2.zip和linux.x64_11gR2_database_2of2.zip，两个包加起来大约2.1GB。下载后解压到同一个目录，会得到一个database文件夹，里面有runInstaller可执行文件。这两个zip包必须同时下载，缺一个解压就会报错。强烈建议下载后校验文件完整性：

md5sum linux.x64_11gR2_database_1of2.zip linux.x64_11gR2_database_2of2.zip

第二种是RPM包或tar包。有些镜像站会把安装文件重新打包成单个文件，看起来是省事了，但Oracle 11g的安装不是简单解压就能用的，它涉及oracle用户、oinstall组、ORACLE_HOME权限、响应文件配置等一系列东西。RPM包主要解决的是“把文件放到对应目录”这一步，后面还是得手工配置，反而容易漏步骤。我的建议是：直接用官方zip包，别贪图方便用来路不明的打包版。

另外，很多人会搜“离线依赖包”。这是因为目标服务器可能无法直接访问外网yum源。处理思路其实是用一台能联网的同版本龙蜥机器，把依赖包提前缓存下来，或者搭建本地yum仓库。具体做法我放在下一章环境准备里讲。

2.2 桌面类安装和服务器类安装的区别

网上热搜里经常出现“oracle11g桌面类安装”，这是Oracle 11g安装程序里的一个选项。运行runInstaller进入图形界面后，你会看到两种安装类型：

• Desktop Class（桌面类）：面向个人开发、测试环境，安装过程简单，系统会自动帮你设置ORACLE_BASE、ORACLE_HOME，还会默认创建数据库实例。如果你只是想在本地跑个库，选这个就行。
• Server Class（服务器类）：面向生产服务器，安装过程可定制程度更高，可以只装数据库软件不建实例，也可以单独配置ASM、RAC等高级选项。

需要说明的是，在静默安装（silent mode）里，对应这个选项的参数是oracle.install.db.InstallEdition，值可以填EE（企业版）、SE（标准版）等，同时还有一个oracle.install.db.isCustomInstall参数控制是否自定义。如果你完全不想要图形界面，又想省事，建议明确选择服务器类并手工指定ORACLE_BASE和ORACLE_HOME，这样后面维护时路径清晰，不会踩到“桌面类装完不知道东西去哪里了”的坑。

2.3 JDK版本这个坑，很多人装不上是死在这里

另外一个热搜词“jdk17安装包”也值得聊聊。很多人在装Oracle 11g之前会习惯性地先装个新版本JDK，实际上完全没必要，而且会添乱。Oracle 11g安装程序自带了所需的JRE，runInstaller用的是它内部的那一套Java环境，跟你系统装了什么JDK没有直接关系。

如果你在服务器上已经把JAVA_HOME指向了JDK 17这类新版本，启动runInstaller时反而可能报错，因为新版JDK对旧的AWT/Swing组件兼容性不好，图形界面可能打不开。如果你走静默安装模式，这个问题倒是不明显，但我依然建议你在执行安装前把JAVA_HOME暂时清掉，或者明确指向安装包自带的jdk目录，以免干扰。

真实操作中我见过有人因为JDK问题反复重装OUI，折腾了一整天才发现是新版JDK的锅。所以这里先打好预防针：装Oracle 11g，不需要你自己准备JDK。

3. 环境准备阶段就能劝退一半人的依赖补齐与系统参数

3.1 官方预安装包在龙蜥上不存在，依赖要手搓

在CentOS上装Oracle 11g，很多人会偷懒用别人做好的oracle-database-preinstall或oracle-rdbms-server-11gR2-preinstallRPM包，一条命令装完一堆依赖。但龙蜥默认仓库里没有这个包，所以必须手动一条一条装依赖。

依赖列表其实固定，Oracle官方文档里写得很清楚。在Anolis OS 7.9上，用这条命令把基础依赖全部装齐：

yum install -y binutils compat-libcap1 compat-libstdc++-33 \ compat-libstdc++-33.i686 elfutils-libelf-devel gcc gcc-c++ \ glibc glibc-devel glibc.i686 ksh libaio libaio-devel \ libaio.i686 libgcc libstdc++ libstdc++-devel libstdc++.i686 \ make sysstat unixODBC unixODBC-devel

这里面比较容易出问题的是compat-libstdc++-33。它在老CentOS 6/7的源里存在，但龙蜥7的默认源里可能没有，装的时候会提示找不到包。解决办法有两个：

• 找一个RHEL 7或CentOS 7的兼容源，把对应的compat-libstdc++-33-3.3.4.4.el7.x86_64.rpm下载下来，用rpm -ivh本地安装。
• 如果你用的是离线环境，就在能联网的同版本机器上先yum install --downloadonly把RPM包缓存出来，再拷贝过去。

这个包非常关键，Oracle 11g的OUI和数据库运行时某些组件依赖老版本的C++标准库，缺了它会在链接阶段报各种看不太懂的错。

3.2 内核参数、用户与资源限制一次配到位

环境准备的第二个大头是内核参数和操作系统用户。这块建议老老实实照着Oracle官方安装文档的标准来，不要自行发挥。

需要创建的组和用户：

groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle passwd oracle

然后编辑/etc/sysctl.conf，追加以下内容：

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 fs.aio-max-nr = 1048576 net.ipv4.ip_local_port_range = 9000 65500

执行sysctl -p让参数生效。这里重点说下kernel.shmmax：它表示单个共享内存段允许的最大字节数。Oracle的SGA会尝试分配共享内存，如果这个值小于SGA需求，就会出现经典的ORA-27102: out of memory报错。我给的4398046511104对应4TB，基本属于“给得足够多但不会影响系统其他程序”的保守值。生产环境可以根据物理内存大小调整，但不要小于SGA目标值。

接着编辑/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

很多人装完数据库，sqlplus一启动就报ODaniel: error while loading shared libraries，或者进程一多就报资源不够，大概率就是limits.conf没配置。这里我的建议是nofile（文件句柄数）给到65536是下限，如果并发连接多，可以再往上调。

3.3 骗过OUI的系统版本检查和SELinux/防火墙

环境准备阶段最后一个大坑，是Oracle 11g的OUI会检查操作系统版本。它最高只认到RHEL 6，在龙蜥7上一检查就会红叉，直接不让你继续安装。

最简单的处理办法是临时修改/etc/redhat-release：

cp /etc/redhat-release /etc/redhat-release.bak echo "Red Hat Enterprise Linux Server release 7.9 (Maipo)" > /etc/redhat-release

安装完成后记得改回来。这个操作的本质是让OUI的prereq checker误以为自己在RHEL 7上运行，从而跳过系统版本硬校验。注意：装完数据库后不还原这个文件会导致系统更新工具行为异常，因为很多yum插件和软件包会读取它判断系统版本。我曾经见过有人装完库忘了恢复，结果后来装别的软件时老是被误导，排查半天才想起来这茬。

然后关闭SELinux和防火墙：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config systemctl stop firewalld systemctl disable firewalld

SELinux对Oracle 11g的影响非常直接：监听进程没法绑定端口，或者客户端连接后马上被断开。虽然通过配置SELinux策略也能让Oracle正常工作，但投入产出比太低，生产环境图省心就关掉。防火墙同理，如果公司安全要求不能关，那就只放行1521端口。

最后还有个经常被忽略的环节：/etc/hosts主机名解析。确保hostname -i返回的不是127.0.0.1：

echo "192.168.1.100 anolis-db" >> /etc/hosts hostname anolis-db

这一步影响的是监听器注册和数据库实例的本地连接，很多“明明装好了却连不上”的案例，最后都定位到hosts配置上。

4. 静默安装链路：响应文件、runInstaller和数据库创建不分开讲

4.1 db_install.rsp里哪些参数决定成败

在真实的服务器部署场景，我通常不会耗在图形界面里，而是用静默安装模式。这要求先准备好响应文件。Oracle zip包解压后，响应文件模板在database/response/db_install.rsp。

关键参数如下：

oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/opt/oracle/oraInventory SELECTED_LANGUAGES=en,zh_CN 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.DBSNMP_PASSWORD=YourPassword DECLINE_SECURITY_UPDATES=true

有几个参数要特别说明：

• oracle.install.option=INSTALL_DB_SWONLY表示只装数据库软件，不建实例。我习惯把建实例的动作留到后面用dbca单独做，这样职责清晰，也方便在安装失败时定位问题。
• INVENTORY_LOCATION是Oracle安装清单目录，建议放在独立位置/opt/oracle/oraInventory，不要放在/u01/app/oracle里面，否则卸载重装时容易残留权限问题。
• DECLINE_SECURITY_UPDATES=true一定要写，不然OUI会强制要求配置“My Oracle Support”账号，不配置就卡在原地。
• DBSNMP_PASSWORD是Oracle的SNMP监控账号密码，可以后续再改，但这里必须先填一个符合复杂度要求的值，避免OUI校验不通过。

4.2 运行runInstaller时的细节与看日志的方法

接下来切换成oracle用户，执行安装：

su - oracle cd /data/install/database ./runInstaller -silent -responseFile /data/install/database/response/db_install.rsp

执行后，终端会打印安装进度。如果中途报错，日志文件路径通常在这里：

/u01/app/oraInventory/logs/InstallActions-*.log

重点看日志里INFO级别以上的错误信息，定位到具体的检查项。比较常见的报错有：

• 路径权限错误：例如OUI-10035: You have specified an invalid value for the Oracle Home。原因多半是ORACLE_HOME的父目录不是oracle用户所有，或者oracle用户对该路径没有写权限。解决办法是先mkdir -p /u01/app/oracle，然后chown -R oracle:oinstall /u01/app/oracle。
• 系统版本检查失败：这是没改/etc/redhat-release导致的，回到上面第3.3节处理。
• 依赖缺失：OUI在预检查阶段会提示缺少某个rpm包，根据提示回到yum命令补齐。

静默安装跑完后，安装程序会提示需要用root用户执行两个脚本：

/opt/oracle/oraInventory/orainstRoot.sh /u01/app/oracle/product/11.2.0/dbhome_1/root.sh

这一步千万别跳过。orainstRoot.sh会修改oraInventory目录的属主和权限，root.sh会设置/etc/oratab和数据库本地认证相关文件。漏掉这两个脚本，后面的监听注册和开机自启都会出问题。

4.3 netca、dbca与监听注册

装完数据库软件后，还需要配置监听器并创建实例：

su - oracle netca -silent -responsefile /data/install/database/response/netca.rsp dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname orcl -sid orcl \ -sysPassword YourSysPass \ -systemPassword YourSystemPass \ -emConfiguration NONE \ -memoryPercentage 40 \ -datafileDestination /u01/app/oracle/oradata

netca会创建默认的LISTENER监听器并写入listener.ora。dbca会创建名为orcl的实例。这里要注意-sid orcl和-gdbname orcl必须保持一致，否则后续连接时就会出现监听器不认识这个SID的问题。

如果你希望监听器由tnsnames和客户端连接，还需要确认listener.ora里SID_LIST的配置。默认情况下，Oracle 11g的监听器会自动通过动态注册识别实例，但前提是实例启动时能正常访问listener.ora中的端口和主机名。监听配好后，执行lsnrctl status应该能看到类似Service "orcl" has 1 instance(s)的输出。

5. 安装完成后的三座大山：ORA-12505、ORA-27102与开机自启

5.1 ORA-12505真凶不一定是监听没配好

装完后用SQL Developer或者DataGrip连接数据库时，最经典的一个报错是：

ORA-12505: TNS:listener does not currently know of SID chosen in connect descriptor

翻译成大白话就是：客户端跟服务器的1521端口已经建立了网络连接，但监听器翻遍了手里的名单，发现没有你填的那个SID。

这事的排查链路很有代表性，我建议按顺序来：

第一步，用lsnrctl status看监听器是否正常、当前注册了哪些服务。如果输出里没有orcl这个服务，说明数据库实例没有动态注册到监听器上。最常见的两个原因：一是实例还没启动（sqlplus / as sysdba然后startup），二是实例启动的时候监听器也还没起来，错失了动态注册机会。解决办法是在实例里执行：

alter system register;

手动触发一次注册。

第二步，确认/etc/hosts里主机名解析正常。如果监听器启动时绑定的是localhost，外部连接自然找不到SID。通常建议监听地址直接写服务器IP，不要写主机名，避免解析歧义。

第三步，如果客户端程序走的是tnsnames.ora，检查连接描述符里的SERVICE_NAME和SID是否填对。SERVICE_NAME对应实例的全局数据库名，SID对应实例名，两者在单实例环境通常一致，但有些工具默认写的连接串可能指向了不存在的SID。

5.2 ORA-27102共享内存不足的边界在哪里

另一个高频报错是：

ORA-27102: out of memory Linux-x86_64 Error: 28: No space left on device

注意，这里“No space left on device”跟磁盘满了没关系，而是共享内存分配失败。出现这个报错，重点检查两处：

• kernel.shmmax是否小于SGA目标大小。如果你在dbca里把SGA设成了8GB，但shmmax还是默认的几百MB，分配肯定失败。理论上Oracle可以退而求其次使用多个共享内存段，但11g对单个大段的依赖很明显，所以直接把shmmax调大最省心。
• /dev/shm空间是否够大。Oracle在内存管理上会用hugetlb或者/dev/shm文件系统分配内存，df -h /dev/shm看一下，如果只有64MB这类默认值，建议改到物理内存的一半以上。修改方法是在/etc/fstab中给/dev/shm加size参数并重新挂载。

物理内存分配的大原则我一般建议这样：总内存64GB的机器，SGA给24GB-32GB，PGA给8GB左右，剩下的留给操作系统和文件缓存。小内存机器（8GB以下）就别硬撑了，SGA给2GB-3GB就行，否则系统自身会先OOM。

5.3 用systemd接管Oracle服务的做法

很多老教程让你在/etc/rc.local里写su - oracle -c dbstart来实现开机自启。这在龙蜥上虽然能用，但不够干净，rc.local本身在systemd生态里已经被边缘化了。我建议直接写一个systemd服务：

[Unit] Description=Oracle Database 11g After=network.target [Service] Type=forking User=oracle Group=oinstall Restart=no ExecStart=/u01/app/oracle/product/11.2.0/dbhome_1/bin/dbstart /u01/app/oracle/product/11.2.0/dbhome_1 ExecStop=/u01/app/oracle/product/11.2.0/dbhome_1/bin/dbshut /u01/app/oracle/product/11.2.0/dbhome_1 Environment=ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 [Install] WantedBy=multi-user.target

把这个文件保存为/etc/systemd/system/oracle.service，然后：

systemctl daemon-reload systemctl enable oracle systemctl start oracle

用systemd接管的好处是自然支持systemctl status oracle查看日志，监控告警接入也方便。需要提醒的是，dbstart和dbshut会读取/etc/oratab，这个文件中每一行的最后一个字段决定是否允许自动启动。确认orcl:/u01/app/oracle/product/11.2.0/dbhome_1:Y里的N改成了Y，否则dbstart不会启动数据库。

最后再分享一个经验：装完并验证无误后，一定要把/etc/redhat-release恢复原样，否则后续系统更新和yum安装软件时会被误导；安装介质的zip包如果服务器空间紧张，安装完就可以删了，不影响运行。Oracle 11g毕竟是老软件，能用但不代表什么事情都适合它，如果业务允许，还是要把“未来升级”提上日程，至少要让这套环境具备可备份、可重建的能力。

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