Re: To increase a packet size for local connection (SDU,TDU,IPC,BEQ)

Hi !

All the elapsed time for these waits is 0, which means that SQL*Net communication IS NOT a bottleneck here.
Depending on the behaviour of your batch process, you may experience an increase in performance (and maybe packet size), by using array processing (processing multiple lines in one operation), therefore minimizing the number of roundtrips needed.

Anyway, the SQL*Net communication might not be the real bottleneck. As mentionned by Herman, you must have a look at the != stats, especially the ones about system wait time (v$system_event and such)...

Bye !

Sur Tue, 25 Jun 2002 11:23:38 GMT, Herman de Boer <h.de.boer_at_itcg.nl> a écrit:
> Hello Stano,
>
> From the trace file bit you sended, there might be a lot of waits, but
> they seem all to be performed in the same 1/100th of a second
> (tim=1229996800). I think that you should investigate, for the full
> month-end batch job, the aggregated wait events, their times and
> counts. IPC communication is usually pretty fast, times faster than
> tcp/ip. Therefore, I guess, enlarging the packetsize will not help
> much.
>
> Usually, improving a few bad-performing sql-statements might shorten
> the duration times significantly.
>
> Stano wrote:
>
> >Hi there,
> >
> >a month-end batch process reads a lot of data from a table and
> >the data is subsequently being processed. It runs on the same server
> >where the database resides (DEC 8400). The trace reveals a lot waits
> >for 'SQL*Net more data to client':
> >
> >EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0
> >WAIT #1: nam='db file sequential read' ela= 0 p1=31 p2=31179 p3=1
Received on Tue Jun 25 2002 - 07:48:34 CDT