Linux – Oracle: 32bit vs. 64bit with respect to memory usage

You already answered the question yourself.

If you are 100% percent positive not to grow beyond 2GB of RAM usage in the current hardware lifecycle you can stay with 32bit, when the time comes to replace your hardware you will have to reconsider anyway.

Given the current hardware market I don't see a real reason not to use 64 bit it will be the safe side in case of unforseen growth, that is true for cache as well as real data size. After all a full migration will take somewhat longer than just taking the box down and adding some RAM.

Drawbacks could be that pointers on a 64bit system use about 30% more memory but that won't really hurt you if you really stay on the small side of memory usage, but on the other hand if you grow you will be able to grow more quickly (at least as long as you can stay on the same hardware box)

Most modern 32-bit CPUs support PAE which allows them to address more than 4GB of physical memory, although a single process can only see 4GB at a time. The kernel will take some of this address space. This Stackoverflow post discusses how PAE works.

Many operating systems (including Linux and MS Windows) offer an API that allows you to manipulate the MMU and page overlays in and out of the virtual address space of a process. This facility allows you to use extra memory for disk buffers. However, as far as I am aware the only DBMS platform with direct support for this is MS SQL Server.

Additional memory will improve your database read performance (which will probably improve your overall throughput), but write performance will be constrained by I/O. If you have a low DB cache hit rate (say less than 95%) then additional memory will probably improve your overall throughput. Otherwise, you may need to look at your disk subsystem (see 1 below).

Assuming you need or can benefit from more memory, the best approach is to move to a 64 bit platform. A modern Xeon or Opteron server will let you install up to 32-144GB depending on the model. This is likely to be your best option.

1. SANs are good for transactional applications. For a high-volume application you should have write-through caching on the DB logs but you may be able to get away with write-back caching on the data volumes. This will get you good log-reader performance as the random data writes can be absorbed by the controller's battery-backed cache and the controller can optimise disk writes to improve throughput.
   
   However, this arrangement has failure modes that can leave the data volumes inconsistent (corrupted). Using write-through on the log volumes mitigates this (as the logs are not vulnerable to these failure modes). Practicaly this limits you to a restore/roll-forward recovery model, so it will only work if you can tolerate a (say) 4-hour recovery window.