一、案例背景
某银行客户一套生产系统出现存储磁盘链路问题,其中一块MAP到主机的磁盘频繁出现链路全部丢失的情况,导致其所在的存放索引数据(600GB)的磁盘组dismount,进而造成相关业务查询缓慢、数据库备份失败等现象。交换机、存储等设备厂商排查后,并未发现异常,但链路丢失的现象仍时常发生。客户希望通过磁盘组替换磁盘的方式排除故障,工程师现场调研后,制定了实施方案及应急措施。
二、信息收集
1、数据库信息
版本:Oracle 11.2.0.3
环境:RAC双节点
磁盘组信息,故障盘所在的磁盘组为外部冗余模式:
DGSYS 存放系统表空间、UNDO表空间等;
DGARCH 存放归档;
DGADATA 存放业务数据;
DGAINDEX 存放相关索引;
DGBDATA 存放业务数据;
DGBIDX 此磁盘组为故障盘所在的磁盘组,存放索引数据;
2、操作系统版本
ASianux Server 3.1
3、备份信息
由于故障磁盘链路频繁failed,数据库备份失败,无备份信息;
4、DGBIDX磁盘组信息
DGBIDX磁盘组共有三块盘,其中一块磁盘disk3最近频繁出现全部链路failed的情况,该磁盘组3块盘均来自同一台存储,另外2块盘一切正常:
![1621315830966488.png image001.png](/data/upload/image/20210518/1621315830966488.png)
联合存储、交换机、操作系统厂商共同排查,未确认故障原因,故对该盘进行替换操作。由于该磁盘组使用率高,在替换硬盘的同时对该磁盘组进行扩容:
multipath -ll>/tmp/mpath
more /tmp/mpath |grep disk3
可以看到disk3大小为200G,8条链路全部failed,DGBIDX磁盘组在二节点上是dismounted的状态:
![1621316013522617.png image003.png](/data/upload/image/20210518/1621316013522617.png)
![1621316285377240.png image005.png](/data/upload/image/20210518/1621316285377240.png)
三、风险评估
1、该存储盘故障频发,无法预测在替换磁盘的过程中,链路是否会发生故障。链路错误会导致磁盘组dismounted重平衡失败,此时主机必须重新认到磁盘才能继续重平衡;
2、此数据库未备份,直接操作风险较大,且停机窗口有限,一旦出现问题,无法继续操作;
3、索引表空间的数据,可以容忍数据丢失。
综合以上情况,工程师决定将现有存储上MAP给主机8块新盘,如果操作时间窗口内发生异常,则新建一个磁盘组,重建索引表空间及索引数据,可保证客户正常业务。
四、实施步骤
1、查看状态
磁盘组添加磁盘并查看相关磁盘状态:
![1621317080315267.png image007.png](/data/upload/image/20210518/1621317080315267.png)
2、重现故障
查询结果为DGBIDX磁盘组dismount,后手工mount报错,磁盘链路又发生故障。
![1621317147187824.png image009.png](/data/upload/image/20210518/1621317147187824.png)
![1621317164733702.png image011.png](/data/upload/image/20210518/1621317164733702.png)
查询disk3盘链路状态为failed ,重新multipath -F multipath -v2扫描后,链路状态恢复正常:
![1621317237329333.png image013.png](/data/upload/image/20210518/1621317237329333.png)
重新启动集群 ,DGBIDX磁盘组依旧是dismount状态;
查看message日志发现:只要启动集群,mount DGBIDX磁盘组时,disk3盘链路状态就会变为failed:
![1621317369305687.png image015.png](/data/upload/image/20210518/1621317369305687.png)
五、应急方案
1、新建磁盘组,重建索引数据
因停机时间窗口有限,在操作前已制定应急方案:若出现异常情况,可放弃索引数据,而后进行重建。此方案需要先开库,保障业务连续性。开库须将故障磁盘组中的所有数据文件下线,数据库启动到OPEN状态。但此时由于磁盘故障,磁盘组无法挂载,数据库只能启动到mount状态:
![1621318524914902.png image017.png](/data/upload/image/20210518/1621318524914902.png)
使用操作前新MAP的8块磁盘重新创建DGBIDXNEW磁盘组,创建DGBDX_NEW表空间,并添加20个数据文件:
![1621317564256286.png image019.png](/data/upload/image/20210518/1621317564256286.png)
![1621317575927969.png image021.png](/data/upload/image/20210518/1621317575927969.png)
最后由重建相关业务表索引到新建表空间。
2、选择性数据备份
由于旧磁盘组是dismounted状态,客户需要保留故障环境继续排查,所以全备时要排除旧的表空间数据文件,通过rman设置将DGBIDX表空间排除备份,以保证后续备份正常。
![1621317630927967.png image023.png](/data/upload/image/20210518/1621317630927967.png)
3、硬件厂商收集相关日志信息,继续排查故障。
六、经验总结
1、此次磁盘组替换磁盘的操作,由于当前存储盘的不稳定导致风险性很高,尤其在未备份的情况下,一旦出现问题就可能导致数据丢失,所以在操作前务必制定实施方案及应急方案;
2、操作过程再次证明了应急方案的重要性。由于故障盘所在的磁盘组仅存放索引数据,可以接受选择性丢失,处理起来相对简单。但如果事前没有根据应急方案给主机MAP新盘,那么在停机窗口内无法完成后续操作,必然影响正常业务;
3、如果业务磁盘组因磁盘链路不稳定发生故障,不能使用此种替换磁盘的方法。此时可以采用逻辑导出/导入的方式,移动数据到新位置等方式。
如欲了解更多,请登录365足球体育投注官方网站:228214.web-sitemap.dbayscpa.com