一个清晨，某医疗客户的 IT 运维团队刚完成 Oracle 19c RAC 环境到 19.24 补丁的升级工作，正准备松口气，却被一个紧急情况打了个措手不及 —— 数据库实例无法正常启动了。
起初，工程师们尝试用 spfile 启动数据库，可无论怎么操作，数据库都只能停留在 NOMOUNT 状态，再也无法继续向前推进。大家心里咯噔一下，赶紧去查看 Alert 日志，发现里面赫然显示着 ASMB 进程报错，说是尝试读取 ASM 磁盘时失败了，这才导致启动过程卡壳。
本以为这样就能高枕无忧，可没过几小时，服务器因为一些其他原因重启后，数据库再次 “罢工”，依旧顽固地停留在 NOMOUNT 状态。这一下，大家都有些懵了，刚才的操作明明见效了，怎么会又出问题呢？
工程师们不死心，再次尝试将数据库启动到 MOUNT 状态，这次又出现了新的报错：“ORA01017: invalid username/password; logon denied”。一开始，大家还以为是权限问题再次冒了出来，又动手修改了一遍权限，可数据库还是纹丝不动，启动失败的局面丝毫没有改变。
接连的挫败让团队陷入了沉思，到底是什么原因在作祟呢？就在大家一筹莫展的时候，有人提议去查查 MOS（My Oracle Support）文档，看看有没有类似的案例。
功夫不负有心人，在翻阅大量文档后，他们找到了 MOS 号为 2919585.1 的文档。文档里明确指出，Oracle 19c 在打上 19.23 或以上补丁版本后，存在与用户组权限相关的问题。具体来说，Oracle 实例的运行用户 oracle 和集群管理用户 grid 在某些情况下没有被正确加入到必要的组中，这就会导致权限出问题，进而影响数据库启动。
看到这里，大家眼前一亮，赶紧去检查 oracle 用户和 grid 用户的组配置。这不查不知道，一查果然发现了问题—— 这两个用户竟然都没有在 oinstall 组里。而 oinstall 组可是 Oracle 数据库和 Grid 控制集群所需的最基本权限组啊。
找到症结所在，解决起来就顺理成章了。工程师们立刻执行命令 “usermod -a -G oinstall grid” 和 “usermod -a -G oinstall oracle”，将 grid 和 oracle 用户都添加到了 oinstall 组中。
完成权限修改后，大家屏住呼吸重启了数据库实例。随着启动进度条一点点推进，数据库成功启动，并顺利恢复到了正常的 OPEN 状态。那一刻，整个团队都松了一口气。
修改前：
这次故障排查让大家深刻认识到：Oracle 19c 在打上 19.23 或以上版本的补丁后，真的可能会遇到用户组权限丢失或错误配置的问题，尤其是 oracle 和 grid 用户的组配置。在集群环境中，确保这两个用户正确加入 oinstall 组至关重要，权限配置不当，数据库很可能就无法正常启动。
未来，在进行 Oracle 补丁升级时，特别是针对 19c 版本，大家一致决定，务必先检查和确认用户组权限，绝不能再因为权限配置不当而让数据库 “罢工” 了。
