Re: Memory Limit Imposed on Oracle by Windows?



On Apr 22, 9:38 pm, joel garry <joel-ga...@xxxxxxxx> wrote:
On Apr 20, 2:47 pm, dbaplusp...@xxxxxxxxxxx wrote:





On Apr 20, 3:32 pm, sybra...@xxxxxxxxx wrote:

On 19 Apr 2007 08:14:40 -0700, dbaplusp...@xxxxxxxxxxx wrote:

On Apr 19, 5:22 am, "Dereck L. Dietz" <diet...@xxxxxxxxxxxxx> 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.


.



Relevant Pages

  • Re: read vs. mmap (or io vs. page faults)
    ... not fit in main memory, and there are overheads related to the heuristics ... But because the CPU is underutilized, ... reasonably sized user buffer). ... You have to measure the actual overhead to see what the actual cost is. ...
    (freebsd-questions)
  • Re: Real World Significant Sources of (what we usually call) Latency
    ... faster CPU, more RAM, and tweaking actually help to reduce latency? ... you can reduce your buffer size to half." ... memory will have little additional benefit. ...
    (rec.audio.pro)
  • Re: Model I with DIN Expansion Interface
    ... Both the CPU and Expansion Interface ... and a ?mem should show the additional EI memory. ... If the response is not sensible it assumes there is no floppy interface and continues to boot ROM BASIC. ... If the EI is modified for the buffer mod a straight cable must not be used. ...
    (comp.sys.tandy)
  • Re: [RFC PATCH] introduce sys_membarrier(): process-wide memory barrier (v5)
    ... <switch back to user-space> ... memory access before membarrier ... mm_cpumask includes CPU 1 ... current = next (buffer flush) ...
    (Linux-Kernel)
  • Re: Does my server have enough memory
    ... What should I watch to determine if we're short on memory ... have not taken the system performance analysis or tuning courses with ... My guess is that your Oracle instances are using up all of the ... CPU to have to wait for the I/O to clear up. ...
    (comp.unix.aix)