Re: Memory Limit Imposed on Oracle by Windows?

On Apr 22, 9:38 pm, joel garry <joel-ga..._at_home.com> wrote:
> On Apr 20, 2:47 pm, dbaplusp..._at_hotmail.com wrote:
>
>
>
>
>
> > On Apr 20, 3:32 pm, sybra..._at_hccnet.nl wrote:
>
> > > On 19 Apr 2007 08:14:40 -0700, dbaplusp..._at_hotmail.com wrote:
>
> > > >On Apr 19, 5:22 am, "Dereck L. Dietz" <diet..._at_ameritech.net> wrote:
> > > >> > That's my take. The limitations to 4gb are all based on the 32-bit
> > > >> > architecture. 2 to the 32nd power = 4 billion = 4GB. That's the math
> > > >> > side of it; the direct memory addressing limitation of a 64-bit
> > > >> > architecture is... well, a lot more than 4GB.
>
> > > >> > Definitely do your own digging into the specs of 32-bit versus 64-bit
> > > >> > Windows, *and* 32-bit versus 64-bit Oracle. But I think you'll find
> > > >> > that the resourcing under 64-bit is a lot more sizeable, and all the
> > > >> > hokey config jazz you have to do under 32-bit Windows won't be needed.
>
> > > >> Thanks.
>
> > > >IIn 32 bit, limit is 2GB and not 4GB
>
> > > Incorrect. When booted with the correct switches the limit is 3 Gb,
> > > not 2 Gb. And adding just another Gig usually won't help you a damn,
> > > unless you subscribe to the silver bullet religion promoted by DKB.
>
> > > --
> > > Sybrand Bakker
> > > Senior Oracle DBA
>
> > I was referring to plain 32 bit Oracle without doing anything special
> > is OS. On UNIX system, Oracle always refer
> > to limit of 2GB. I was suprised why some people are syaing limit is
> > 4GB.
>
> > I do not subscrbe to any silver bullet, yet open to taking advnatge
> > of 64 bit Oracle and setting large db_buffer cache.
>
> The 2GB limit referred to on unix is file size, not memory size. It
> refers to older unix where that was the maximum file size, and some
> older Oracle utilities had issues dealing with larger files as the
> world moved away from the limitation.
>
> Setting an overly-large cache isn't quite the big deal it used to be
> in earlier Oracle versions, but you still have to have at least a
> latch per buffer, and this can lead to some excess cpu being devoted
> to managing all those latches and buffers. You really should get in
> the habit of figuring out what a proper buffer size is. Tools exist
> (OEM, for example) to make pretty pictures and recommendations, and it
> is worthwhile to learn how to figure it out by the command line (such
> as v$bh and the advisor views) so you can understand what is going
> on. Also, if you make things too large, you risk running into really
> strange effects or bugs that can misdirect you when you look to see
> what is wrong. This can be especially confusing when you have two
> different bottlenecks near each other. For example, if your cpu is
> saturated and your network is not quite saturated, and you fix what is
> saturating the cpu, your total response might get worse as so many
> more processes can run and give their results back to the network.
>
> Why take away memory from user-processes unnecesarily?
>
> jg
> --
> @home.com is bogus.
> "It wasn't until later that we realized that we were being exploited,
> and then you think and you look back and say, 'Boy, I was dumb for
> letting that happen to me.' " - Luis Verduzco, legal immigrant not
> paid overtime by Lakewood Building Systems of Canada
> The carpenters committee used a commercial database used by the
> federal government to discover whether workers were using legitimate
> Social Security numbers. It found that out of 189 workers, 112 had
> false numbers.- Hide quoted text -
>
> - Show quoted text -

Of couuse there are some overheads which you point out, but how much CPU ovethead one is talking vs disk based access. which takes mili seconds . CPU based access takes micro secinds. Do the math for your application. I found that for read intensive databases, having a large buffer cacahe makes all the differemce in the world. I do not find oracle's advisors to be all that good to tune buffer cache.
Those people who advise you to limit memory to 640K or stay away from large buffer cache are plain wrong. Why there are in memory dataase, why Oracle has developed/acquired TEN TIMES database, Why in TPC benchamrks, they use hundreads of GB"s of buffer cache.

Clerly there are performance advantages if one can store database in memory instead of disks. Of course, tune you sql stamenets if you can. Of course, make sure you have the memory and CPU power in the first place. If you have the hardware, you can make good use of it using Oracle's 64 bit architecure. Received on Sun Apr 22 2007 - 21:55:02 CDT