客户CRM历史数据库添加磁盘问题说明

作者简介:高文博,OCM,从事ORACLE专业15年,主要服务于各大升级运营商。现任职北京海天起点技术服务股份有限公司山东办事处主任,为山东省内企事业客户提供海量级ORACLE数据库及相关产品的运维支持,参与出版《Oracle云管理平台——企业管理器12c实战指南》一书。

故障背景:

2019年1月31日 春节假期前根据业务组要求扩充各数据库表空间,其中CRM历史数据库需扩1.5T,但ASM磁盘组只剩余400G,经沟通,准备将CRM历史主机上的4块500G磁盘,添加到磁盘组中。4块磁盘为

/dev/sdx  /dev/sdy  /dev/sdaa  /dev/sdab

其中sdaa和sdab已经使用udev绑定为asm磁盘,sdx和sdy没有绑定。因此当天工作为将/dev/sdx和/dev/sdy绑定为asm磁盘,然后将4块新asm磁盘asm-disk021-024加入到DATA磁盘组中,完成扩容计划。该工作于1月31日晚22:19分完成,并开启power 11的rebalance。

故障描述:

2019年1月31日 23:12:08 在rebalance过程中,数据库开始出现报错:

此时DATA磁盘组已被DISMOUNT,数据库宕机。

故障分析:

根据数据库警告日志的报错,可判断是在rebalance过程中,突然发现DISK
DATA_00022中asm metadata被损坏,DATA_00022是磁盘/dev/asm-disk023,对应物理磁盘为/dev/sdx,也就是当时存疑的两块盘之一。

根据报错信息ORA-15196的一般格式是:

各部分含义为:

[1st]该报错的Oracle内核函数及其在代码中的行数

[2nd]问题区域名称

[3rd]ASM对象号

[4th] ASM的块号

[5th]报错区域实际存放的值

[6th]报错区域应存放的值

根据实际报错信息:

ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483670] [256] [0 != 1]

endian_kfbh :问题区域名称

存放在该块中的ASM对象号:2147483670

存放在该块中的ASM的块号:256

2nd指定的区域中实际存放的值:0

2nd指定的区域中应当存放的值:1

根据一般情况下的ORA-15196报错处理,应先尝试恢复ASM磁盘头部信息。

首先查看 /dev/asm-disk00023的头部信息:

经过查询,没发现什么问题。先尝试修复一下:

导致这个错误的原因是由于当前磁盘组的AUSIZE不是默认值1M,ASM头块备份位置为第2个AU的倒数第2个块上,默认的AUSIZE 1M,每个AU存储256个块,第2个AU的倒数第2个块为510;

从前面ASM头部信息可以查看到AU是4M,每个AU可存储1024个块,因此备份块位置为1024×2-2=2046,查看第2046个块的信息

确认该块为备份块。

因此需要使用以下命令修复:

但修复后,mount磁盘组,只要开始rebalance,磁盘组一会就又会报错和卸载,问题仍然没有解决。

现在看来,磁盘头部信息保留完整,根据报错,第256个块出现损坏,读取256块信息:

可以看到,块信息中出现/expdata。查看操作系统目录,确实存在/expdata文件系统,并且该目录已不能正常访问,由此判断,/dev/sdx和/dev/sdy本来是分配给了操作系统的/expdata目录,由于添加磁盘时,根据要求只和马工进行了简单沟通,没有二次确认,导致将分配给操作系统的磁盘加入到ASM磁盘组中,而当天晚上进行定时导出任务时,将256块内容清空。

故障处理:

由于256块已经被完全清空,而且不确定是否还有其他块有问题,因此通过kfed和bbed进行修复已经没有可行性了,经过和公司其他同事沟通,进行以下操作:

1、考虑到磁盘组头部信息是正常的(运气好),磁盘组可以正常挂载,只是在rebalance过程中写到坏块时才会触发报错,因此首先要停掉rebalance,保证磁盘组和数据库能正常mount。

停止rebalance后,磁盘组不再报错卸载,数据库也能正常打开。

2、新建磁盘组DATA01,将数据库备份到新磁盘组中,并切换备份

  • 新建磁盘组DATA01(相关命令省略)
  • 使用rman进行backup as copy

在运行rman backup as copy时,出现报错:

说明256块损坏,必然导致了部分数据文件出现坏块。经统计,共有26个数据文件出现坏块,dbv标记坏块,大部分为1-3个坏块,个别数据文件超过1000个坏块。

  • 数据库设置event在全表扫描时忽略坏块
  • 处理数据库坏块(省略具体步骤)
  • 对于索引坏块,直接删除索引。
  • 对于表和分区表坏块,通过CTAS创建新表,删除旧表。
  • 由于RMAN默认只要标记1个坏块,就不再备份该数据文件,因此需要设置maxcorrupt,来绕过该机制。

  • alter database open;
  • 检查数据库相关配置,应用连接测试。
  • 重建索引
  • 在新磁盘组上重建控制文件和在线日志文件。

至此,数据库已完全迁移到新磁盘组DATA01上,并且坏块也都进行了处理。在稳定运行一段时间后,可逐步删除原DATA磁盘组,并回收磁盘。

故障总结:

本次故障属人为故障,主要原因是在添加磁盘时,没有进行二次确认。说明在维护工作中,还存在标准化流程的缺失。针对本次故障,我们在今后进行类似扩容工作时,需定制以下标准化工作流程:

  • 接到工作需求后,登录、确认主机、数据库名称并记录
  • 检查磁盘状态、检查各操作系统vg详细信息,并进行比对。
  • 确认相关磁盘没有在操作系统中使用后,数据库中新建磁盘组DATA9
  • 在数据库正常运行至少一周,确认新磁盘组没有问题后,删除新磁盘组DATA9,并重新将磁盘加入到生产磁盘组。

未经允许不得转载:Oracle一体机用户组 » 客户CRM历史数据库添加磁盘问题说明

相关推荐