Oracle 19c麒麟系统glibc版本冲突解决方法

今天，我们来探讨一个许多麒麟V10用户频繁遇到的棘手问题——Oracle 19c在安装或运行过程中反复出现glibc符号缺失错误。先给出核心结论：请务必不要升级系统级glibc，优先采用软链接、环境变量或容器化方案来绕过版本检查。 麒麟V10默认的glibc版本为2.28及以上，而Oracle 19c所依赖的GLIBC_2.14、CXXABI_1.3.9等符号，在该版本中已被移除——并非未安装，而是库本身将这些旧符号删除了。强行升级或降级系统级glibc，极有可能导致系统崩溃，这一代价任何用户都难以承受。

为什么Oracle 19c会报glibc符号缺失？

Oracle 19c的二进制程序基于较老的glibc版本（例如RHEL 7自带的2.17）编译而成。运行时，它会自动查找GLIBC_2.14、CXXABI_1.3.9等符号。而麒麟V10 SP3及以上系统的内置glibc版本≥2.28，这些旧符号已被废弃——执行ldd --version显示版本为2.28，但使用strings /lib64/libc.so.6 | grep GLIBC_2.14检查时，返回结果为空。这就是问题的根源所在。

用软链接伪造缺失的符号版本（最常用）

这里所说的“伪造”并非欺骗系统，而是让Oracle的加载器能够找到它期望的符号入口。关键点在于：仅伪造Oracle实际调用的那几个符号，切勿对整个libc库进行改动。

• 首先确认缺失项：运行LD_DEBUG=libs $ORACLE_HOME/bin/sqlplus /nolog 2>&1 | grep "not found"
• 最常需要伪造的库：libnsl.so.1、libpthread_nonshared.a
• 以libnsl为例，执行如下命令：

sudo yum install libnsl -y
sudo ln -s /lib64/libnsl.so.2.0.0 /lib64/libnsl.so.1

对于libpthread_nonshared.a，可从CentOS 7或RHEL 7机器上将文件复制到/usr/lib64/，然后执行chmod 644 /usr/lib64/libpthread_nonshared.a。

用CV_ASSUME_DISTID骗过安装器的glibc检查

Oracle的安装脚本在预检阶段会根据CV_ASSUME_DISTID来推断目标系统的glibc能力。将其设为旧系统ID，即可跳过部分符号校验。

• 必须在执行runInstaller或dbca之前设置：export CV_ASSUME_DISTID=RHEL7.6
• 不能仅设置一次：每次新shell都需要重新设置，因此建议写入oracle用户的.bash_profile
• 建议配合export LANG=en_US一起使用，以避免PRVG-0282等字符集干扰

真正安全的长期方案：容器化部署

在麒麟宿主机上使用Docker运行一个RHEL 7或CentOS 7镜像，将Oracle 19c安装在其中。这样既能满足Oracle对glibc的依赖要求，又不会污染宿主系统。

• 镜像选择：registry.access.redhat.com/rhel7:7.9 或 centos:7
• 关键挂载参数：-v /u01:/u01:shared（共享存储）、--ulimit memlock=-1（大页支持）
• 注意：麒麟V10 SP3及以上内核已支持cgroup v2，启动容器前需确认Docker配置启用了cgroupfs驱动

最后提醒一个最容易被忽视的细节：所有软链接和环境变量必须在oracle用户下生效，切勿依赖root shell的临时设置。静默安装时db_install.rsp不读取环境变量，因此CV_ASSUME_DISTID必须在执行./runInstaller的同一个shell中导出，否则等同于无效配置。