Re: How To Improve Connection Times?

Also, just to respond to this possibility as well, our pre_page_sga parameter is set to false, and lock_sga is set to false as well. In production, our database is expected to be relatively small. We expect it to grow to around 750MB to 1.5GB. The memory settings are as follows:

Shared Pool: 208MB
Buffer Cache: 512MB
Large Pool: 10MB
Java Pool: 64MB (doesn't really matter since we aren't using Java Stored Procedures etc.)

Total SGA is 282MB.

Based on what has been said, it it possible that our memory parameters are set too large?

Khalid.

"Mladen Gogala" <mgogala_at_adelphia.net> wrote in message news:acol73$r854c$1_at_ID-82084.news.dfncis.de...
> On Sat, 25 May 2002 13:02:43 -0400, Sybrand Bakker wrote:
>
> > This must be a network and/or a sqlnet configuration issue. You don't
> > provide any details on that. We need to have listener.ora, tnsnames.ora
> > and sqlnet.ora Also we need to know whether the client can ping the
> > server in a reasonable amount of time, what the traceroute results are
> > between the systems, and whether a firewall is involved.
>
> Here I have to respectfully disagree. It seldomly an Oracle*Net issue,
> it's usually a network problem. In my experience, long connection times
> have usually been related to memory problems, because the kernel has to
> page the ora_s0000n_$SID process in the memory. If there is an enormous
> SGA, there may be a delay with paging in the whole SGA. In that case,
> pre_page_sga parameter mightt help, as well as "lock_sga".
> If it was my machine, I'd first do a ping to see what times do I get and
> if it turs out OK (~5ms or less), then look at gtop and see whether there
> is excessive paging. You can also use sar or iostat from sysstat package.
> for that purpose. If not, turn the tracing in the listener (level=ADMIN)
> and see whether you can figure out what is it waiting for.
> --
> Mladen Gogala
> Za Feral Spremni!
Received on Sun May 26 2002 - 10:07:06 CDT