A program instruction on an Intel 386 or later CPU can address up to 4GB of memory, using its full 32 bits. This is normally far more than the RAM of the machine. (The 32nd exponent of 2 is exactly 4,294,967,296, or 4 GB. 32 binary digits allow the representation of 4,294,967,296 numbers — counting 0.) So the hardware provides for programs to operate in terms of as much as they wish of this full 4GB space as Virtual Memory, those parts of the program and data which are currently active being loaded into Physical Random Access Memory (RAM). The processor itself then translates (‘maps’) the virtual addresses from an instruction into the correct physical equivalents, doing this on the fly as the instruction is executed. The processor manages the mapping in terms of pages of 4 Kilobytes each - a size that has implications for managing virtual memory by the system.
Virtual Memory in UNIX:
Virtual memory is an internal “trick” that relies on the fact that not every executing task is always referencing it’s RAM memory region. Since all RAM regions are not constantly in-use, UNIX has developed a paging algorithm that move RAM memory pages to the swap disk when it appears that they will not be needed in the immediate future.
As memory regions are created, UNIX will not refuse a new task whose RAM requests exceeds the amount of RAM. Rather, UNIX will page out the least recently referenced RAM memory page to the swap disk to make room for the incoming request. When the physical limit of the RAM is exceeded UNIX can wipe-out RAM regions because they have already been written to the swap disk.
When the RAM region is been removed to swap, any subsequent references by the originating program require UNIX copy page in the RAM region to make the memory accessible. UNIX page in operations involve disk I/O and are a source of slow performance. Hence, avoiding UNIX page in operations is an important concern for the Oracle DBA.