Comments on: SQL*Net message to client wait isn’t really what it’s thought to be http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/?utm_source=rss&utm_medium=rss&utm_campaign=sqlnet-message-to-client-wait-gotcha Oracle, Exadata, Performance, Troubleshooting - Mobile Life and Productivity. Wed, 08 Feb 2012 08:03:50 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Madhu http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-11337 Madhu Fri, 20 Jan 2012 11:16:26 +0000 http://tanelpoder.wordpress.com/?p=60#comment-11337 Cleared my doubts, love this blog Cleared my doubts, love this blog

]]> By: Book Review: Oracle SQL Recipes: A Problem – Solution Approach « Charles Hooper's Oracle Notes http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-4732 Book Review: Oracle SQL Recipes: A Problem – Solution Approach « Charles Hooper's Oracle Notes Mon, 07 Jun 2010 11:05:23 +0000 http://tanelpoder.wordpress.com/?p=60#comment-4732 [...] Page 500 states that the “SQL*Net message from client” wait event indicates possible network or middle-tier bottlenecks.  Client-side “think time” is probably the most significant contributor to this wait event, and I think that it would be very difficult to demonstrate that this wait event indicates network bottlenecks. [Reference/Test Case] [Reference/Test Case] [Reference/Test Case - Check the Comments Section Also] [...] [...] Page 500 states that the “SQL*Net message from client” wait event indicates possible network or middle-tier bottlenecks.  Client-side “think time” is probably the most significant contributor to this wait event, and I think that it would be very difficult to demonstrate that this wait event indicates network bottlenecks. [Reference/Test Case] [Reference/Test Case] [Reference/Test Case - Check the Comments Section Also] [...]

]]> By: Planning Manager 诊断过程和10046事件 : Fans Or Not http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-4709 Planning Manager 诊断过程和10046事件 : Fans Or Not Wed, 26 May 2010 08:23:37 +0000 http://tanelpoder.wordpress.com/?p=60#comment-4709 [...] 《SQL*Net message to client wait isn’t really what it’s thought to be》 [...] [...] 《SQL*Net message to client wait isn’t really what it’s thought to be》 [...]

]]> By: Tanel Poder http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-4290 Tanel Poder Sun, 28 Mar 2010 02:29:09 +0000 http://tanelpoder.wordpress.com/?p=60#comment-4290 Luis, you can download Snapper here: http://tech.e2sn.com/oracle-scripts-and-tools/ Luis, you can download Snapper here:

http://tech.e2sn.com/oracle-scripts-and-tools/

]]> By: Luis http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-4278 Luis Tue, 23 Mar 2010 15:25:27 +0000 http://tanelpoder.wordpress.com/?p=60#comment-4278 Hi Tanel, where can I get you snapper script ? Hi Tanel,
where can I get you snapper script ?

]]> By: Marjan Koloski http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-3872 Marjan Koloski Wed, 17 Feb 2010 22:12:02 +0000 http://tanelpoder.wordpress.com/?p=60#comment-3872 It was false alarm. Wrong presentation on the Quest Performance Analysis. In fact setting this parameter help with removing the log file sync wait events completely and reduced the oracle cpu utilization by 40%. In the top 5 wait events redo waits were replaced with network waits :) so we tought that we are hitting some side effect of the change. After comparing the AWR reports before and after the change we realized that there is no change in the network waits. Thanks and Best Regards Marjan It was false alarm. Wrong presentation on the Quest Performance Analysis. In fact setting this parameter help with removing the log file sync wait events completely and reduced the oracle cpu utilization by 40%. In the top 5 wait events redo waits were replaced with network waits :) so we tought that we are hitting some side effect of the change. After comparing the AWR reports before and after the change we realized that there is no change in the network waits.
Thanks and Best Regards
Marjan

]]> By: Tanel Poder http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-3858 Tanel Poder Mon, 15 Feb 2010 11:39:20 +0000 http://tanelpoder.wordpress.com/?p=60#comment-3858 <a href="#comment-3854" rel="nofollow">@Marjan Koloski</a> Hi Marjan, Can you run my snapper script ("snapper out 10 1 &sid") on one of these sessions and paste me the output, so I'd have better overview of what's going on. Perhaps the problem isn't the SQL*Net message to client itself, but an instrumentation bug with this workaround. @Marjan Koloski
Hi Marjan,

Can you run my snapper script (“snapper out 10 1 &sid”) on one of these sessions and paste me the output, so I’d have better overview of what’s going on. Perhaps the problem isn’t the SQL*Net message to client itself, but an instrumentation bug with this workaround.

]]> By: Marjan Koloski http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-3854 Marjan Koloski Mon, 15 Feb 2010 07:43:42 +0000 http://tanelpoder.wordpress.com/?p=60#comment-3854 Hi Tanel, on our production database Oracle Enterprise Edition 11.1.0.7 64 bit on Windows server 2003 due to the bug 6319685 LGWR posts do not scale on some platforms, we enabled the fix for this bug with setting undocumented parameter "_FG_SYNC_SLEEP_USECS"=1. Once we enable this parameter problem with the log file sync is solved but now we have the wait event SQL*Net message to client which is 20% of the total wait time. How SQL*Net message to client wait event is connected with the parameter _FG_SYNC_SLEEP_USECS ? How can we tune this ? Thanks Marjan Hi Tanel,
on our production database Oracle Enterprise Edition 11.1.0.7 64 bit on Windows server 2003 due to the
bug 6319685 LGWR posts do not scale on some platforms, we enabled the fix for this bug
with setting undocumented parameter “_FG_SYNC_SLEEP_USECS”=1. Once we enable this parameter problem with the log file sync is solved but now we have the wait event SQL*Net message to client which is 20% of the total wait time.
How SQL*Net message to client wait event is connected with the parameter _FG_SYNC_SLEEP_USECS ? How can we tune this ?
Thanks
Marjan

]]> By: Amos http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-3512 Amos Thu, 31 Dec 2009 20:22:47 +0000 http://tanelpoder.wordpress.com/?p=60#comment-3512 Hi Tanel, Thanks for your reply. Do you know your 2010 US seminars schedule? Happy New Year! Amos Hi Tanel,
Thanks for your reply.
Do you know your 2010 US seminars schedule?
Happy New Year!
Amos

]]> By: Tanel Poder http://blog.tanelpoder.com/2008/02/07/sqlnet-message-to-client-wait-gotcha/comment-page-1/#comment-3473 Tanel Poder Sat, 26 Dec 2009 15:09:31 +0000 http://tanelpoder.wordpress.com/?p=60#comment-3473 These numbers are measured across all databases calls, in other wrods things like parses, executions and fetches too (!) of that statement. So even if you execute once but fetch 10 times, the total waited will be the sum, the max waited will be maximum time waited during/between database calls. These numbers are measured across all databases calls, in other wrods things like parses, executions and fetches too (!) of that statement.

So even if you execute once but fetch 10 times, the total waited will be the sum, the max waited will be maximum time waited during/between database calls.

]]>