在 Oracle Linux 7 环境中部署 Oracle 11gR2 时，最省心的方法并非手动逐个安装几十个 RPM 包，而是直接安装一个元包——oracle-rdbms-server-11gR2-preinstall.x86_64。该包不含数据库本体，但能自动拉齐所有依赖项、创建 oracle 用户，并配置好内核参数与资源限制。
不过，前提是 yum 源必须正确配置，否则执行 yum install 只会收到“No package available”的提示。该元包只能从 ol7_latest 或 ol7_uX_base 这两个仓库获取，默认的 base 和 updates 仓库中不存在。建议先用 yum repolist 确认仓库状态是否为 enabled。
本地 ISO 源配置容易遗漏的关键路径
将 Oracle Linux 7 的 ISO 挂载到 /mnt 后，很多人以为 baseurl=file:///mnt 就能直接使用，结果却报错找不到包。问题出在 ISO 内部结构：RPM 包实际存放在 /mnt/Server/Packages 或 /mnt/BaseOS/Packages 目录下，具体取决于 ISO 版本。早期 OL7.0–7.6 使用 Server 目录，OL7.9+ 使用 BaseOS 目录。
- 正确写法：
baseurl=file:///mnt/BaseOS/Packages（新版）或file:///mnt/Server/Packages（旧版） gpgcheck=0必须显式设为 0，否则本地源因缺少 GPG 密钥会失败；enabled=1也不能少- 执行
yum clean all && yum makecache后再试，旧缓存可能掩盖路径错误
离线环境必须禁用 gpgcheck 并跳过 metadata 验证
网络不可达时，yum 默认会尝试连接远程元数据服务器验证仓库，导致超时卡住。即使本地源配置正确，也可能卡在“Metadata Cache Created”之前。
- 临时方案：加上
--nogpgcheck参数，例如yum install --nogpgcheck oracle-rdbms-server-11gR2-preinstall - 永久方案：在 repo 文件中设置
gpgcheck=0和metadata_expire=0，防止 yum 定期检查过期 - 若仍提示“Cannot retrieve metalink”，说明 yum 仍在尝试联网——检查是否启用了其他远程源（如
epel），用yum repolist enabled确认只保留本地源
依赖包版本冲突常源于混用 CentOS 和 OL 源
在 Oracle Linux 7 上误加 CentOS 的 epel 或 baseos 源，会导致 glibc、libaio 等关键包版本不一致，yum install 报“package conflicts with…”或“requires newer version”。Oracle 官方包只适配 OL 自带的内核和库版本。
- 删除所有非 Oracle 官方的 .repo 文件，只保留
public-yum-ol7.repo或你自建的本地源文件 - 运行
yum distro-sync强制对齐系统基础包版本，再重试 preinstall 安装 - 如果已安装冲突包，用
rpm -e --nodeps 包名卸载后再走 yum 流程，不要硬凑rpm -ivh
实际部署时，最常卡住的问题并非命令本身，而是源路径写错、gpgcheck 未关闭、或者多源混用导致的静默冲突。确认好这三点，oracle-rdbms-server-11gR2-preinstall 就能真正发挥“自动装全依赖”的作用。
