exadata四节点RAC，其中一个节点宕机

wanglixue2012

//各位专家一起帮忙会诊一下这个数据库宕机问题

1、时间(在 2012-06-23 10:15:29.818，其中一个节点RAC宕机)


alert日志
见附件

trace日志
见附件


2、简单日志分析，日志非常简单，几乎没有什么错误日志


Sat Jun 23 10:21:43 2012
Process W003 died, see its trace file
Sat Jun 23 10:21:45 2012
Process PW61 died, see its trace file
Sat Jun 23 10:22:03 2012
Process m000 died, see its trace file
Sat Jun 23 10:24:41 2012
Process W002 died, see its trace file
Sat Jun 23 10:31:45 2012
Process PW62 died, see its trace file
Sat Jun 23 10:31:47 2012
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /u01/app/oracle/diag/rdbms/aaadb/aaadb4/trace/aaadb4_cjq0_32727.trc:

3、查询系统的相关信息


SQL> show parameter process;
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ------------------------------
aq_tm_processes                      integer                          0
cell_offload_processing              boolean                          TRUE
db_writer_processes                  integer                          2
gcs_server_processes                 integer                          2
global_txn_processes                 integer                          1
job_queue_processes                  integer                          1000
log_archive_max_processes            integer                          4
processes                            integer                          1500
SQL> show parameter sga;
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ------------------------------
lock_sga                             boolean                          FALSE
pre_page_sga                         boolean                          FALSE
sga_max_size                         big integer                      51712M
sga_target                           big integer                      0

Maclean Liu(刘相兵

ODM FINDING:

相关的案例

Hdr: 13935502 11.2.0.3 RDBMS 11.2.0.3 JOB QUEUE PRODID-5 PORTID-226
Abstract: 11.2.0.3 RAC INSTANCE DIES ON W000 PROCESS DYING ERROR

Hdr: 13538182 11.2.0.2 RDBMS 11.2.0.2 SCHEDULER PRODID-5 PORTID-226 ORA-4030 13855490
Abstract: THE MEMORY SIZE OF CJQ PROCESS HAS BEEN GROWTH CONTINUOUSLY.  




advice

建议你首先做2个DUMP 收集现场信息

oradebug setmypid;
oradebug unlimit;
oradebug dump systemstate 266;
oradebug tracefile_name

ps -ef | grep cjq0

oradebug setospid  $上一步查到的OSID
oradebug dump errorstack 4;
oradebug tracefile_name

把上面生成的2个TRACE 文件上传SR   或者 本论坛 我会帮忙看一下



紧急措施

生成以上TRACE后 可以尝试以下手段 先尝试能否解决问题

找出 LOCAL=NO 的Server Process 并KILL掉 继续观察 OS memory 和alert.log

ps -ef | grep LOCAL=NO |grep -v grep| awk '{print $2}' | xargs kill -9

wanglixue2012

中午的时候就恢复了
我发现的时候已经宕机了。让后我尝试重启，发现内存不够用了。
MEMORY_TARGET设置成51712M了。实际/dev/shm已经不到43G了。

所以我尝试使用以下方法释放内存
1、shutdown abort
2、使用类似你提供的方式
找出 LOCAL=NO 的Server Process 并KILL掉 继续观察 OS memory 和alert.log

ps -ef | grep LOCAL=NO |grep -v grep| awk '{print $2}' | xargs kill -9

然后集群自动将数据库拉起了。

Maclean Liu(刘相兵

1. /dev/shm=> 只有11g AMM会运用到/dev/shm文件系统 ， 10g的ASMM 采用shared memory segment

2.  没有  systemstate dump 、errorstack dump的话 提交SR ， GCS的工程师一般不会给非常明确的solution