Heim  >  Artikel  >  Datenbank  >  AWR--servicestatistics

AWR--servicestatistics

WBOY
WBOYOriginal
2016-06-07 15:56:411265Durchsuche

最近发现一个奇怪的现象,数据库报告上看负载很高,但是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 El

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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Vorheriger Artikel:11203RAC(asm)恢复一例Nächster Artikel:要点Java20java.util.Collections