Re: bstat and estat

"Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message news:xVzA9.98$FK3.14076239_at_newssvr21.news.prodigy.com...
> 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.

Excuse me????? Dispatchers are not automatically spawned. The number of dispatchers is governed by MTS_DISPATCHERS (just DISPATCHERS in 9i) and the number is fixed. The parameter is dynamically adjustable, but not by the Listener, or by "Sqlnet", whatever that means, since sqlnet is just a protocol. And dispatchers don't just "go away" after a while, either.

Are you perchance confusing this with the shared server processes, which are dynamically spawned and destroyed, depending on the load on the system (and none of which, of course, would make the slightest difference to a connect time, since connections in MTS are always to a dispatcher)?

HJR
>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 - 16:07:07 CST