前不久某客户的ERP 库出现故障(Linux x64,10204 rac ams环境). 大概问题是由于一些列操作之后导致磁盘组无法mount， 只能进行数据恢复，针对该case，我们前后投入了8个人力，进行了3天3夜终于成功抢救该数据库。 首先是客户在rac其中一个节点add disk时，发
前不久某客户的ERP 库出现故障(Linux x64,10204 rac ams环境). 大概问题是由于一些列操作之后导致磁盘组无法mount，
只能进行数据恢复，针对该case，我们前后投入了8个人力，进行了3天3夜终于成功抢救该数据库。
首先是客户在rac其中一个节点add disk时，发现在另外节点未添加成功，后面又反复折腾add，甚至dd 盘头进行了add。
最为致命的一个动作是强制add disk，其实在该步骤之前这几个disk已经add过一次，且完成了reblance，但是drop disk
却并未成功，最后客户尝试强制添加，如下：
SQL> ALTER DISKGROUP xxxx ADD DISK
<code class="php string">'ORCL:VOL1_xxx' <code class="php plain">SIZE 2097152M FORCE ,
<code class="php string">'ORCL:VOL2_xxx'
<code class="php plain">SIZE 2097152M FORCE ,
<code class="php string">'ORCL:VOL3_xxx'
<code class="php plain">SIZE 2097152M FORCE
<code class="php plain">........
<code class="php plain">ORA-15186: ASMLIB error
<code class="php keyword">function <code class="php plain">= [asm_open], error = [1], mesg = [Operation not permitted]
<code class="php plain">Tue Feb 18 06:09:32 2014
<code class="php plain">SQL> alter diskgroup xxx MOUNT
<code class="php plain">NOTE: cache registered group xxx number=1 incarn=0x6c42d680
<code class="php plain">.......
<code class="php plain">Tue Feb 18 06:09:32 2014
<code class="php plain">NOTE: Hbeat: instance not first (grp 1)
<code class="php plain">Tue Feb 18 06:09:32 2014
<code class="php plain">NOTE: cache dismounting group 1/0x6C42D680 (xxx)
<code class="php plain">NOTE: dbwr not being msg'd to dismount
<code class="php plain">Tue Feb 18 06:09:32 2014
<code class="php plain">NOTE: PST enabling heartbeating (grp 1)
<code class="php plain">Tue Feb 18 06:09:32 2014
<code class="php plain">ERROR: diskgroup xxx was not mounted
<code class="php plain">Tue Feb 18 06:10:22 2014
<code class="php plain">ORA-15186: ASMLIB error
<code class="php keyword">function <code class="php plain">= [asm_open], error = [1], mesg = [Operation not permitted]
<code class="php plain">Tue Feb 18 06:10:22 2014
<code class="php plain">.........
<code class="php plain">最后导致磁盘组都无法mount，当然数据库肯定也无法成功open，会报如下类似的错误；
<code class="php plain">Tue Feb 18 05:53:57 2014
<code class="php plain">Errors in file /opt/oracle/admin/xxx/bdump/xxx_lmon_17095.trc:
<code class="php plain">ORA-00202: control file:
<code class="php string">'+xxx/xxx/controlfile/current.256.743166671'
<code class="php plain">ORA-15078: ASM diskgroup was forcibly dismounted
<code class="php plain">Tue Feb 18 05:53:58 2014
<code class="php plain">Errors in file /opt/oracle/admin/xxx/bdump/hxxx_lmon_17095.trc:
<code class="php plain">ORA-00204: error in reading (block 35, # blocks 1) of control file
<code class="php plain">ORA-00202: control file:
<code class="php string">'+xxx/xxx/controlfile/current.256.743166671'
<code class="php plain">ORA-15078: ASM diskgroup was forcibly dismounted
<code class="php plain">Tue Feb 18 05:53:58 2014
<code class="php plain">LMON: terminating instance due to error 204
<code class="php plain">Tue Feb 18 05:53:58 2014
<p>首先利用kfed 读取相关的disk，发现asm的相关元数据基本上都不存在了，因为前面的add disk force其实相当于是吧<br>
diskgroup 重建了一次，其中最为关键的file directory元数据没了。这是非常麻烦的一件事。</p>
<p>在恢复的过程中，我们甚至尝试了Oracle DUL，发现file directory完全丢失的情况下，dul根本无法正常工作。当然，</p>
<p>我们利用老熊的ODU成功的恢复了该库。ODU目前有这样的一个强悍功能，可以进行scan asm disk，然后将所有数据文件</p>
<p>的AU分配信息扫描出并记录到一个文件asm_fileext_meta.odu 中，然后可以自动的将AU进行拼接，也就形成了一个完整</p>
<p>的数据文件，大致的语法如下：</p>
extract asm file
1 to /xxxxx/system01.dbf
extract asm file
2 to /xxxxx/undotbs1_01.dbf
extract asm file
3 to /xxxxx/sysaux01.dbf
<p>备注:<br>
1. 第一次使用抽取文件的方式进行了恢复，由于数据字典损坏严重，导致数据库open后问题不断（其中还修复了<br>
大量的block，因为部分block是空的，空块是因为部分disk完成了reblance，部分没有，导致抽取的数据字典不完整），<br>
因此我们又重新抽取了一次数据，并重建库导入，前后花费了大量的人力，当然这也是我第一次利用ODU<br>
恢复ERP库，并完美的解决问题。 这里必须赞一个！</p>
<p>2. 关于file directory，可以参考：http://www.killdb.com/2013/01/13/oracle-asm-%e5%89%96%e6%9e%90%e7%b3%bb%e5%88%974-file-directory.html</p>
<p> </p>
