个人简介
偶尔有空上来看看
文章分类
文章存档
最近访客
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2022-02-18 22:58:46
linux 5.8 oracle 11.2.0.4 rac
两种存储组成的asm磁盘组，配置了normal冗余，结果就偏偏一个存储故障了，丢失一个ocrdg中的磁盘和两个datadg中磁盘，crs没宕机，数据库稳稳的运行着。。。
查看asm磁盘，是这样子滴
select name,path,total_mb from v$asm_disk;
输出信息中name列为空的 sdb sdc sdd sde，大小为0，就是出现故障的磁盘，这里还有个奇怪的_dropped_0000_开头的磁盘组名称（修复后会自动消失 dont warry about it）。
3天后存储故障修复，还要恢复数据库原样
这些设备是如何配置的呢？
经验上应该是看/etc/udev/rules.d/99-oraclexxx.rules这样的文件
但是没有
5年前的环境，采用磁盘管理方式比较“旧”
看/etc/rc.local
然后看multipath -ll
看来是ibm磁盘用多路径软件管理，这得看一下配置文件 /etc/multipath.conf
大概知道哪些盘，怎么用了。
再确认一下属主
ls -l /dev/sd*
ls -l /dev/mapper/*
执行ocrcheck 和 crsctl query css votedisk 检查健康状态和投票盘名称
由于crsdg是3个2g的磁盘采用normal冗余方式创建，因此直接加回即可，但是哪些盘是原先的呢？
看大小，fdisk -l |grep /dev 可能比较粗糙，lsblk这个命令没有
精致的方法 kfed read /dev/sde |grep name
dskname就是这个盘属于哪个asm磁盘组，这下就放心添加了。
先看看asm磁盘组当前状态
select name,state from v$asm_diskgroup;
如果没有mount，要先挂载
alter diskgroup fra mount;
alter diskgroup crsdg add disk '/dev/sdf' force;
因为磁盘上面有过信息，因此要用force
添加回原先的磁盘组后，会自动rebalance，可以检查 v$asm_operation 看进度
检查 alert_ asm1.log 看是否还有异常，检查arb进程的日志可以看是否完全结束。
由于磁盘比较大，rebalance时间比较长，经验上讲 ssd设备 1小时4t，普通硬盘1小时400g
为了加速可以增加并行度（即使已经开始rebalance）
alter diskgroup datadg rebalance power 11;
rebalance分为三个阶段：
第一阶段planning:
计算出rebalance的计划，会根据磁盘大小个数，磁盘吞吐，au大小等计算出大致计划
这个时间一般只需几分钟。
第二阶段extent relocating：
真正进行重平衡的过程，将extent均匀的分配在各个磁盘中。该过程通常是整个rebalance最耗时的过程
这个时间大致可参考 v$asm_operation 的 est_minutes字段。
第三阶段compacting:
asm11.1.0.7以上才开始支持，将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去（机械盘的外圈速度更快），花费时间较少。是 disk 级别，不是整个 diskgroup 级别，可以通过参数_disable_rebalance_compact来进行控制，当rebalance进行到这个步骤时,查询v$asm_operation.est_minutes会显示为0 但rebalance 操作却很长时间没结束。
这个时间如何评估？
如果每磁盘组中的盘大小一致 ，粗略的算法是：
（新盘大小 - 现有磁盘free_mb大小）/ 每秒变化量
当前参数：
新盘大小 614400，现有磁盘剩余大小103717
记录/dev/sdc 磁盘free_mb 值547653，过10秒钟再记录一次值546553，这个值是不断减小的
简单算法：
(614400-103717) / (547653-546553)/10 /60/60= 510683/110/3600 = 1.3 小时
因此得知：
这块将近500g的空间执行compact，大概还需要1.3小时。
可以安排好时间去吃点东西了。
两种存储组成的asm磁盘组，配置了normal冗余，结果就偏偏一个存储故障了，丢失一个ocrdg中的磁盘和两个datadg中磁盘，crs没宕机，数据库稳稳的运行着。。。
查看asm磁盘，是这样子滴
select name,path,total_mb from v$asm_disk;
输出信息中name列为空的 sdb sdc sdd sde，大小为0，就是出现故障的磁盘，这里还有个奇怪的_dropped_0000_开头的磁盘组名称（修复后会自动消失 dont warry about it）。
3天后存储故障修复，还要恢复数据库原样
这些设备是如何配置的呢？
经验上应该是看/etc/udev/rules.d/99-oraclexxx.rules这样的文件
但是没有
5年前的环境，采用磁盘管理方式比较“旧”
看/etc/rc.local
然后看multipath -ll
看来是ibm磁盘用多路径软件管理，这得看一下配置文件 /etc/multipath.conf
大概知道哪些盘，怎么用了。
再确认一下属主
ls -l /dev/sd*
ls -l /dev/mapper/*
执行ocrcheck 和 crsctl query css votedisk 检查健康状态和投票盘名称
由于crsdg是3个2g的磁盘采用normal冗余方式创建，因此直接加回即可，但是哪些盘是原先的呢？
看大小，fdisk -l |grep /dev 可能比较粗糙，lsblk这个命令没有
精致的方法 kfed read /dev/sde |grep name
dskname就是这个盘属于哪个asm磁盘组，这下就放心添加了。
先看看asm磁盘组当前状态
select name,state from v$asm_diskgroup;
如果没有mount，要先挂载
alter diskgroup fra mount;
alter diskgroup crsdg add disk '/dev/sdf' force;
因为磁盘上面有过信息，因此要用force
添加回原先的磁盘组后，会自动rebalance，可以检查 v$asm_operation 看进度
检查 alert_ asm1.log 看是否还有异常，检查arb进程的日志可以看是否完全结束。
由于磁盘比较大，rebalance时间比较长，经验上讲 ssd设备 1小时4t，普通硬盘1小时400g
为了加速可以增加并行度（即使已经开始rebalance）
alter diskgroup datadg rebalance power 11;
rebalance分为三个阶段：
第一阶段planning:
计算出rebalance的计划，会根据磁盘大小个数，磁盘吞吐，au大小等计算出大致计划
这个时间一般只需几分钟。
第二阶段extent relocating：
真正进行重平衡的过程，将extent均匀的分配在各个磁盘中。该过程通常是整个rebalance最耗时的过程
这个时间大致可参考 v$asm_operation 的 est_minutes字段。
第三阶段compacting:
asm11.1.0.7以上才开始支持，将磁盘上存的数据尽可能的移动到磁盘的外圈磁道上去（机械盘的外圈速度更快），花费时间较少。是 disk 级别，不是整个 diskgroup 级别，可以通过参数_disable_rebalance_compact来进行控制，当rebalance进行到这个步骤时,查询v$asm_operation.est_minutes会显示为0 但rebalance 操作却很长时间没结束。
这个时间如何评估？
如果每磁盘组中的盘大小一致 ，粗略的算法是：
（新盘大小 - 现有磁盘free_mb大小）/ 每秒变化量
当前参数：
新盘大小 614400，现有磁盘剩余大小103717
记录/dev/sdc 磁盘free_mb 值547653，过10秒钟再记录一次值546553，这个值是不断减小的
简单算法：
(614400-103717) / (547653-546553)/10 /60/60= 510683/110/3600 = 1.3 小时
因此得知：
这块将近500g的空间执行compact，大概还需要1.3小时。
可以安排好时间去吃点东西了。
给主人留下些什么吧！~~