Tracing analysis
505417Jan 30 2008 — edited Feb 5 2008Hi,
We are investigating if potential benefits from database partitioning in our database. As a first step I run session tracing for the most time consuming reports. The results have taken me by surprise. It seems that I/O is not the reason of long reports execution time. Please check the following excerpt from the tkprof output for one of my reports.
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2259825 0.00 2.55
SQL*Net message from client 2259825 463.62 3568.29
SQL*Net break/reset to client 2 0.00 0.00
db file sequential read 241234 0.12 687.65
log file sync 3 0.00 0.00
SQL*Net more data from client 7 0.00 0.00
SQL*Net more data to client 78285 0.00 3.82
latch: cache buffers chains 55 0.00 0.00
latch: library cache 83 0.00 0.00
latch: library cache pin 53 0.00 0.00
latch: cache buffer handles 4 0.00 0.00
read by other session 1 0.00 0.00
Do you have any idea how I can diagnose the reason of " SQL*Net message from client". Is there something we can do with it? The same report with other parameters goes fast and smoothly, wait event time for " SQL*Net message from client" is almost equal to "db file sequential read". TCP connectivity between Oracle client and the oracle database is very good! Do you have any suspicions what can cause that bottleneck?
Kind Regards,
Tim