Good points. I use the sql monitor active report and
I have seen cases where sql*net message from client are missing from sql
monitor report and DBA_HIST_ACTIVE_SESS_HISTORY. but in this case i do see
few samples for "SQL*Net message from client" as well.
I am checking on other points that you have mentioned along with other
useful points mentioned by Dominic, Mark .
On Wed, Oct 9, 2019 at 1:50 PM Andy Sayer <andysayer@xxxxxxxxx> wrote:
What are you using to show “ most of the time is being spent on "SQL*Net
more data to client"”? Is it something that will ignore sql*net message
A standard 10046 trace will show you everything you really need here -
rows returned in a fetch and individual wait times for this event and how
often they occurred for a fetch.
What’s client driver being used? How is the fetching configured?
On Wed, 9 Oct 2019 at 18:34, Mark W. Farnham <mwf@xxxxxxxx> wrote:
and (not but) are different client programs or client locations the
“catchers” of the data?
if different, seeing if the slow ones are consistently of a type could be
useful in diagnosis and prevention.
a VLAN with no real QOS (even if configured and promised) can also
correlate with this, especially if the physical LAN is used for video.
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Dominic Brooks
*Sent:* Wednesday, October 09, 2019 1:16 PM
*Subject:* Re: How to trace the root cause of "SQL*Net more data to
client" for only few executions of a query
What arraysize is being used ? What’s the average row size?
Sent from my iPhone
On 9 Oct 2019, at 17:32, kunwar singh <krishsingh.111@xxxxxxxxx> 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.
For other executions we dont see that wait event being a problem.
What kind of tracing can we do to go in depth of the issue. I want to be
sure before i suggest some tuning at SDU sizing level etc.
Because we cannot predict when the slow run of the query will happen we
cannot wait for it and then run strace etc exactly at that time ,Basically
we will have to automate the tracing step.