SQL*Net message from client

  • From: "Charudatta Joshi" <joshic@xxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Sat, 3 Dec 2005 20:28:36 +0530

Dear all,

Version: 9.2.0.6
OS: Solaris 8

I am tracing a very very slow session. I am seeing a strange thing in
the trace file generated. I see a recursive SQL taking LOTS and LOTS of
'SQL*Net Message from client' and 'SQL*Net Message to client' events,
with the former taking majority of time. An excerpt from the trace file
is given below.

What I find strange is why should a recursive SQL statement like the one
given below have to connect any client at all? Could the client here be
the shadow server process? In any case why should it spend so much time
here and how to cure this?

Thanks & Regards,
Charu.


PARSING IN CURSOR #2 len=283 dep=1 uid=0 oct=6 lid=0 tim=13775679437729
hv=3948238198 ad='945716a8'
update seg$ set
type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:1
0,user#=:11,iniexts=:12,lists=decode(:13, 65535, NULL,
:13),groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16,
spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2 and block#=:3
END OF STMT
PARSE
#2:c=20000,e=21345,p=0,cr=89,cu=0,mis=1,r=0,dep=1,og=0,tim=1377567943772
1
EXEC #2:c=0,e=2002,p=0,cr=5,cu=1,mis=0,r=1,dep=1,og=4,tim=13775679440193
STAT #2 id=1 cnt=0 pid=0 pos=1 obj=0 op='UPDATE  (cr=5 r=0 w=0 time=922
us)'
STAT #2 id=2 cnt=1 pid=1 pos=1 obj=14 op='TABLE ACCESS CLUSTER SEG$
(cr=5 r=0 w=0 time=499 us)'
STAT #2 id=3 cnt=1 pid=2 pos=1 obj=9 op='INDEX UNIQUE SCAN
I_FILE#_BLOCK# (cr=2 r=0 w=0 time=34 us)'
EXEC
#1:c=30000,e=36596,p=0,cr=106,cu=28,mis=0,r=1,dep=0,og=4,tim=13775679441
350
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 7109 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=294,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679449343
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 6787 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=173,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679456514
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 6846 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=203,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679463770
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 6792 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=149,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679470908
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 6811 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=145,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679478059
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1413697536 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 6839 p1=1413697536 p2=1
p3=0
EXEC #1:c=0,e=182,p=0,cr=0,cu=3,mis=0,r=1,dep=0,og=4,tim=13775679485278
WAIT #1: nam='SQL*Net message to client' ela= 1 p1=1413697536 p2=1 p3=0

*********************************************************
Disclaimer:

The contents of this E-mail (including the contents of the enclosure(s) or 
attachment(s) if any) are privileged and confidential material of MBT and 
should not be disclosed to, used by or copied in any manner by anyone other 
than the intended addressee(s).   In case you are not the desired addressee, 
you should delete this message and/or re-direct it to the sender.  The views 
expressed in this E-mail message (including the enclosure(s) or attachment(s) 
if any) are those of the individual sender, except where the sender expressly, 
and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of 
any virus.  However, it is the responsibility of the recipient to ensure that 
it is virus free and MBT is not responsible for any loss or damage arising in 
any way from its use

*********************************************************
--
//www.freelists.org/webpage/oracle-l


Other related posts: