如何解决Oracle 19c在麒麟系统中因glibc版本引发的冲突？

直接结论：不要升级系统glibc，优先用软链接、环境变量或容器隔离来绕过版本检查；麒麟V10默认glibc≥2.28已移除Oracle 19c依赖的GLIBC_2.14、CXXABI_1.3.9等符号，需通过ln -s伪造libnsl.so.1、拷贝libpthread_nonshared.a、设置CV_ASSUME_DISTID=RHEL7.6及容器化等方式安全适配。

直接结论：不要升级系统glibc，优先用软链接、环境变量或容器隔离来绕过版本检查。 麒麟v10默认glibc版本（2.28+）已移除oracle 19c依赖的符号（如glibc_2.14、cxxabi_1.3.9），硬升或降系统级glibc极易导致系统崩溃。

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

Oracle 19c二进制是用较老glibc（如RHEL7的2.17）编译的，运行时会显式查找GLIBC_2.14、CXXABI_1.3.9等符号。而麒麟V10SP3+内建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<br>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（大页支持）
• 注意：麒麟V10SP3+内核已支持cgroup v2，启动容器前确认Docker配置启用cgroupfs驱动

最容易被忽略的一点：所有软链接和环境变量必须在oracle用户下生效，且不能依赖root shell的临时设置。静默安装时db_install.rsp里不读环境变量，所以CV_ASSUME_DISTID必须在执行./runInstaller的同一shell中导出。