Sybrand Bakker wrote:
> On Wed, 13 Nov 2002 16:00:24 -0500, "Jerry D"
> <jdubuke_at_notme.gpdservices.com> wrote:
>
>
>>I looked on tahiti and it did not talk about 8.0.6, so I am still looking
>>for information regarding sql*net and any tuning parameters I can use to
>>make my system more efficient!
>
>
> There are 2 main gotcha's when using sql*net.
> 1 - your SDU (session data unit) isn't a multiple of the Max
> Transmission Unit of the network card (usually 1500 for ethernet). The
> default SDU is 2048
> The SDU applies to both sqlnet 2 and net8, so just read the Net8
> administrators manual, on how to set it in listener.ora on the server
> and tnsnames.ora on the client
> 2 You aren't using array fetches, so you get a round trip for every
> individual record.
>
> If you are severely suffering from sql*net problems, most likely 2)
> applies.
> This points to an application not using Oracle features, which is
> regrettably a way too common problem.
>
> Apart from the 2 issues outlined above, you can't 'tune' anything.
>
> Hth
>
>
>
>
> Sybrand Bakker, Senior Oracle DBA
>
> To reply remove -verwijderdit from my e-mail address
Add to the above a couple of other tuning things you can do in your
listener.ora file:
- If your users connect infrequently, sqlnet might need to spawn a new
dispatcher, which goes away when there's no activity for a while. Then
the next user connects and another dispatcher has to be spawned. All of
this spawning can take time. You can specify a minimum number of
dispatchers to be spawned (see PRESPAWN_MAX, PRESPAWN_LIST,
PRESPAWN_DESC in docs). You can also force the connection to use a
"dedicated" dispatcher by putting "USE_DEDICATED_SERVER = on" in your
sqlnet.ora file or adding the "SERVER=DEDICATED" in your tnsnames.ora
file (in case you don't like to share).
- You can shorten the time it takes for a Client to realize it ain't
gonna establish a connection with the CONNECT_TIMEOUT parameter. This
doesn't speed up connections, but it does speed up failure notification
(why wait the default 10 seconds to find out you can't connect). Of
course, you have to make sure that "real" connections can be handled in
the shorter timeframe (don't want to time out someone who's coming in
over a slow bandwidth line).
Received on Wed Nov 13 2002 - 15:57:49 CST