Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › oracle 10g 单机异常hang住，所有新连接不能连接问题请 ...
发新帖
unodba

0

积分

1

好友

3

主题

[SQL调优] oracle 10g 单机异常hang住，所有新连接不能连接问题请教

1#
发表于 2013-1-14 10:09:36 | 查看: 7079| 回复: 20
本帖最后由 unodba 于 2013-1-14 21:51 编辑

aix 5.3下，oracle 10.2.4版本，在1月10号晚上10点后，发现不能新建所有连接，数据库已不能使用，查看alert日志，发现在Thu Jan 10 22:18:22 2013后报kkjcre1p: unable to spawn jobq slave process ，查看当时的ora_j进程有10个，job_queue_processes参数值也是10,不清楚是否为此参数导致。具体日志在附件。

alert_com3000.rar

164.29 KB, 下载次数: 1615

awrrpt_20120110.html

287.46 KB, 下载次数: 927

awrrpt
2#
发表于 2013-1-14 10:35:47
问题主要在：ORA-3136——WARNING Inbound Connection Timed Out
先检查系统资源占用率是不是是很高（cpu，内存）？，再从网络上查看网络问题（利用率，网速等）




回复 只看该作者 道具 举报

3#
发表于 2013-1-14 10:59:02
同一时间点的连接过多？

回复 只看该作者 道具 举报

4#
发表于 2013-1-14 10:59:53
  1. *** SERVICE NAME:(SYS$BACKGROUND) 2013-01-01 22:32:19.384
  2. *** SESSION ID:(3297.1) 2013-01-01 22:32:19.379
  3. Waited for process J002 to initialize for 60 seconds
  4. *** 2013-01-01 22:32:19.420
  5. Dumping diagnostic information for J002:
  6. OS pid = 795072
  7. loadavg : 0.14 0.29 0.84
  8. swap info: free_mem = 20.02M rsv = 64.00M
  9.            alloc = 7547.50M avail = 16384.00M swap_free = 8836.50M
  10.        F S      UID     PID    PPID   C PRI NI ADDR    SZ    WCHAN    STIME    TTY  TIME CMD
  11.   240001 A   oracle  795072       1   0  60 20 91f08590 92404          22:31:19      -  0:00 ora_j002_com3000
  12. open: Permission denied
  13. Warning: executed in non-root mode
  14. procstack cannot verify that /unix matches the running kernel.
  15. Kernel symbols might not be validated.
  16. 795072: ora_j002_com3000
  17. 0x00000001000fc898  sskgpwwait(??, ??, ??, ??, ??) + 0x38
  18. 0x00000001000f9e7c  skgpwwait(??, ??, ??, ??, ??) + 0xbc
  19. 0x000000010011dbac  kslges(??, ??, ??, ??, ??) + 0x54c
  20. 0x00000001001219dc  kslgetl(??, ??, ??, ??) + 0x33c
  21. 0x00000001049f0978  ksfglt(??, ??, ??, ??, ??) + 0x198
  22. 0x00000001000847b4  kghfrunp(??, ??, ??, ??, ??, ??, ??) + 0x794
  23. 0x000000010007a488  kghfnd(??, ??, ??, ??, ??, ??) + 0x7e8
  24. 0x0000000100098444  kghalo(??, ??, ??, ??, ??, ??, ??, ??) + 0xa24
  25. 0x0000000100005908  ksp_param_handle_alloc(??) + 0x168
  26. 0x000000010001d21c  kspcrec(??) + 0x1bc
  27. 0x00000001001407e8  ksucre(??) + 0x408
  28. 0x0000000103081ab0  kkjrdp() + 0x350
  29. 0x000000010430c190  opirip(??, ??, ??) + 0x4f0
  30. 0x0000000102d9a598  opidrv(??, ??, ??) + 0x458
  31. 0x000000010370b0b0  sou2o(??, ??, ??, ??) + 0x90
  32. 0x0000000100000870  opimai_real(??, ??) + 0x150
  33. 0x00000001000006d8  main(??, ??) + 0x98
  34. 0x0000000100000368  __start() + 0x98
  35. *** 2013-01-01 22:32:24.404
  36. *** 2013-01-01 22:32:34.405
  37. Waited for process J002 to initialize for 70 seconds
  38. *** 2013-01-01 22:32:34.405
  39. Dumping diagnostic information for J002:
  40. OS pid = 795072
  41. loadavg : 0.11 0.28 0.83
  42. swap info: free_mem = 35.31M rsv = 64.00M
  43.            alloc = 7547.08M avail = 16384.00M swap_free = 8836.92M
  44.        F S      UID     PID    PPID   C PRI NI ADDR    SZ    WCHAN    STIME    TTY  TIME CMD
  45.   240001 A   oracle  795072       1   0  60 20 91f08590 92404          22:31:19      -  0:00 ora_j002_com3000
  46. open: Permission denied
  47. Warning: executed in non-root mode
  48. procstack cannot verify that /unix matches the running kernel.
  49. Kernel symbols might not be validated.
  50. 795072: ora_j002_com3000
  51. 0x00000001000fc898  sskgpwwait(??, ??, ??, ??, ??) + 0x38
  52. 0x00000001000f9e7c  skgpwwait(??, ??, ??, ??, ??) + 0xbc
  53. 0x000000010011dbac  kslges(??, ??, ??, ??, ??) + 0x54c
  54. 0x00000001001219dc  kslgetl(??, ??, ??, ??) + 0x33c
  55. 0x00000001049f0978  ksfglt(??, ??, ??, ??, ??) + 0x198
  56. 0x00000001000847b4  kghfrunp(??, ??, ??, ??, ??, ??, ??) + 0x794
  57. 0x000000010007a488  kghfnd(??, ??, ??, ??, ??, ??) + 0x7e8
  58. 0x0000000100098444  kghalo(??, ??, ??, ??, ??, ??, ??, ??) + 0xa24
  59. 0x0000000100005908  ksp_param_handle_alloc(??) + 0x168
  60. 0x000000010001d21c  kspcrec(??) + 0x1bc
  61. 0x00000001001407e8  ksucre(??) + 0x408
  62. 0x0000000103081ab0  kkjrdp() + 0x350
  63. 0x000000010430c190  opirip(??, ??, ??) + 0x4f0
  64. 0x0000000102d9a598  opidrv(??, ??, ??) + 0x458
  65. 0x000000010370b0b0  sou2o(??, ??, ??, ??) + 0x90
复制代码
每次stack call都等kslgetl  ，可能与latch相关

需要当时的AWR

回复 只看该作者 道具 举报

5#
发表于 2013-1-14 11:11:38
Thu Jan 10 22:18:22 2013
ksvcreate: Process(m000) creation failed
Thu Jan 10 22:45:42 2013
kkjcre1p: unable to spawn jobq slave process
Thu Jan 10 22:45:42 2013
Errors in file /home/oracle/admin/com3000/bdump/com3000_cjq0_217288.trc:

Thu Jan 10 22:46:43 2013
PMON failed to acquire latch, see PMON dump
Thu Jan 10 22:47:55 2013
ksvcreate: Process(m000) creation failed
Thu Jan 10 22:51:35 2013
kkjcre1p: unable to spawn jobq slave process
Thu Jan 10 22:51:35 2013
Errors in file /home/oracle/admin/com3000/bdump/com3000_cjq0_217288.trc:

楼主说的应该是这个问题吧。

如果是job参数不足的话，job会发生等待，不会出现这个报错。

这个报错应该是和资源不足有关。 trc文件读不懂。

回复 只看该作者 道具 举报

wlq
6#
发表于 2013-1-14 16:45:58
Waited for process J002 to initialize for 60 seconds

这个job等待很长时间。你连接超时估计是这个job造成的。

回复 只看该作者 道具 举报

7#
发表于 2013-1-14 20:07:05
wlq 发表于 2013-1-14 16:45
Waited for process J002 to initialize for 60 seconds

这个job等待很长时间。你连接超时估计是这个job造 ...

连接超时是一直存在的，几个程序的通道一直存在问题

回复 只看该作者 道具 举报

8#
发表于 2013-1-14 20:16:44
aaaaaaaa2000 发表于 2013-1-14 10:59
同一时间点的连接过多？

当时所有的进程大概489个

回复 只看该作者 道具 举报

9#
发表于 2013-1-14 21:52:17
Maclean Liu(刘相兵 发表于 2013-1-14 10:59
每次stack call都等kslgetl  ，可能与latch相关

需要当时的AWR

刘大，取了10点之前的awr，这样能否更进一部诊断？

回复 只看该作者 道具 举报

10#
发表于 2013-1-14 21:56:32
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                  15,948                  53.4         
latch: library cache         1,152,690         10,442         9         34.9        Concurrency
latch: shared pool         863,510         1,008         1         3.4        Concurrency
log file sync         519,178         471         1         1.6        Commit
latch free         122,854         417         3         1.4        Other



latch: library cache+ latch: shared pool

Hard parses:         173.34         4.86 大量的硬解析

Pool        Name        Begin MB        End MB        % Diff
java        free memory        32.00        32.00        0.00
large        PX msg pool        1.03        1.03        0.00
large        free memory        14.97        14.97        0.00
shared        CCursor        488.49        468.75        -4.04
shared        Cursor Stats        89.80        89.80        0.00
shared        PCursor        664.05        670.05        0.90
shared        free memory        2,031.99        2,028.80        -0.16
shared        kglsim heap        127.59        127.59        0.00
shared        kglsim object batch        149.76        149.76        0.00
shared        library cache        337.04        325.86        -3.32
shared        sql area        1,445.52        1,469.04        1.63
        buffer_cache        1,344.00        1,344.00        0.00
        fixed_sga        2.00        2.00        0.00
        log_buffer        14.00        14.00        0.00


shared pool component基本没变化，排除shared pool shrink造成解析问题的可能

回复 只看该作者 道具 举报

11#
发表于 2013-1-14 21:59:22
        Begin        End
Memory Usage %:         63.92         63.98
% SQL with executions>1:         25.85         40.66
% Memory for SQL w/exec>1:         25.92         40.80


SQL重用率极低


Statistic Name        Time (s)        % of DB Time
DB CPU        15,948.29        53.37
sql execute elapsed time        13,767.46        46.08
parse time elapsed        13,518.19        45.24
hard parse elapsed time        8,269.31        27.67

parse time占了45% hard parse 27， 解析是主要问题


这个库 平时解析压力估计也不小， 在某根稻草被压上后最终hang住属于正常现象

至少需要调优SQL解析

回复 只看该作者 道具 举报

12#
发表于 2013-1-16 00:32:23
本帖最后由 wind 于 2013-1-16 01:25 编辑
Maclean Liu(刘相兵 发表于 2013-1-14 21:59
Begin        End
Memory Usage %:         63.92         63.98
% SQL with executions>1:         25.85         40.66


学习了。。。也可以尝试先增大shared pool size?看能否缓解一下问题。当然刘大说的要照做。

回复 只看该作者 道具 举报

13#
发表于 2013-1-16 16:43:59
wind 发表于 2013-1-16 00:32
学习了。。。也可以尝试先增大shared pool size?看能否缓解一下问题。当然刘大说的要照做。 ...

出现硬解析首先要考虑的是 使用绑定变量的方式...

如果单单只扩大shared_pool_size的话,反而可能cpu的负载会加大

回复 只看该作者 道具 举报

14#
发表于 2013-1-16 16:47:54
刘大分析的好啊~~学习了。硬解析很多，对性能影响大，找到sql进行调优吧。

回复 只看该作者 道具 举报

15#
发表于 2013-1-16 16:57:54
wind 发表于 2013-1-16 00:32
学习了。。。也可以尝试先增大shared pool size?看能否缓解一下问题。当然刘大说的要照做。 ...

共享池貌似不是问题，很合理啊。才64%哦。，共享池（share pool）内存被使用的比例。这个指标的值应保持在75%~90%,如果这个值太低，就浪费内存，如果太高，会使共享池外部的组件老化，如果sql语句被再次执行，则就会发生硬分析。

回复 只看该作者 道具 举报

16#
发表于 2013-1-16 23:27:14
关注下，是不是你的内存不足，swap使用的过多，导致shared pool相关等待异常
08.swap info: free_mem = 20.02M rsv = 64.00M

09.           alloc = 7547.50M avail = 16384.00M swap_free = 8836.50M

具体见我最近一篇类此blog

回复 只看该作者 道具 举报

17#
发表于 2013-1-17 08:09:21
ricky 发表于 2013-1-16 16:57
共享池貌似不是问题，很合理啊。才64%哦。，共享池（share pool）内存被使用的比例。这个指标的值应保持 ...

说的对，oltp系统硬解释是硬伤。

回复 只看该作者 道具 举报

18#
发表于 2013-1-17 08:09:49
xifenfei 发表于 2013-1-16 23:27
关注下，是不是你的内存不足，swap使用的过多，导致shared pool相关等待异常
08.swap info: free_mem = 20. ...

8g的空闲swap，不算少吧。

回复 只看该作者 道具 举报

19#
发表于 2013-1-17 21:22:57
xifenfei 发表于 2013-1-16 23:27
关注下，是不是你的内存不足，swap使用的过多，导致shared pool相关等待异常
08.swap info: free_mem = 20. ...

好的，我来看看

回复 只看该作者 道具 举报

20#
发表于 2013-1-20 11:46:26
wind 发表于 2013-1-17 08:09
8g的空闲swap，不算少吧。

使用了近8g难道正常？

回复 只看该作者 道具 举报

21#
发表于 2013-1-20 16:18:41
swap 这个信息值得一看， 但就 以往的经验 这个 trace里的swap信息经常不准确， 我还看到过swap free 0MB的情况，但实际swap一点也没用。

所以可以参考，但未必100%准确， 要看实际情况 还是看osw来的切实。

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-26 13:46 , Processed in 0.065816 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569