wait events

From: Jack van Zanen <nlzanen1_at_ey.nl>
Date: Mon, 15 May 2000 16:14:54 +0100
Message-Id: <10498.105650@fatcity.com>

Hi All,

I have run utlestat & utlbstat plus some other scripts and have a lot of wait events

---

Event Name                       Count         Total Time    Avg Time
-------------------------------- ------------- ------------- -------------
SQL*Net message from client             443489       4645139         10.47
rdbms ipc message                         1995        999996        501.25
db file scattered read                 1087432        798071           .73
PL/SQL lock timer                            1         10001         10001
buffer busy waits                         3542          2415           .68
latch free                                6804          2149           .32
db file sequential read                  35326          1812           .05
SQL*Net message to client               443501           617             0
log file sync                             1354           514           .38
SQL*Net more data to client               5142            98           .02
control file sequential read                18             4           .22
enqueue                                      1             0             0
file open                                   13             0             0
refresh controlfile command                  6             0             0

14 rows selected.

SVRMGR>
SVRMGR>
SVRMGR> Rem System wide wait events for background processes (PMON, SMON, etc)
SVRMGR> select      n1.event "Event Name",
     2>             n1.event_count "Count",
     3>   n1.time_waited "Total Time",
     4>   round(n1.time_waited/n1.event_count, 2) "Avg Time"
     5>    from stats$bck_event n1
     6>    where n1.event_count > 0
     7>    order by n1.time_waited desc;
Event Name                       Count         Total Time    Avg Time
-------------------------------- ------------- ------------- -------------
rdbms ipc message                         5441       1383003        254.18
smon timer                                   7        210005      30000.71
pmon timer                                 668        200693        300.44
log file parallel write                   1456           499           .34
control file parallel write                666           420           .63
latch free                                   8             5           .63
control file sequential read                12             0             0

*****************************************************************************************************

The most of the buffer busy waits were on data blocks belonging to one table only.
The point is that performance of som infrastructure testing has decreased dramatically between two releases of this new soon to be live application. One of the requirements of the suppliers was to switch from 4k to 8K block size. so I rebuild the database and left all other parms the same.

Now performance is poor and they all point the finger at ORACLE. I defend oracle and say it's the application, but in the meantime will be rebuilding the database to 4K. Does anybody see anything else I should be looking at ?

Jack

---

De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. Ernst & Young staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan.

---

The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. Ernst & Young is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. Received on Mon May 15 2000 - 10:14:54 CDT