Re: 9205 Problems / SGA_MAX_SIZE
- From: Paul Drake <bdbafh@xxxxxxxxx>
- To: lisa.koivu@xxxxxxxxxxxxxxx
- Date: Tue, 16 Nov 2004 11:21:59 -0500
Lisa,
You should be able to get this to work on either MS W2K Advanced
Server, or W2K3 Server provided that the /3GB switch has been set in
the boot.ini.
What I would have first suspected is that large memory support was
broken in the oracle.exe binary - but that is not the case in 9.2.0.x
(as it was in 8.1.7.3, 8.1.7.4).
We're running with "large memory support" with the 9.2.0.5.3 patchset
in place in production quite nicely.
What you need to pay attention to is the virtual memory that is
allocated, not the "committed" memory.
Download the Pstools suite and track virtual memory allocated with the
utility pslist.exe.
I have some scripts that logged memory usage for the oracle.exe
process(es) and sent them via email daily, when we were hitting our
heads against the 3 10E9 ceiling.
This limit actually kicks in at 2.79 GB of virtual memory, not at 3 GB.
Contact me offline for a copy.
pga_aggregate_target is allocated at runtime, and is not allocated
during instance startup.
each oracle dedicated server process (connection) will still add to
the memory allocated to the oracle.exe process - you may want to run
orastack to reduce this value. Search metalink and the archives of
this list for details.
here is a sample memory configuration.
I am not recommending it, as it is largely duct tape applied to
relieve pressure due to app code that produces a large amount of table
scans - that should eventually be fixed (hence the disproportionately
large keep pool). The app users are happy, so I stopped tuning.
NAME VALUE
------------------------------ ----------
db_keep_cache_size 838860800
db_2k_cache_size 8388608
db_cache_size 805306368
db_recycle_cache_size 16777216
large_pool_size 67108864
shared_pool_size 335544320
java_pool_size 33554432
sga_max_size 2282828404
olap_page_pool_size 8388608
pga_aggregate_target 536870912
this supports 250 simultaneous users, typically 200 of which are
dedicated server connections. we haven't hit a listener error since
about a week after migrating from 8.1.7 to 9.2. I did originally think
that pga_aggregate_target was under sga_max_size, it is not.
the maximum size reported from pslist -m oracle for the counter "VM"
has been 2890612.
it does not take much over 3000000000 to start throwing ORA-12540 errors.
All I can say for now, time for meetings.
hth.
Paul
On Tue, 16 Nov 2004 09:51:25 -0500, Koivu, Lisa
<lisa.koivu@xxxxxxxxxxxxxxx> wrote:
> 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."
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
