|
最近发现一个奇怪的现象,数据库报告上看负载很高,但是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 StatisticsService 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的脚本监控一下,是哪个进程导致。最后诊断出是数据库服务器在某个时间段不响应,简单的说是硬件的问题。
|