| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Wait event problems
Excellent information! Thanks for taking the time to write it all down.
Beth
-----Original Message-----
Sent: Friday, June 14, 2002 10:42 AM
To: 'ORACLE-L_at_fatcity.com'
Cc: Seefelt, Beth
Well, with all the caveats that's a long and boring story, so I'll
shorten
it up. ;)
TRACE_LEVEL_CLIENT = SUPPORT TRACE_FILE_CLIENT = sqlnet TRACE_DIRECTORY_CLIENT = /some/directory TRACE_UNIQUE_CLIENT = on
4a) If you aren't using TNSNAMES, make sure your NAMES.DIRECTORY_PATH
in
the SQLNET.ORA starts with TNSNAMES.
5) Connect a test client. Do some work from this client, preferrably
as
close to a "real" user as possible. Note that the tracefile created
will
contain every bit from every packet sent to and from the client, as well
as
all the overhead involved for debugging, so the file can grow large
quick.
It only less than 5 minutes of testing to produce a 55MB trace file for
us.
6) Disconnect the test client. Before running trcasst, you'll need to
edit
the trace file in order to workaround a bug in trcasst. If you're
Unix-y,
you can use this instead of trying to pull 50+MB into mem (VERY crude
SED --
there's a much more elegant way of doing this!):
mv sqlnet_xxxx.trc t.t
sed -e 's/nspsend: /nspsend:/g' t.t >t.tt
rm t.t
sed -e 's/nsprecv: /nsprecv:/g' t.tt >t.t
rm t.tt
sed -e 's/nsprcvs: /nsprcvs:/g' t.t >t.tt
rm t.t
rm sqlnet_xxxx.trc
mv t.tt sqlnet_xxxx.trc
The "rm"s are in there to reduce the amount of disk needed. PLEASE
adjust
for your own environment! If you're using Winders, get CygWin to use
sed
(or use any of a number of tools for search/replace).
7) trcasst -od sqlnet_xxxx.trc >sqlnet_xxxx.lis
8) Examine the .lis file for send/receive packet sizes. I dumped the
output from a grep of the .lis file to MS Exhell to graph the send and
recieve packets. It's easier for me to see the need for a larger SDU
when
the graph shows a nice square wave pattern. The theory being that if
SQL*Net is pushing the maximum SDU size several packets in a row (a
nice,
flat horizontal line at the top of the graph), that the SDU could stand
to
be larger so as to minimize the length of that line.
9) Repeat steps 5 thru 8 with different values of SDU, remembering to change both the client and the server, and to restart the listener after each change.
Anyone care to comment on this? This is pretty much just what I figured
out
yesterday, so I'm interested to know of any "whoopses" I may have made.
One
thing I'm not sure of is "How big is too big for an SDU value?".
HTH! GL! Happy Flag Day! :)
Rich Jesse System/Database Administrator Rich.Jesse_at_qtiworld.com Quad/Tech International, Sussex, WIUSA
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Seefelt, Beth INET: Beth.Seefelt_at_TetleyUSA.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Fri Jun 14 2002 - 10:53:28 CDT
 |
 |