前一阵碰到了一个ASM相关的bug，今天又碰到了一次。

连接ASM实例后出现ORA-1012错误：http://yangtingkun.itpub.net/post/468/280923

问题的现象和上次比较基本一致，只是这次发生故障的节点和上次不一样。

之所以要续写这篇文章，是因为基本上确定了这次产生这个问题的原因。发现问题的时候，状况和上次基本上完全一样。先是归档到ASM上报错，我开始认为是ASM空间已经不足，打算用DBCA登陆检查一下ASM的使用情况，结果报错信息和上面完全一样。从后台ASM的alert文件中，也找到了大量的告警信息：WARNING: allocation failure on disk DISK_0000 for file 384 xnum 34

根据上次的经验，我登陆了ASM实例，结果意外的发现了另一个错误：

ORA-00020: 超出最大进程数 (%s)

这个错误是上次没有发现的，莫非进程数已经超过了数据库的限制。

$ ps -ef|grep ASM|grep -v grep|wc -l
40

检查ASM实例启动日志，发现PROCESSES参数是默认值启动的。

没想到过了一段时间，发现居然可以正常的登陆ASM实例，并运行SQL语句，查询PROCESSES初始化参数，发现数据库设置果然是40：

SQL> show parameter processes

NAME TYPE VALUE
------------------------------------ ---------------------- -----------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 1
job_queue_processes integer 0
log_archive_max_processes integer 2
processes integer 40

当可以登陆ASM实例时，检查后台ASM启动的进程数，发现已经减少到40以下：

$ ps -ef|grep ASM|grep -v grep|wc -l
39

从上面的现象至少可以断定，本次出现的问题是由于进程数超过初始化参数的设置导致的。

可以在ASM实例的启动初始化参数中给processes参数设置一个较大的值。避免这种情况的产生。