直接结论：不要升级系统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中导出。
