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