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

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

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

1 空间异常

首先是EMCC巡检发现三个存储节点操作系统都有空间告警,到对应服务器检查,/var/log挂载点空间使用量均超过80%:
数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理(20230928)_第1张图片
通过进一步检查/var/log中所有文件加起来没有实际占用那么大,这是怎么回事呢?当然一体机嘛,第一件事情就是开个Linux OS的SR,然后再一步一步排查。

2 排查过程

首先/var/log里面最大的文件夹是journal,首先检查journalctl持久化的问题,然而检查配置文件是全注释状态,journal的问题就排除了。此时SR还没有给出任何有用的回复,我只能进一步排查。Linux上还有一种空间没有释放的现象,就是通过lsof的方式去检查删除操作是否完成,不查不知道,一查吓一跳:
数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理(20230928)_第2张图片
在这里插入图片描述
一个存储节点挂住了4740个与/var/log相关的删除操作,这也是df -h输出空间未释放的重要原因。将这一结果反馈SR,SR也同时通过新的上传文件与之前上传的SOSReport确认了空间未释放的原因,并建议通过杀掉相关进程处理。
但是经过排查相关进程均有Exadata Storage Software发起,贸然杀掉进程会导致存储节点出现异常,大概率引起一体机上运行数据库出现异常。而不释放空间,SR也确认当/var/log在df -h输出结果到100%时,操作系统将出现问题,因此这时候重启存储节点成了唯一选择。

3 问题处理

首先,这台一体机承载的是分析型业务,因此晚上的压力比白天大,也因此白天操作比晚上操作更合适,首先检查一下当前一体机存储侧整体性能压力情况:
数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理(20230928)_第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';

数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理(20230928)_第4张图片
如果你的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

数据库管理-第108期 因Exadata存储节点操作系统空间异常的紧急处理(20230928)_第5张图片
这里通过以下命令将该存储节点磁盘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进一步跟进。
老规矩,知道写了些啥。

你可能感兴趣的:(Oracle,数据库,oracle,服务器)