RE: How to trace the root cause of "SQL*Net more data to client" for only few executions of a query

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <gogala.mladen@xxxxxxxxx>, "'kyle Hailey'" <kylelf@xxxxxxxxx>, <krishsingh.111@xxxxxxxxx>
  • Date: Wed, 9 Oct 2019 16:35:13 -0400

And (again) if this is active only and missing the “idle” waits (that sometimes 
are idle), then a classic (for example) is if the 50 row initial retrieval 
default for sqldev is very occasionally exceeded, leaving the rest of the row 
delivery waiting for the doggone user to hit return. (Then you’re measuring 
something like a coffee break or a meeting time and the user hits return to 
free the session when they return.) 

 

This behavior sometimes leads people to configure connection timeouts and it 
can be frustrating and unreliable to try to change human behavior on this. And 
it is NOT the fault of sqldev.

 

Leaving a query hanging is also a great way to crank up active concurrent 
sessions!

 

mwf

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Wednesday, October 09, 2019 3:58 PM
To: kyle Hailey; krishsingh.111@xxxxxxxxx
Cc: ORACLE-L
Subject: Re: How to trace the root cause of "SQL*Net more data to client" for 
only few executions of a query

 

Well, kernel socket buffer may block if the network subsystem was not able to 
deliver the data. That is why increasing net.core.wmem_default and 
net.core.wmem_max are being checked during Oracle installation.

On 10/9/19 3:13 PM, kyle Hailey wrote:

And yes, Tanel is the expert here, see   
<http://blog.tanelpoder.com/2008/02/10/sqlnet-message-to-client-vs-sqlnet-more-data-to-client>
 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. "

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

Other related posts: