Comments on: SQL*Net message to client wait isn’t really what it’s thought to be

By: Marjan Koloski

Marjan Koloski — Wed, 17 Feb 2010 22:12:02 +0000

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

Tanel Poder — Mon, 15 Feb 2010 11:39:20 +0000

@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

Marjan Koloski — Mon, 15 Feb 2010 07:43:42 +0000

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

Amos — Thu, 31 Dec 2009 20:22:47 +0000

Hi Tanel,
Thanks for your reply.
Do you know your 2010 US seminars schedule?
Happy New Year!
Amos

By: Tanel Poder

Tanel Poder — Sat, 26 Dec 2009 15:09:31 +0000

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.

By: Amos

Amos — Sat, 26 Dec 2009 06:33:42 +0000

Tanel,
sql*net message to client and from client are the two top wait events in one of my SQL trace file. In the TKPROF formatted trace file, I have the following:
Event waited on Times Max. Wait Total Waited
—————————————- Waited ———- ————
SQL*Net message to client 37776 0.00 0.11
SQL*Net message from client 37776 0.56 21.76

What’s the relationship between “Total Waited” and “Max Waited”? Is either the 0.56 seconds or 21.76 seconds (?) a measurement of one single execution?

Thanks,
Amos

By: Daniel, Wu

Daniel, Wu — Tue, 15 Dec 2009 12:57:15 +0000

In all lines, #bytes=1. So why bytes=1?

WAIT #7: nam=’SQL*Net message to client’ ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=16418644515
WAIT #5: nam=’SQL*Net message to client’ ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=16428803213
W

By: megan fox superman pic

megan fox superman pic — Fri, 20 Nov 2009 17:10:11 +0000

Sign: dgcph Hello!!! mxzsb and 8912htudqtpfqb and 9065 : Hi! I was surfing and found your blog post! nice! I just came across your blog and wanted to say that Ive really enjoyed it.

By: sandrar

sandrar — Thu, 10 Sep 2009 22:36:11 +0000

Hi! I was surfing and found your blog post… nice! I love your blog. :) Cheers! Sandra. R.

By: Mike

Mike — Sat, 17 Jan 2009 00:22:42 +0000

Glen Fawcett wrote a SUN Blue Print paper in 2003 (Sun Part # 817-1781-10) and he says the SDU and TDU must be sized according to the MTU for the interface. On SUN Solaris the default MTU size for the NIC is 1500 and the SDU and TDU should be set to integral values of the MTU setting for the NIC. For example for an MTU size of 1500, SDU and TDU can be set to 15000. This is recommend to reduce the number and ave time waited for SQLNet wait events. Glen also says it is best to set the TDU = SDU. I have tried this method and I see it decreased the number and ave time waited for the SQLNet waits by half.