今天，我们来探讨一个许多麒麟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中导出，否则等同于无效配置。