ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []
error 488 detected in background process
ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []
kjzduptcctx: Notifying DIAG for crash event
----- Abridged Call Stack Trace -----
ksedsts()+465<-kjzdssdmp()+267<-kjzduptcctx()+232<-kjzdicrshnfy()+63<-ksuitm()+5594<-ksbrdp()+3507<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201<-__libc_start_main()+253?
----- End of Abridged Call Stack Trace -----
*** 2015-05-25 16:09:32.865
RBAL (ospid: 4147): terminating the instance due to error 488
ksuitm: waiting up to [5] seconds before killing DIAG(4129)
终止进程操作，查看alert log的进一步详细信息。
Errors in file /u02/app/oracle/diag/rdbms/sicsstb/sicsstb/trace/sicsstb_rbal_4147.trc? (incident=9721):
ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u02/app/oracle/diag/rdbms/sicsstb/sicsstb/incident/incdir_9721/sicsstb_rbal_4147_i9721.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u02/app/oracle/diag/rdbms/sicsstb/sicsstb/trace/sicsstb_rbal_4147.trc:
ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []
RBAL (ospid: 4147): terminating the instance due to error 488
System state dump requested by (instance=1, osid=4147 (RBAL)), summary=[abnormal instance termination].
System State dumped to trace file /u02/app/oracle/diag/rdbms/sicsstb/sicsstb/trace/sicsstb_diag_4129_20150525160933.trc
Dumping diagnostic data in directory=[cdmp_20150525160933], requested by (instance=1, osid=4147 (RBAL)), summary=[abnormal instance termination].
Instance terminated by RBAL, pid = 4147
Mon May 25 16:09:40 2015
Adjusting the default value of parameter parallel_max_servers
from 160 to 120 due to the value of parameter processes (150)
提示信息中出现了ora-600错误，并且在最后有一个半提示半建议的信息，要求提升参数parallel_max_servers的数量参数。GI和ASM要伴随着多个并行工作进程，笔者猜测一种可能是不是进程数量过多，参数设置较小而引起的故障。
尝试将参数进行调整。
SQL> show parameter parallel_max_servers
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? VALUE
------------------------------------ ----------- ------------------------------
parallel_max_servers? ? ? ? ? ? ? ? integer? ? 120
SQL> alter system set parallel_max_servers=150 scope=both;
System altered.
SQL> show parameter parallel_max
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? VALUE
------------------------------------ ----------- ------------------------------
parallel_max_servers? ? ? ? ? ? ? ? integer? ? 150
在MOS上，笔者也进行了检查，Oracle一些文章认为是权限问题。但是似乎没有过多问题。
[oracle@NCR-Standby-Asm ~]$ cd $ORACLE_HOME/bin
[oracle@NCR-Standby-Asm bin]$ ls -l grep oracle
ls: cannot access grep: No such file or directory
-rwsr-s--x 1 oracle asmadmin 239882127 May 25 17:06 oracle
之后，重启Database，服务正常。
SQL> startup
ORACLE instance started.
Total System Global Area 2087780352 bytes
Fixed Size? ? ? ? ? ? ? ? ? 2254824 bytes
Variable Size? ? ? ? ? ? 553650200 bytes
Database Buffers? ? ? ? 1526726656 bytes
Redo Buffers? ? ? ? ? ? ? ? 5148672 bytes
Database mounted.
Database opened.
故障解决。
3、结论
老实说，笔者对这个故障的解决还是有一些不明白的地方。从直观看，在进行补丁操作之后，Oracle实例对进程数目要求是增加的，所以需要进行一些调整。