Re: How To Improve Connection Times?

Java pool is outrageous when not using Java (decrease it to 1M) Buffer cache is outrageous for this size of database. If you think you really need this to guarantee performance, I'd better start tuning my statements *now*.
Most likely you have assigned so much resources to Oracle you are *causing* excessive paging.

Also your listener.ora and tnsnames.ora don't match (named host vs. localhost) and your tnsnames.ora will work on the server only. That, however, is the only place where you don't need tcp/ip and want to use IPC or bequeath instead.

Regards

--
Sybrand Bakker
Senior Oracle DBA

to reply remove '-verwijderdit' from my e-mail address

"Khalid Eidoo" <someone_at_rogers.com> wrote in message
news:uS6I8.118135$t8_.101893_at_news01.bloor.is.net.cable.rogers.com...


> 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!

>

>