|
最近发现一个奇怪的现象，数据库报告上看负载很高，但是cpu和等待事件都很低，不知道消耗的资源跑到哪里去了？
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
| Begin Snap: |
5073 |
17-5月 -14 04:00:20 |
127 |
78.8 |
| End Snap: |
5074 |
17-5月 -14 05:13:36 |
363 |
19.5 |
| Elapsed: |
? |
73.27 (mins) |
? |
? |
| DB Time: |
? |
1,196.25 (mins) |
? |
? |
Top 5 Timed Events
| Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
| latch: library cache |
3,174 |
6,933 |
2,184 |
9.7 |
Concurrency |
| latch free |
977 |
6,530 |
6,684 |
9.1 |
Other |
| latch: shared pool |
4,021 |
1,929 |
480 |
2.7 |
Concurrency |
| cursor: pin S wait on X |
82,902 |
1,620 |
20 |
2.3 |
Concurrency |
| CPU time |
? |
1,073 |
? |
1.5 |
? |
Service Statistics
- ordered by DB Time
| Service Name |
DB Time (s) |
DB CPU (s) |
Physical Reads |
Logical Reads |
| SYS$USERS |
67,080.30 |
454.30 |
43,604 |
15,183,498 |
| scmis |
4,523.20 |
588.30 |
0 |
22,868,201 |
| SYS$BACKGROUND |
0.00 |
0.00 |
109 |
77,783 |
可以看到数据库软件消耗的资源不多。 找到问题症结：再看servicestatistics总的SYS$USERS消耗最多，这个是何方圣神呢？官方文档的解释：the SYS$USERS serviceis the default service name used when a user session is established withoutexplicitly identifying its service name。就是说SYS$USERS这是一个缺省的服务名，当用户的session建立的时候没有明确的标示符。 那说明此时有其他的服务在数据库服务器上跑，只有用操作系统层面上做诊断，用shell写一个top的脚本监控一下，是哪个进程导致。最后诊断出是数据库服务器在某个时间段不响应，简单的说是硬件的问题。
|