Oracle10g引入ASM以来,关于ASM的担心就从来没有停止过.因为ASM引入了一个新的ASM Instance,新的实例的稳定性一度成为了关注的焦点.
我们看一下这个新的ASM实例引入的后台进程:
[oracle@danaly bdump]$ ps -ef|grep ASM|grep -v grep
oracle 3720 1 0 14:38 ? 00:00:00 asm_pmon_+ASM
oracle 3722 1 0 14:38 ? 00:00:00 asm_psp0_+ASM
oracle 3724 1 0 14:38 ? 00:00:00 asm_mman_+ASM
oracle 3726 1 0 14:38 ? 00:00:00 asm_dbw0_+ASM
oracle 3728 1 0 14:38 ? 00:00:00 asm_lgwr_+ASM
oracle 3730 1 0 14:38 ? 00:00:00 asm_ckpt_+ASM
oracle 3732 1 0 14:38 ? 00:00:00 asm_smon_+ASM
oracle 3734 1 0 14:38 ? 00:00:00 asm_rbal_+ASM
oracle 3736 1 0 14:38 ? 00:00:00 asm_gmon_+ASM
oracle 3748 1 0 14:38 ? 00:00:00 asm_o000_+ASM
oracle 3781 1 0 14:38 ? 00:00:00 oracle+ASM (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
|
这些进程和数据库的后台进程同样重要(甚至可以说更为重要),如果ASM实例Crash,数据库将会立刻中止.
今天这个10g的数据库就遇到了这样的问题.第一次，Oracle10gR2的ASM挂了。
检查数据库的alert文件，获得如下信息:
Thu Jan 19 13:34:11 2006
WARNING: inbound connection timed out (ORA-3136)
Thu Jan 19 13:52:47 2006
Errors in file /opt/oracle/admin/danaly/bdump/danaly_asmb_4154.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Thu Jan 19 13:52:47 2006
ASMB: terminating instance due to error 15064
Instance terminated by ASMB, pid = 4154
|
