- 最后登录
- 2014-5-26
- 在线时间
- 8 小时
- 威望
- 8
- 金钱
- 48
- 注册时间
- 2012-5-30
- 阅读权限
- 10
- 帖子
- 4
- 精华
- 0
- 积分
- 8
- UID
- 466
|
1#
发表于 2012-5-31 04:30:45
|
查看: 5469 |
回复: 0
Hi
刘大,今天凌晨再次遇到这个问题,再次宕机,依然找不到原因。大刘帮帮忙吧。
我遇到一个问题,造成oracle宕机。虽然经过努力,让oracle重新启动,但是目前找不到宕机的真正原因。刘大帮我这个菜鸟分析一下真正原因吧,多谢!大量如下信息
alert:
May 30 04:32:54 2012
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file /var/u01/app/oracle/diag/rdbms/qc010/down/trace/down_cjq0_29326.trc:
trace:
*** 2012-05-30 04:32:53.689
*** 2012-05-30 04:32:54.393
Process J000 is dead (pid=8448 req_ver=1204 cur_ver=1204 state=3).
*** 2012-05-30 04:33:00.857
Process J000 is dead (pid=8524 req_ver=1205 cur_ver=1205 state=3).
*** 2012-05-30 04:33:11.862
Process J000 is dead (pid=8651 req_ver=1206 cur_ver=1206 state=3).
*** 2012-05-30 04:35:18.338
Process J000 is dead (pid=9105 req_ver=1207 cur_ver=1207 state=3).
Oracle数据库基本信息:
Version: 11.1.0.6.0
memory_target:18G
memory_max_target:18G
JOB_QUEUE_PROCESSES=1000
OS信息:
Version:CentOS release 5.6 (Final)
内存:24G
/dev/shm:20G
具体情况:
收到报警后,登录sqlplus,发现数据库已经宕机了。试着启动oracle,
SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system
MEMORY_TARGET设置的是18G,而/dev/shm设置的是20G,不应该起不来啊,查看/dev/shm具体情况
[oracle@hou-test dbs]$ df -Th /dev/shm
文件系统 类型 容量 已用 可用 已用%% 挂载点
tmpfs tmpfs 20G 13G 6.6G 67% /dev/shm
/dev/shm剩余空间不足18G。重新remount /dev/shm后,oracle顺利启动。
这就是我的第一个问题:oracle数据库宕机后,oracle占用/dev/shm的空间为什么不释放呢?
第二个问题:memory_max_target和memory_target设置多大合适,一般占内存的多少?还有就是/dev/shm和memory_max_target之间有没有比例关系。
最重要的问题,就是我不到宕机原因,根据您的文章http://www.oracledatabase12g.com ... B8%80%E4%BE%8B.html
我排除了Oracle实例资源不足的情况,我猜测的是内存不足造成的宕机,但是没有依据。
SQL> select * from v$resource_limit;
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
processes 37 49 150 150
sessions 44 70 170 170
enqueue_locks 39 87 2300 2300
enqueue_resources 33 33 968 UNLIMITED
ges_procs 0 0 0 0
ges_ress 0 0 0 UNLIMITED
ges_locks 0 0 0 UNLIMITED
ges_cache_ress 0 0 0 UNLIMITED
ges_reg_msgs 0 0 0 UNLIMITED
ges_big_msgs 0 0 0 UNLIMITED
ges_rsv_msgs 0 0 0 0
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
gcs_resources 0 0 0 0
gcs_shadows 0 0 0 0
dml_locks 2 2 748 UNLIMITED
temporary_table_locks 0 0 UNLIMITED UNLIMITED
transactions 2 27 187 UNLIMITED
branches 0 13 187 UNLIMITED
cmtcallbk 0 14 187 UNLIMITED
max_rollback_segments 19 19 187 65535
sort_segment_locks 0 1 UNLIMITED UNLIMITED
k2q_locks 0 0 340 UNLIMITED
max_shared_servers 1 1 UNLIMITED UNLIMITED
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
parallel_max_servers 0 0 40 3600
麻烦您帮忙分析一下,看看到底是什么原因,万分感谢!
附上alert log和trace。 |
|