数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理（20230928）

数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理（20230928）

众所周知，明天放假了，本着对客户数据库软硬件负责任的态度，进行了一次深入彻底的软硬件巡检（就是检查包括计算节点、存储节点、交换机等各个组件）。不查不知道，一查吓一跳，我这某一台一体机的存储节点闹出了一些问题。

1 空间异常

首先是EMCC巡检发现三个存储节点操作系统都有空间告警，到对应服务器检查，/var/log挂载点空间使用量均超过80%：

通过进一步检查/var/log中所有文件加起来没有实际占用那么大，这是怎么回事呢？当然一体机嘛，第一件事情就是开个Linux OS的SR，然后再一步一步排查。

2 排查过程

首先/var/log里面最大的文件夹是journal，首先检查journalctl持久化的问题，然而检查配置文件是全注释状态，journal的问题就排除了。此时SR还没有给出任何有用的回复，我只能进一步排查。Linux上还有一种空间没有释放的现象，就是通过lsof的方式去检查删除操作是否完成，不查不知道，一查吓一跳：


一个存储节点挂住了4740个与/var/log相关的删除操作，这也是df -h输出空间未释放的重要原因。将这一结果反馈SR，SR也同时通过新的上传文件与之前上传的SOSReport确认了空间未释放的原因，并建议通过杀掉相关进程处理。
但是经过排查相关进程均有Exadata Storage Software发起，贸然杀掉进程会导致存储节点出现异常，大概率引起一体机上运行数据库出现异常。而不释放空间，SR也确认当/var/log在df -h输出结果到100%时，操作系统将出现问题，因此这时候重启存储节点成了唯一选择。

3 问题处理

首先，这台一体机承载的是分析型业务，因此晚上的压力比白天大，也因此白天操作比晚上操作更合适，首先检查一下当前一体机存储侧整体性能压力情况：

首先并没有超过性能上限的2/3（其实X8M性能比这个上限还要高不少，但是得保险啊），接着就是如何安全的重启存储节点而对数据库没有影响，由于SR没有快速回复，这里就发挥传统艺能，找后台小姐姐，这时小姐姐也正好在旅游转机过程中，非常幸运的拿到了对应文档Steps to shut down or reboot an Exadata storage cell without affecting ASM ( Doc ID 1188080.1 ) （当然后来SR也反馈了中文版对应文档如何在不影响 ASM 的前提下对 Exadata 存储节点关机或重启 ( Doc ID 1943722.1 )），那么开干：

3.1 检查ASM磁盘组修复时限

首先如果ASM磁盘组中的磁盘超过了DISK_REPAIR_TIME设置时限会被直接舍弃，需要重新加入ASM磁盘组导致一些麻烦，我这里默认配置是12小时，重启操作不会花费那么长时间，而文档建议是不低于8.5小时：

sqlplus / as sysasm
select dg.name,a.value from v$asm_diskgroup dg, v$asm_attribute a where dg.group_number=a.group_number and a.name='disk_repair_time';

如果你的ASM磁盘组的DISK_REPAIR_TIME设置时间过短，可以通过一下命令进行调整，该操作同样适合非一体机开启非外部冗余的环境，用于存储设备维护：

ALTER DISKGROUP XXX SET ATTRIBUTE 'DISK_REPAIR_TIME'='8.5H';

3.2 将存储节点DISK OFFLINE

这里需要先检查操作存储节点的磁盘情况：

cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

这里通过以下命令将该存储节点磁盘offline:

cellcli -e alter griddisk all inactive

操作会执行一段时间，完成后在检查磁盘情况，asmmodestatus会变成"OFFLINE"状态。
同时其他节点检查磁盘状态asmdeactivationoutcome会变成"Cannot de-activate due to other offline disks in the diskgroup"状态进而无法被OFFLINE。

3.3 重启存储节点

以下命令会立即重启 Oracle Exadata 存储节点并在重启时强制调用 fsck：

shutdown -F -r now

3.4 将存储节点DISK ONLINE

cellcli -e alter griddisk all active

这时候检查磁盘状态，asmmodestatus会变成"SYNCING"状态，这时候该存储节点的磁盘会进行Fast Mirror Resync，只会重建磁盘离线后被修改过的数据，不会触发ASM Rebalance，因此同步时间不会很久，大概跟OFFLINE到ONLINE的时间差不多。
Fast Mirror Resync完成之后asmmodestatus会变成ONLINE。
同时其他存储节点上磁盘的asmdeactivationoutcome也会变回为"Yes"。即代表可以在其他节点进行操作。
如果想查看Fast Mirror Resync的大致，通用可以在ASM实例中通过v$asm_operation进行查看。

3.5 重启其他存储节点

接下来就是按照上面的操作分步将其他的存储节点重启。

总结

虽然存储节点操作系统空间异常的问题解决了，保证了中秋+国庆该一体机的安全稳定运行，但是出现这一问题的原因还是需要排查的，后续也会和SR进一步跟进。
老规矩，知道写了些啥。