9205 Problems / SGA_MAX_SIZE

From: Koivu, Lisa <Lisa.Koivu_at_Cendant-TRG.com>
Date: Tue, 16 Nov 2004 09:51:25 -0500
Message-ID: <3B16FC3F45D57A498EF8E25958909FED134F49@webmail.ffci.com>

Hi all,=20

Am I the only one having major problems with 9205? Is anyone else seeing the following behavior? I'm on Windows 2003 unfortunately

ORA-12500, ORA-12540, etc. refused connections with 'internal limit exceeded', 'exec error' in the log files=20 ORA-4030's=20
Instance crash with no trace as to why
Listeners crashing

I'm scared out of my pants because this app will be adding hundreds of users in two weeks. We can't even support what we have now. =20

I'm blaming the patchset because I worked on a 9204 database that accepted 150+ connections being spawned in the same second without errors.

Maybe part of this behavior is due to my possible misunderstanding of sga_max_size and pga_aggregate_target. Can someone please tell me if I've got this right, I need a reality check.

Sga_max_size is the total amount of memory that the buffer cache, large pool, shared pool, etc. can grow to, allowing dynamic resizing.

Pga_aggregate_target is the guideline for the amount of memory granted to user connections. This is *above* sga_max_size. =20

So, on Windows, since I am limited to 2gb (and /3gb switch is a nightmare) my sga_max_size + pga_aggregate_target should be below 2gb, with some wiggle room since the db will just go on trucking by the figure set in pga_aggregate_target.=20

Any suggestions, comments, etc. are appreciated. I'm going to open up a TAR but it's near impossible to dig through all the trace files to get the error(s) necessary to point out my problem. Guess I better get out my f'ing shovel...

Thanks all

Lisa Koivu
The poor chump that ends up doing everyone else's work / Database Monkey Mama
Orlando, FL, USA

"The sender believes that this E-Mail and any attachments were free of an=
y virus, worm, Trojan horse, and/or malicious code when sent. This messag=
e and its attachments could have been infected during transmission.  By r=
eading the message and opening any attachments, the recipient accepts ful=
l responsibility for taking proactive and remedial action about viruses a=
nd other defects. The sender's business entity is not liable for any loss=

=20or damage arising in any way from this message or its attachments."

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Nov 16 2004 - 09:05:27 CST