| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> wait events cntd..
Hi All,
We just checked with the new and "improved" (?) 4K block size and still poor performance. I think it's safe to say now that the application developers should be checking their code now.
By the way. I see a lot of wait events on db_file_scattered reads. Don't these point to lack of indexes??? (or at least the usage thereof)
Jack
---------------------- Forwarded by Jack van Zanen/nlzanen1/External/MEY/NL on 05/16/2000 08:24 AM ---------------------------
Please respond to ORACLE-L_at_fatcity.com
Sent by: root_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: wait events
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 014 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
 |
 |