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

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala Sent: Wednesday, October 09, 2019 3:58 PM To: kyle Hailey; krishsingh.111_at_gmail.com 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



--
http://www.freelists.org/webpage/oracle-l