一、故障描述
某次，用户某套数据库在 2023 年 2 月 15 早上 9 点 46 分后应用报无法连接数据库，数据库 Alert 日志明显出现 ORA-00600 和 ORA- 27300 、 ORA- 27301 、 ORA-27302 等报错信息，详细日志如下：
同时，我们同步检查了该节点集群 ASM 实例和 CSS 服务，均出现异常，导致业务不可用，日志如下：
二、根因分析
经过紧急分析，通过告警日志错误关键字，我们在 MOS 匹配到类似场景： ORA-00600 [ksm_mga_pseg_cbk_attach:map_null] reported by database when issuing NFS mount causing /dev/shm/ to become unavailable on Redhat 7 servers (Doc ID 2703432.1) ，同样是在 19.6 数据库版本上命中该报错，如下：
而在该场景中，这个问题是由 mount -a 操作导致 fstab 刷新，引起操作系统重新装载内存段 /dev/shm 。新的装载会删除 Oracle 正在使用的内存段，并将其替换为新的空内存段，从而会对正在运行业务的 Oracle 造成灾难性的影响。如下：
为了证实是否因为 mount -a 导致，我们与用户进行了深入交流，并在相关数据库服务器上排查故障时间段执行过的操作的审计记录。如下：
shell> pvcreate /dev/mapper/mpathq
shell> vgcreate vgarch /dev/mapper/mpathq
shell> lvcreate -l 76794 -n lvarch vgarch
shell> mkfs.xfs /dev/vgarch/lvarch
shell> mkdir /int_arch
shell> vim /etc/fstab
/dev/vgarch/lvarch /int_arch xfs defaults 0 0
shell> mount – a
至此，我们获取到了关键的 “证据”，故障时间段之前，确实有人创建了逻辑卷并计划用于日志归档，由于执行了 mount -a ，也就引发了此次故障。其实回过头来讲，将挂载信息写入 fstab 文件并没有问题，关键在于用户可以选择手动挂载归档文件系统，这样可以降低出故障的风险，当然这是后话了。
三、解决方案
当然，如果还是想正常执行 mount -a ，以下也提供几种方法进行规避。
1 、进行 mount -a 操作前关闭数据库实例
2 、注销 fstab 中 /dev/shm 的挂载操作
3 、将 fstab 中的 /deb/shm 移出。
