Re: statspack report - SQL*Net data stuff

Hi from Paris

what is true, is that "SQL*Net messages to/from" are idle events, "more data to/from client" is saying you are facing a bandwith problem.

Look at theses statistics on the perfstat report:

SQL*Net roundtrips to/from client / seconds -> in order to know how frequent communication is, hence limited by network latency bytes received/send via SQL*Net from client / seconds -> both cumulated, to know the required bandwith

If you see that clients are making too frequent calls and roundtrips, then you should try to increase number of rows returned at each fetch (with ODBC, rowset), if bandwith is required, then your only choice is to increase network adapters, and switches, ....

you can still try to increase SDU/TDU size for SQL*Net related trafic (have a look at 'Net administrator guide' from RTFM).

"Karsten Farrell" <kfarrell_at_belgariad.com> a écrit dans le message de news:MPG.19353bf254f583c2989789_at_news.la.sbcglobal.net...
> hub_at_houston.rr.NOSPAM.com said...
> >
> > We're having some weird network problems and I think I'm seeing some of
it
> > in the statspack report. Here is an excerpt:
> >
> >
> > Event Waits Timeouts Time (s) (ms)
> > /txn
>
> ---------------------------- ------------ ---------- ---------- ------ ---

--


> > ---

> > db file sequential read         7,959,227          0      4,678      1

> > 10.3

> > db file scattered read          5,581,367          0      2,948      1

> > 7.3

> > log file sync                     824,640        160      2,195      3

> > 1.1

> > SQL*Net more data to client    17,819,017          0      1,317      0

> > 23.2

> > <snip>

> > SQL*Net message from client   133,289,942          0 ##########    190

> > 173.3

> >

> > Are those SQL*Net values excessive?

> >

> > Another symptom is that I will be scp'ing some files from one server to

> > another, then things slow down bigtime for awhile, then they resume

normal


> > transfer speed.  Any ideas on how I can track down this temporary

> > congestion, and might it be related to the SQL*Net waits?

> >

> >

> > Any info much appreciated.. thx!

> >

> Usually the SQL*Net values can be ignored. This from the book "Oracle

> Performance Tuning 101":

>

> "SQL*Net message from/to client"

> "Indicates elapsed time during communication between the user process

> and the server process. In some rare cases can shed light on a network

> transmission problem, but for the most part can be ignored. If the

> application supports the configuration of ARRAYSIZE (for example, Oracle

> Forms, SQL*Plus, Pro*C, and so on), configuring ARRAYSIZE to a value

> greater than its default value can potentially decrease the waits for

> this event."

>

> By saying "elapsed time," it tells me it's not really "wait" time ...

> except in the sense that the user can't do anything while sqlnet is

> talking.

> -- 

> /Karsten

> DBA > retired > DBA