Yes, those are my slides on Kellyn's site. And as I recall the only network
wait event that includes network time is
- "SQL*Net more data from client".
And yes, Tanel is the expert here, see SQL*Net message to client
"I”ll reiterate that both SQL*Net message to client and SQL*Net more data
to client waits only record the time it took to write the return data from
Oracle’s userland SDU buffer to OS kernel-land TCP socket buffer. "
He's the one who tracked down that the other wait events like
- SQL*Net message to client
- SQL*Net more data to client
are just measuring the time it takes to package the data and send it out to
the wire, not how long it takes to get to the client.
Though SQL*Net more data to client as I recall could show a problem with
your network processing on your Oracle host.
On Wed, Oct 9, 2019 at 11:56 AM kunwar singh <krishsingh.111@xxxxxxxxx>
This wait is confusing. If i see this link ,
https://dbakevlar.com/2014/03/oracle-sqlnet-wait-events/ it means doesnt
include network timings. Does your above explanation mean that below is
Wait represents the time it takes to pack data.
Doesn’t include network timing
On Wed, Oct 9, 2019 at 2:52 PM Mladen Gogala <gogala.mladen@xxxxxxxxx>
On 10/9/19 12:30 PM, kunwar singh wrote:
Our customer have one job which runs daily and one of the sqls which
executes like 500 times had 5 odd executions where it runs slower and
most of the time is being spent on "SQL*Net more data to client" .
Normal run times are like few seconds and the longer run times are
like 1 hour or so.
Personally, I don't think that this is an Oracle problem. You have a
network connection that is unable to keep up with demand. I've seen that
happen with application servers like WebLogic which request large
amounts of data from the database and are on 1 GB LAN. Another example
is when a slow PC is trying to pull a huge extract or report from the
database. That can be helped by making the IP queue size longer.
Tel: (347) 321-1217