黑豆

0 积分	1 好友	9 主题

发消息

[升级] ksvcreate: Process(m001) creation failed

1^#

发表于 2013-12-28 18:45:43 | 查看: 4952| 回复: 5

本帖最后由黑豆于 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状态的时间？

谢谢各位的浏览

分享0

收藏0 回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2013-12-28 20:35:02

需要当时的AWR

以及alert.log

和

select * from v$resource_limit

回复只看该作者道具举报

黑豆

3^#

发表于 2013-12-29 11:36:12

本帖最后由黑豆于 2013-12-29 11:39 编辑

Maclean Liu(刘相兵发表于 2013-12-28 20:35
需要当时的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日志