华南某电商企业出现ASM diskgroup损坏情况，直接导致生产核心EBS数据库无法使用。 诗檀软件工程师在分析了其具体ASM DISKGROUP的受损情况后，手动Patch了对应的ASM DISK后，成功将ASM Diskgroup MOUNT起来，将用户的宕机时间减到了最少。

恢复场景7   ASM下数据库无法打开

D公司的某套核心CRM库由于加入到ASM Diskgroup中的少量磁盘存在I/O问题，导致SYSTEM表空间的DBF数据文件发生讹误，导致数据库无法打开。

此时即可以通过PRM恢复软件从ASM Diskgroup中将DATAFILE全部克隆到文件系统上，如恢复场景6中所述，并进一步修复数据库。

也可以通过PRM的《Dictionary Mode(ASM)》即基于ASM的字典模式来直接恢复问题数据库。其简要步骤如下：

1. Recovery Wizard
2. Dictionary Mode(ASM)
3. 加入必要的ASM DISK(你所要恢复数据库的所在的ASM Disk Group的所有ASM DISK)
4. 点击ASM analyze
5. 为后面的数据文件选择合适的Endian
6. 在ASM analze给出的数据文件列表中选中需要的数据文件，如果嫌麻烦且只有一套库，那么可以勾选”Select all”
7. 点击load按钮，后续的恢复与《场景3》中类似

Oracle ASM Diskgroup数据恢复终极方案PRM-DUL工具

下载最新版PRM:
https://zcdn.parnassusdata.com/DUL5108.zip

PRM用户手册：

http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

ORACLE的ASM自动存储管理技术正被越来越多的企业采用，数据库采用ASM存储对比传统文件系统具有高性能、支持集群、管理方便等优势。 但ASM的问题在于，对于普通用户而言ASM的存储结构过于黑盒了，一旦ASM中的某个Disk Group的内部数据结构发生了损坏导致Disk Group无法被成功MOUNT，也就意味着用户重要的数据被锁死在这个ASM的黑盒中了。在这种场景中往往需要熟悉ASM内部数据结构的ORACLE原厂的资深工程师到达用户现场后通过手动修复ASM内部结构；而购买ORACLE原厂的现场服务对普通用户而言显得即昂贵又耗时。

基于PRM的研发人员(前ORACLE公司资深工程师)对ORACLE ASM内部数据结构的深入理解，PRM中加入了特别针对ASM的数据恢复功能。

PRM目前支持的ASM数据恢复功能包括：

1. 即便Disk Group无法正常MOUNT，仍可以通过PRM直接读取ASM磁盘上的可用的元数据metadata，并基于这些元数据将Disk Group中的ASM文件拷贝出来

2. 即便Disk Group无法正常MOUNT，仍可以通过PRM直接读取ASM上的数据文件，并抽取其中的数据，支持传统抽取方式和数据搭桥方式。

PRM对ASM的支持

社区版中ASM clone功能无任何限制，今后社区版将加入更多免费新特性

恢复场景6 从被损坏的ASM Diskgroup中拷贝出数据库数据文件

D公司开始采用ASM方案来替代文件系统和裸设备，但是由于使用的11.2.0.1版本ASM上Bug较多导致ASM DISKGROUP磁盘组无法加载MOUNT，通过多方修复ASM Disk Header无果。

此场景可以使用PRM的ASM Files Clone文件克隆功能从受损的ASM Diskgroup中拷贝出数据库数据文件。

1. 打开主界面，菜单栏Tools选择ASM File(s) Clone:

1. 进入ASM Disks界面，点击SELECT…按钮加入仍可用的ASM Disks，如/dev/asm-disk5(linux);确保加入所有可用LUN后，点击ASM analyze按钮

2. ASM Files Clone将分析指定的ASM Disk的磁盘头，以便找出对应Disk group磁盘组中的文件，以及这些文件的分布位置(File Extent Map)； 这些信息均将记录到Derby数据库中以便今后使用； 可以说PRM将ASM的所有Metadata元数据均收集、分析、并存储起来，并通过各种形式来完善PRM的基本功能，并以图形化地方式展现给用户。

3. ASM Analyze分析完成后，PRM将列出找到的ASM上文件的列表，用户可以勾选那些文件需要被克隆，并指定文件克隆的目标文件夹。

之后点击ASM Clone按钮，进入文件克隆阶段。

文件克隆阶段中，将列出ASM File的克隆进度，克隆完成后点击OK。

克隆阶段的进度日志输出如下：

4. 可以通过dbv或者rman validate命令来验证克隆出来的数据文件，例如：

对于使用ASMLIB的ASM环境要如何使用PRM呢？

其实也很简单，asmlib相关的ASM DISK在OS操作系统上会以ll /dev/oracleasm/disks 的形式存放，例如：直接将/dev/oracleasm/disks下的文件加入到PRM ASM DISK中即可

直接将/dev/oracleasm/disks下的文件加入到PRM ASM DISK中即可。

某用户ASM实例遇到ORA-00600 [kfdAuDealloc2]错误，详细日志如下：

Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb6_15539.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [35], [272], [748], [], [], [], [], [], [], [], []
NOTE: stopping process ARB6
ERROR: ORA-600 thrown in ARB2 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb2_15523.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [148], [270], [720], [], [], [], [], [], [], [], []
NOTE: stopping process ARB2
ERROR: ORA-600 thrown in ARB3 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb3_15527.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [196], [271], [0], [], [], [], [], [], [], [], []
NOTE: stopping process ARB3
ERROR: ORA-600 thrown in ARB5 for group number 1
Errors in file /opt/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_arb5_15535.trc:
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [363], [272], [1], [], [], [], [], [], [], [], []
NOTE: stopping process ARB5


Errors in file /u02/oracle/ASM/diag/asm/+asm/+ASM/trace/+ASM_rbal_27162.trc (incident=674120):
ORA-00600: internal error code, arguments: [kfdAuDealloc2], [101], [335], [300], [], [], [], [], [], [], [], []
Incident details in: /u02/oracle/ASM/diag/asm/+asm/+ASM/incident/incdir_674120/+ASM_rbal_27162_i674120.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ERROR: An unrecoverable error has been identified in ASM metadata. The instance will be taken down.
Sun Nov 25 20:51:11 2012
NOTE: AMDU dump of disk group DWHCTL1 created at /u02/oracle/ASM/diag/asm/+asm/+ASM/incident/incdir_674120
NOTE: starting check of diskgroup DWHCTL1
ERROR: file +dwhctl1.330.797592669: F330 PX11 => D0 A7650 => F385 PX135: fnum mismatch
ERROR: file +dwhctl1.330.797592669: F330 PX12 => D0 A7651 => F385 PX136: fnum mismatch

kfdAuDealloc2意味着Kernel Files Disk AU DEALLOCate ，其负责回收ASM DISK上的AU 。发生该错误一般说明 ASM metadata中的allocation table可能存在逻辑上的数据不一致。

相关bug :

Bug 5682184 OERI[kfdAuDealloc2] from resize/drop more than 16TB ASM file

Bug 10621169 I/O errors during RAC ASM recovery may drop redo and cause metadata corruptions / ORA-600

BUG 10017130 – ORA-600 [KFDAUDEALLOC2] DURING REBALANCE AFTER ADDING DISKS

出现该问题情况下可能需要手动patch asm metadata，建议联系Oracle Support原厂 或诗檀软件  13764045638。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

More about _asm_repairquantum

参数_asm_repairquantum的值调大。让rebalance有足够的时间 结束。对于10g 的版本我们可以调高参数_asm_droptimeout 来拉长drop的间隔， 对于11g的版本，这个参数被重命名为_asm_repairquantum。

【Oracle ASM数据恢复】ORA-00600 [KFRVALACD30]错误解析，某用户遇到ORA-00600 [kfrValAcd30]错误 且导致无法打开ASM实例，之前用户有断电重启过操作系统。

该错误的stack call如下：

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

STACK TRACE:
————
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
<- ksfdmp <- dbgexPhaseII <- dbgexProcessError <- dbgeExecuteForError
<- dbgePostErrorKGE
<- 1615 <- dbkePostKGE_kgsf <- kgeadse <- kgerinv_internal <-
kgerinv
<- kgeasnmierr <- kfrValAcd <- kfrgnr <- kfrgnc <- kfrPass1
<- kfrcrv <- kfcMountPriv <- kfcMount <- kfgInitCache <-
kfgFinalizeMount
<- 2149 <- kfgscFinalize <- kfgForEachKfgsc <- kfgsoFinalize <-
kfgFinalize
<- kfxdrvMount <- kfxdrvEntry <- opiexe <- opiosq0 <- kpooprx
<- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino
<- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main <- libc_start_main <- start

kfrValAcd Reap the current log read I/O.

该错误的原因是当recovery diskgroup时，发现ACD记录的seq=111，而实际ACD记录的seq=6

针对该问题 我们可以通过 PRM工具来抽取该问题diskgroup中的数据文件，并重建Diskgroup。

关于PRM FOR ORACLE 详见 http://parnassusdata.com/

• 1st， 触发该意外报错的Oracle内核函数的名字以及其在代码中的行数
• 2nd， 验证发现问题的区域名字
• 3rd ， 存放在该块中的ASM对象号      http://www.parnassusdata.com/
• 4th，存放在该块中的ASM的块号
• 5th， 2nd指定的区域中实际存放的值
• 6th,   2nd指定的区域中应当存放的值         诗檀软件专业修复Oracle数据库

例如：

• 验证发现问题的区域名字

• 存放在ASM Block中的ASM对象号object_number

• 存放在ASM block中的块号 block number

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

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

• 建议收集的数据

具体引起ORA-00600 [KFCEMA02]的场景是存在bug  6163771的版本上，可能当ASM实例崩溃后，mount一个diskgroup失败且报错为ORA-00600 [KFCEMA02]。

虽然ORACLE在多个平台上均提供了补丁bug  6163771，但由于这个补丁仅仅是预防出现该故障，而不能实际修复该故障。由于该故障的特殊性，其需要特殊的内部工具FACP才能具体修复，该工具负责修复ASM checkpoint信息，该工具的功能就是修复ASM Diskgroup上的特性metadata源数据。

ORA-00600: internal error code, arguments: [kfcema02], [0], [165057275], [], [], [], [], [], [], [], [], []

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

首先注意我们是不推荐用asmlib的，为什么请见Why ASMLIB and why not?

但如果真的遇到了使用asmlib的场景且用户误操作oracleasm deletedisk删除了ASM Disk上的 asmlib标签的话，可以通过下面的步骤来恢复：