ksvcreate: Process(m001) creation failed
本帖最后由 黑豆 于 2013-12-28 18:46 编辑os：Linux Server release 5.4 (Tikanga)
db：oracle 10.2.0.4.0 dataguard 最大性能模式
主库问题描述：
1. alert日志，
Fri Dec 27 23:18:19 2013
Thread 1 advanced to log sequence 269 (LGWR switch)
Current log# 1 seq# 269 mem# 0: /oradata/redo01.log
Current log# 1 seq# 269 mem# 1: /oracle/onlinelog/redo01_b.log
Sat Dec 28 02:03:03 2013
ksvcreate: Process(m001) creation failed
Sat Dec 28 02:21:56 2013
ksvcreate: Process(m001) creation failed 之后就没有了
2. 今天中午发现，然后关闭库时报错：
SQL> shutdown immediate
ORA-24324: service handle not initialized
ORA-24323: value not allowed
ORA-00020: maximum number of processes (%s) exceeded
数据库的process数是1600，session数是1750，平时监控时这个库的awr中的session数才80
3. netstat -an发现38个状态为FIN_WAIT2的前台应用程序的连接，137个状态为ESTABLISHED的连接，未监测过正常情况下的ESTABLISHED连接有多少
例如：
d-Q Local Address Foreign Address State
0 192.168.0.111:1521 192.168.0.111:40830 FIN_WAIT2
发生mmon的slave进程m001创建失败的原因猜测：
1. 是不是由于前台应用192.168.0.111要关闭连接，但是数据库服务器没有成功发送FIN包，造成长时间等待于FIN_WAIT2状态，是不是FIN_WAIT2状态很耗费资源，也会导致连接数急剧增加，同时造成m001失败？如果是的话，如何理解？如果不是，需要从哪些方面查找m001进程失败的原因呢？
2. 单纯针对FIN_WAIT2来说，是不是需要在192.168.0.111端增加net.ipv4.tcp_fin_timeout 的控制，来决定保持在FIN_WAIT2状态的时间？
谢谢各位的浏览 需要当时的AWR
以及alert.log
和
select * from v$resource_limit 本帖最后由 黑豆 于 2013-12-29 11:39 编辑
Maclean Liu(刘相兵 发表于 2013-12-28 20:35 static/image/common/back.gif
需要当时的AWR
以及alert.log
select * from v$resource_limit
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
processes 80 96 1600 1600
sessions 88 102 1765 1765
enqueue_locks 14 40 21390 21390
enqueue_resources 14 38 7984 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
gcs_resources 0 0 0 0
gcs_shadows 0 0 0 0
dml_locks 0 50 7764 UNLIMITED
temporary_table_locks 0 3 UNLIMITED UNLIMITED
transactions 0 9 1941 UNLIMITED
branches 0 0 1941 UNLIMITED
cmtcallbk 0 1 1941 UNLIMITED
sort_segment_locks 9 43 UNLIMITED UNLIMITED
max_rollback_segments 11 11 1941 65535
max_shared_servers 0 0 UNLIMITED UNLIMITED
parallel_max_servers 0 7 160 3600
附件包含四个文件
1. 日期为201312280102的附件是发生进程失败的前一个小时的awr报告，有对应的addm
2. 日期为201312250102的附件是与12月28日有一样操作的exp的awr对比报告
3. 日期为201312270912的附件是上午三个小时（OA库）的awr报告，与平时的监控报告数据统计无大的差别
其中top1 sql中的半连接里的sql已经优化改进，top2的sql select 1 from dual 不知何含义，有说是连接池同数据库相连之前的验证，但是这个系统的这个sql执行次数很多，目前重启的数据库里在v$sql中查询这个sql的执行次数已经达到790122，但是我在其他负载比这个高很多的系统中，发现这个sql select 1 from dual 的执行次数才366
4. alert文件为近一周的log日志 总的物理内存15g
sga设置12g ， pga_aggregate_target 2g
这个内存设置不太合理 12/15=80% ， sga设置不要超过物理内存的70%
需要当时的OSW or nmon数据进一步分析 Maclean Liu(刘相兵 发表于 2013-12-29 12:18 static/image/common/back.gif
总的物理内存15g
sga设置12g ， pga_aggregate_target 2g
谢谢给出的建议，但是没有当时相关的nmon数据，数据库版本是10.2.0.4.0，现在就暂时定为是bug5377099引起的了。sga已经缩小为10g。
因为系统是采用的短连接，应该是这个引起的select 1 from dual比较高的原因。 问题解决了么？ ，类似你这个情况，很多都是递归sql在内部触发的session
页:
[1]