作者：技术从业16年，踩过坑、做过技术负责人、带过团队，也亲眼看着AI把很多"理所当然"的事情重新洗牌。这个号不追热点，只写真实踩过的坑和总结过的东西，欢迎关注一起交流。

起因：一个不该接的活儿

周一早上，项目组丢过来一个需求：在测试环境搭一套 Oracle 26ai。

需求本身不复杂，复杂的是后半句——机器是 openEuler 24.03。

我做这行十六年，Oracle 装过无数次，但有个常识刻在骨子里：Oracle 只在它认证过的系统上"包活"。Oracle Linux、RHEL，这些是亲儿子；openEuler，连干儿子都算不上。让 Oracle 跑在非认证系统上，就像让一辆调校好的德系车去跑没铺过的土路——能跑，但你心里清楚哪里会颠。

我本想回一句"建议换 Oracle Linux"，但测试环境就这一台机器，预算不会再批第二台。客户指定要 26ai，机器指定是 openEuler。

那就硬上。

这篇记录的就是这场"违规操作"的全过程。如果你哪天也遇到"非认证系统硬装 Oracle"的活儿，照着走，能少走至少两天弯路——我把能踩的坑都踩了。

---

第一个坎：连安装包都下不到

装 Oracle，第一关不是技术，是下载。

Oracle 的 EE RPM 在 OTN（Oracle Technology Network）上，理论上点一下就能下。实际操作时我才发现：所有直链、镜像、eDelivery，最后都重定向到 SSO 登录页。 没账号？对不起，下不了。

我在网上搜了一圈野路子——预配置的 preinstall RPM 是公开的，能下到；但主体那个 2.1G 的 EE 包，绕来绕去都要登录。

折腾半天，我放弃了找捷径。老老实实登录官网，下了 oracle-ai-database-ee-26ai-1.0-1.el9.x86_64.rpm。 注意选 el9（RHEL 9 系）的包，openEuler 跟它最接近，这是后面能强装成功的伏笔。

这一关给我的教训很朴素：别在下载上耗时间。 厂商把付费/登录墙砌在那，就是挡你这条路。注册个账号，十分钟的事，比找镜像省心。

---

系统准备：老规矩，先调系统再装软件

很多人一上来就 rpm -ivh，结果卡在内核参数、用户权限上反复折腾。我的习惯是反过来：先把系统调顺，软件装起来才不返工。

这一步不展开讲细节（命令网上一搜全是），只说我一定会做的几件事：

• 依赖补全：libaio libnsl ksh sysstat unixODBC 这些一个不能少。openEuler 默认不带 libnsl 和 ksh，漏了 sqlplus 和安装脚本直接报命令找不到。
• 内核参数：kernel.shmmax 设成物理内存一半左右，否则建库时 SGA 分配不开，DBCA 会默默失败。
• 关 SELinux、开 1521 端口：测试环境直接 permissive，别折腾 enforcing 策略，省下的时间够陪娃写完作业。
• 建 oracle 用户和组：oinstall/dba 这些常规操作。

这里其实有个偷懒的办法：先装 oracle-database-preinstall 那个 RPM，它会自动帮你建用户、调内核、设 limits。我上面拆开写是为了讲清楚原理，实际操作时可以先装它再补缺的参数。

系统调顺了，进入正题。

---

冲突升级：–nodeps 赌一把

软件包传上去，开装。

先装 preinstall，顺利。接着装 EE 主体：

rpm -ivh oracle-ai-database-ee-26ai-1.0-1.el9.x86_64.rpm

报错。一堆依赖检查失败——因为它校验的是 el9 特定版本的包名，openEuler 的对不上。

这是个岔路口。常规思路是：缺啥补啥，一个一个把依赖装齐。但 el9 的包名跟 openEuler 的源对不上，你没法 1:1 补。

我盯着屏幕想了一会儿，做了个决定：

rpm -ivh --nodeps oracle-ai-database-ee-26ai-1.0-1.el9.x86_64.rpm

--nodeps，跳过依赖检查，强装。

这不是耍流氓。 我心里清楚：Oracle 的 RPM 依赖检查是按 el9 写死的，版本号对不上是"形式问题"；但实际运行所需的 .so 库，我前面都装齐了，是"实质没问题"。形式错了，实质对了——这种情况强装能成。

但前提是：你真的把依赖补全了。 --nodeps 只是把检查关掉，不会凭空变出缺失的库。如果你 libaio、libnsl 这些没装就强装，装是装上了，跑起来一堆 cannot open shared object file，排查更痛苦。强装是赌，但得是"算过牌的赌"。

回车，装完了。ORACLE_HOME 在 /opt/software/openGauss……不对，Oracle 这边是 /opt/oracle/product/26ai/dbhome_1。软件铺好了。

我松了口气，倒了杯水。以为最难的部分过去了。

真正的麻烦，才刚开始。

---

高潮：DBCA 建库，oradism 报错 PRVG-2031

软件装好只是半成品。数据库实例得靠 DBCA 创建。Oracle 26ai 的 RPM 自带一个脚本：

/etc/init.d/oracledb_ORCLCDB-26ai configure

它内部调 DBCA 静默建库，生成 CDB（ORCLCDB）+ PDB（ORCLPDB1）。我执行下去，跑到一半，红字报错跳出来：

PRVG-2031 : expected owner root(0) of file 
".../bin/oradism" but found oracle(54321)

DBCA 直接退出。建库失败。

那一刻我心里咯噔一下。--nodeps 强装那步埋的雷，现在爆了。

我的第一反应是慌：是不是强装把哪个关键文件权限搞坏了？是不是这个非认证系统根本带不动，得换 OS 重来？如果真要换系统，今天交付不了，整个排期都要崩。

深呼吸，先看报错本身在说什么。

---

排查：oradism 是什么？为什么属主必须是 root？

报错信息其实很明确：有个叫 oradism 的文件，Oracle 期望它的属主是 root，但实际是 oracle。

我先搞清楚 oradism 是干嘛的。查了一下——它是 Oracle 的一个 setuid 程序，用来让 Oracle 进程切换资源调度优先级（CPU 调度策略那块）。setuid 的含义是：程序执行时，以文件属主的身份运行，而不是执行者的身份。 这就是为什么它必须属主是 root——它需要 root 权限来做优先级切换。

那为什么属主变成 oracle 了？就是 --nodeps 强装留下的后遗症。 正常安装流程里，有个 root 脚本会把所有 setuid 二进制的属主改回 root；但我强装时跳过了部分依赖检查，这个修权步骤没完整执行，于是 oradism 留着 oracle 属主，DBCA 校验时发现了，认为不安全，拒绝继续。

根因清晰了：不是系统带不动，不是 OS 不兼容，就是强装后一个 setuid 程序的属主没修对。 这个问题好解决。

---

解决方案：chown 修一个，root.sh 修一窝

最直接的办法是手动改属主和权限：

chown root:oinstall /opt/oracle/product/26ai/dbhome_1/bin/oradism
chmod 4750 /opt/oracle/product/26ai/dbhome_1/bin/oradism

4750 里的 4 就是 setuid 位。改完 oradism 一个文件就能让 DBCA 过。

但我没只改这一个。我想到：oradism 只是被 DBCA 主动校验的那个，ORACLE_HOME 里还有别的 setuid 二进制（nmo、extjob 等），它们没被校验，但属主一样是错的。 现在不修，将来跑 job、监控时还会爆。

所以更彻底的做法是跑一遍 root.sh，它会批量修好所有 setuid 二进制：

/opt/oracle/product/26ai/dbhome_1/root.sh

一劳永逸。跑完，重新执行 configure：

/etc/init.d/oracledb_ORCLCDB-26ai configure

这次 DBCA 顺利跑完。CDB 建好了，PDB 建好了。

从报错到解决，差不多一小时。 这一小时里大部分时间花在"搞清楚 oradism 是什么、setuid 是什么"上，真正改命令就两行。

这就是排查的常态：找根因的时间，远大于改代码的时间。 新人容易在这里栽——一看到报错就急着搜"怎么解决"，但没先搞懂"为什么报错"，结果照着网上半通不通的方案瞎试，越试越乱。我的习惯是：先读懂报错信息在指控什么，再决定动哪里。

---

小反转：root.sh 的"无效用户"假警报

本以为尘埃落定，root.sh 跑的时候又蹦出来一行：

无效的用户: oracle_ee:oinstall

我第一反应又是心里一紧。仔细一看，rootinstall.sh 里把 ORACLE_OWNER 写成了 oracle_ee，但 init 脚本里用的是 oracle，两个对不上，于是报了个"无效用户"。

但实测 oratab、二进制、数据库实例全都正常工作。 这是个纯化妆性警告，不影响任何功能。

带团队这些年，我特别怕新人遇到这种"看着吓人其实没事"的报错。新人一搜，网上一堆说"要重装"，然后真的去重装，折腾大半天。我的原则是：先看现象能不能往下走，能走就记下来继续，回头再查根因。 别让一个 warning 卡住整个交付节奏。判断 fatal 还是 warning 的能力，是初级和中级的一道分水岭。

---

验证：一条命令见分晓

配了几件事就到了验证环节：

• 自动启动已配置（/etc/oratab 里设为 Y）
• 字符集 AL32UTF8（支持中文）
• 监听 1521 已起

登录验证：

su - oracle
sqlplus / as sysdba

SQL> select banner_full from v$version;
-- Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0

SQL> show pdbs;
-- ORCLPDB1  READ WRITE

SQL> select name, open_mode from v$database;
-- ORCLCDB   READ WRITE

远程连接也通了：

sqlplus system/Oracle26ai!Sys@192.168.17.199:1521/ORCLCDB

数据库起来了。 非认证系统，强装，从 PRVG-2031 到 OPEN，全程没换系统。

我关掉终端，把这次装的密码、路径、坑都记进了文档。这套环境后来稳稳跑了整个测试周期。

---

复盘：这次安装留下的五条铁律

回看这场"违规操作"，把经验浓缩成五条，建议你截图存档：

1. 内存别抠门。 Oracle 是吃资源的怪兽，低于 4G 别装，Swap 至少跟内存等量。DBCA 建库时内存吃紧会默默失败，日志里才看得出来，这种失败最磨人。

2. --nodeps 是"算过牌的赌"，前提是依赖真补全。 它只关掉检查，不凭空造库。libaio、libnsl、ksh、unixODBC 必须到位。否则装上跑不起来，cannot open shared object file 满屏，比装不上更难受。

3. setuid 二进制必须属主 root。 强装后 oradism、extjob、nmo 这些 setuid 程序属主常被改成 oracle，导致 DBCA 和后续 job 失败。跑一遍 root.sh 一劳永逸，别只修被报错点名的那个。

4. 字符集一次定终身。 AL32UTF8 是首选，支持中文。建库后改字符集是地狱级操作（要重建控制文件），生产尤其要一次定对。

5. 报错先读懂再动手。 PRVG-2031 那一小时，大部分时间花在搞懂"oradism 是什么、setuid 是什么"，改命令就两行。找根因的时间永远大于改代码的时间。 这个习惯，是初级走向中级的分水岭。

---

写在最后

装一个数据库，命令百度都能搜到。但哪些步骤能省、哪些坑必须绕、报错了怎么判断是 warning 还是 fatal——这些是文档不写的，得靠踩。

我自己也是踩过来的。十六年前第一次装 Oracle 10g，对着 runInstaller 的图形界面卡了三天，后来才知道是 X11 转发没配。现在回看，那些弯路都是学费。

如果你也在带团队，或者刚从开发转 DBA，记住一件事：把每次踩的坑写下来，哪怕只是一条备忘。 三年后你会发现，这些零碎记录就是你最值钱的东西——比任何证书都管用。