国产化推进过程中，项目上需要不断的对库进行拆分，我们使用的办法就是通过adg来进行拆分原有的数据库，说来也是比较奇怪，我们每次拆库都需要搭建八九套adg环境，但是每次出现adg坏块的都是应急4环境，这个问题也困扰了好久，或者也可以说是没有具体的深入分析过这个问题，这个问题最终还是拉着主机工程师发现的，最近碰见了好多这种存储层面的问题，身为数据库管理员的我，在分析此类问题，确是存在不少的问题，想的不够周全。
从alert日志后台进程来看，发现数据库不断的产生坏块，并且数据库不断的进行自动修复的动作，但是数据库中仍然存在一些坏块数据库无法做修复，通过recover操作也是无效的，真的这个不断产生坏块的动作，当时理解可能就是写的时候出现的，所以第一时间就联系了存储工程师，来进行排查解决问题，但是存储工程师排查了问题也没有相应的结论，结论就是他们的存储没有任何问题，后台日志没有任何报错，以下是相关alert日志告警信息（数据库在不断的做坏块修复）
当时针对这个坏块问题，我们做了很多修复的动作，包括从源端直接copy数据文件过来进行覆盖，数据文件覆盖后依然出现了坏块信息，而且坏块信息仅仅是针对37号文件，后续排查出问题的时候，我们发现了asm复用文件系统文件，但是仍然不知道为什么覆盖后仍是37号文件一直出错。
与存储工程师沟通问题，存储那边已经反馈存储绝对没有问题的情况下，问题排查的方向就到了Oracle软件层面，思路也比较简单，对Oracle软件进行relink操作，关闭数据库后，对两个节点操作如下：
cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk rac_on make -f ins_rdbms.mk ioracle
节点1在操作后正常数据库开启，但是节点2出现了问题，数据库无法正常open，这里的提示也很明显，文件系统出现了问题，具体的原因就是无法在/oracle_log目录中写审计日志文件。导致数据库无法正常开启。
尝试对文件系统进行修复动作，提示如下信息，修复的动作实际上是有问题的，主机工程师提示需要先dismount之后才能对磁盘进行修复，但是已经不重要了，现在已经好像是发现了问题原因，文件系统发生了损坏！！！那么问题也比较简单了，直接找主机测再次进行排查既可。
针对报错，在mos上搜索的相关信息，也是提示文件系统出现了问题，需要主机工程师进行配合
到这里就到了真正发现问题的地方了，主机工程师查看到我们之前搭建adg环境的时候，将系统存储盘添加到了asm磁盘组中，如下信息：disk117-120磁盘被asm复用了，这也就能解释为什么adg后台为什么一直产生坏块了，这个折磨了好几个月的问题也就解决掉了、。
