1、ASM磁盘无法mount如何处理？
原因一：磁盘权限不正确
如果磁盘组所用的磁盘的宿主不是oracle用户，那么会导致磁盘组不能被MOUNT。
【处理方法】
修改好磁盘的权限，然后关闭有问题的节点上的ASM实例，再重新启动它。
【注意事项】
这样的情况下，磁盘上的数据不受影响。
原因二：磁盘头信息被破坏
如果磁盘头信息被损坏，则磁盘组也不能被MOUNT。
【检查方法】
执行以下命令，如果返回的结果只有15行以内，那么肯定是错误的。
kfedread /磁盘路径及名称
【处理方法】
找到磁盘头信息的备份文件，对它进行恢复。如果是通过dd命令备份的，那么恢复命令如下:
ddif=/备份文件的路径及名称 bs=4096 count=1 of=/要恢复的磁盘路径及名称
如果是通过kfed备份的，那么恢复命令如下:
kfedmerge/要恢复的磁盘路径及名称text=/备份文件的路径及名称
做完恢复后，重新启动ASM实例。
【注意事项】
如果仅仅是磁盘头信息被破坏，那么恢复后，原来磁盘组上的数据是不受影响的。
原因三：磁盘被生成了PV信息
目前，一个磁盘被ASM使用后，如果执行生成PV的命令，则此磁盘的ASM信息被清除并可成功生成PV信息，此时ASM将无法识别它。
【检查方法】
执行以下命令将头信息导出，并用vi打开导出文件，如果文件内容中有乱码，并看到字符串PV或一串数字与字母组成的字符，则很可能是此盘被生成了PV。
ddif=/磁盘路径及名称 of=/导出文件的目标路径及名称bs=4096 count=2
【处理方法】
核实为何要用此磁盘做PV，如果可以，将PV等信息删除，然后启动ASM实例，重新将此磁盘加入到磁盘组中，或者重新创建磁盘组。
【注意事项】
这样的情况下，如果原来磁盘组中有两个以上的磁盘，那么数据不会有丢失。但是如果磁盘组中只有这一个磁盘，则原来磁盘组上的内容都被清除了，必须通过RMAN做恢复。
2、ASM metadata信息包含哪些？ASM的磁盘头备份在哪里？
一个ASM DISK的最前面4096字节为disk header，对于ASM而言是block 0 (blkn=0)。ASM disk header描述了该ASM disk和diskgroup的属性，通过对现有disk header的加载，ASM实例可以知道这个diskgroup的整体信息。所以对那些会影响ASM disk header的操作要慎之又慎，同时最好定期备份disk header。
物理元数据存储在磁盘的固定位置，通常在ASM磁盘头，物理元数据用于描述磁盘组的组成、空间分配等内容。而虚拟元数据则用于记录ASM文件在磁盘上的分布，虚拟元数据也存在于ASM文件当中，和其他ASM文件的分布和管理完全相同。
(第2个AU的倒数第2个BLOCK)，
第2个AU的倒数第一个块是什么?
从第1个块开始记录文件asm file number为1的磁盘分布信息 而第2个块开始记录asm file number为2的磁盘分布信息。以此类推，刚好从asm file number从1-255都保存在2号AU上面。所以File#1至少包含了2个AU，因为我们的数据库文件的file number是从256开始的。
3、ASM的alias在什么地方？
ASM序号6的元数据文件中可以通过查询v$asm_alias视图来获得ASM别名信息。
4、AMDU抽数据文件后如何找和datafile 映射的问题
“amdu -diskstring ‘/dev/磁盘路径’ -extract ‘ASM磁盘组名称.数字编号’”
备注：
如果不使用ODU工具，可以通过抽取的控制文件，再获取数据文件各个目录，最主要的是获取数据文件在asm中的内部编号。
5、数据库进程CPU高如何分析？(比如10s)
一、定位问题
A.通过PID与vprocess、vsession两张视图快速定位出语句的sql_id，如下：
SQL> select sql_id from v$session where paddr= (select addr from v$process where spid ='14468');复制
B、通过sql_id查看具体sql
select sql_text from v$sql where sql_id='gmkaj9nz7vyvw';复制
二、分析问题
A、通过oracle工具脚本awrsqrpt.sql分析具体sql
B、通过dbms_xplan.display_awr与sql_id查看语句详情
select * from table(dbms_xplan.display_awr(‘gmkaj9nz7vyvw’));
C、通过sql语句直接分析
explain plan for select * from scott.t3 where name=dbms_random.string(‘u’, 10);
select * from table(dbms_xplan.display());
6、数据库的坏块如何处理？
常用的处理方法有：
Ø 恢复数据文件
Ø 只恢复坏的block（9i以上版本可用）
Ø 通过ROWID RANGE SCAN保存数据
Ø 使用DBMS_REPAIR
Ø 使用EVENT
使用RMAN的BLOCKRECOVER命令 ：
Rman>run{blockrecover datafile 5 block 11,16;}复制
也可以强制使用某个SCN号之前的备份，恢复数据块。
Rman>run{blockrecover datafile 5 block 11,16 restore until sequence 8505;}复制
用dbms_repair包进行恢复
使用dbms_repair标记有坏块的表，在做全表扫描的时候跳过坏块，执行以下的语句：
Execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('<schema>','<tablename>');复制
然后使用exp工具或者createtable as select的方法取出没有坏块数据，然后重建表，表上的索引和限制
7、crs无法启动，有哪些原因以及如何确认？
依次检查集群状态，检查集群软件目录权限，查看日志信息进行递归检查
- $GRID_HOME/bin/crsctl check crs
- $GRID_HOME/bin/crsctl stat res -t -init
- $GRID_HOME/bin/crsctl stat res -t
- ps -ef | egrep ‘init|d.bin’
8、心跳能ping通，但是crs报无心跳如何处理？
可能遇到bug了。 因为负责管理集群cluster interconnect的gipcd.bin进程是个非核心进程，对与这些非核心进程可以直接kill掉，集群会自动重启。 现在本身也只有一个节点在运行，kill 该进程不会有负面影响。
在节点1的OS上直接kill 进程：
ps -ef|grep gipcd.bin
然后kill。
之后节点2的crs立马恢复正常启动.
