一、案例背景

某银行客户一套生产系统出现存储磁盘链路问题，其中一块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块盘一切正常：

联合存储、交换机、操作系统厂商共同排查，未确认故障原因，故对该盘进行替换操作。由于该磁盘组使用率高，在替换硬盘的同时对该磁盘组进行扩容：

multipath -ll>/tmp/mpath

more /tmp/mpath |grep disk3

可以看到disk3大小为200G，8条链路全部failed，DGBIDX磁盘组在二节点上是dismounted的状态：

三、风险评估

1、该存储盘故障频发，无法预测在替换磁盘的过程中，链路是否会发生故障。链路错误会导致磁盘组dismounted重平衡失败，此时主机必须重新认到磁盘才能继续重平衡；

2、此数据库未备份，直接操作风险较大，且停机窗口有限，一旦出现问题，无法继续操作；

3、索引表空间的数据，可以容忍数据丢失。

综合以上情况，工程师决定将现有存储上MAP给主机8块新盘，如果操作时间窗口内发生异常，则新建一个磁盘组，重建索引表空间及索引数据，可保证客户正常业务。

四、实施步骤

1、查看状态

磁盘组添加磁盘并查看相关磁盘状态：

2、重现故障

查询结果为DGBIDX磁盘组dismount,后手工mount报错，磁盘链路又发生故障。

查询disk3盘链路状态为failed ，重新multipath -F multipath -v2扫描后，链路状态恢复正常：

重新启动集群 ,DGBIDX磁盘组依旧是dismount状态；

查看message日志发现：只要启动集群，mount DGBIDX磁盘组时，disk3盘链路状态就会变为failed：

五、应急方案

1、新建磁盘组，重建索引数据

因停机时间窗口有限，在操作前已制定应急方案：若出现异常情况，可放弃索引数据，而后进行重建。此方案需要先开库，保障业务连续性。开库须将故障磁盘组中的所有数据文件下线，数据库启动到OPEN状态。但此时由于磁盘故障，磁盘组无法挂载，数据库只能启动到mount状态：

使用操作前新MAP的8块磁盘重新创建DGBIDXNEW磁盘组，创建DGBDX_NEW表空间，并添加20个数据文件：

最后由重建相关业务表索引到新建表空间。

2、选择性数据备份

由于旧磁盘组是dismounted状态，客户需要保留故障环境继续排查，所以全备时要排除旧的表空间数据文件，通过rman设置将DGBIDX表空间排除备份，以保证后续备份正常。

3、硬件厂商收集相关日志信息，继续排查故障。

六、经验总结

1、此次磁盘组替换磁盘的操作，由于当前存储盘的不稳定导致风险性很高，尤其在未备份的情况下，一旦出现问题就可能导致数据丢失，所以在操作前务必制定实施方案及应急方案；

2、操作过程再次证明了应急方案的重要性。由于故障盘所在的磁盘组仅存放索引数据，可以接受选择性丢失，处理起来相对简单。但如果事前没有根据应急方案给主机MAP新盘，那么在停机窗口内无法完成后续操作，必然影响正常业务；

3、如果业务磁盘组因磁盘链路不稳定发生故障，不能使用此种替换磁盘的方法。此时可以采用逻辑导出/导入的方式，移动数据到新位置等方式。

如欲了解更多，请登录十大靠谱网赌软件官方网站:be4.kindaigokin.com