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
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 (See ORA-12540.ora-code.com) 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@(protected) > 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 (See ORA-12500.ora-code.com), ORA-12540 (See ORA-12540.ora-code.com), etc. refused connections with 'internal limit
> exceeded ', 'exec error ' in the log files=20
> ORA-4030 (See ORA-4030.ora-code.com) '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
>
--
http://www.freelists.org/webpage/oracle-l
