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