* Data: This is private process memory (real or virtual). For most Oracle systems, a server process's PGA memory is stored in the data area. Think about it-the PGA is associated with a single server process. It is not meant to be shared, and contains process-specific information like session variables and in-memory sort information. If the Oracle architecture requires some of the PGA memory to be shared, it is moved out of the PGA memory and into the SGA. A resident set of memory, known as the resident set size (RES or RSS) is defined to contain only a process's real nonshared memory. We want any semiactive Oracle process to have its data memory contained within this RSS. The only way to be sure about a process's point-in-time RSS memory is to run an operating system- and vendor-specific command that requires a process ID, such as the pmap command. Commands like ps and even top are notorious for counting shared memory segments and nonresident portions of a process's related memory as the RSS.

* Stack: This is a relatively small (kilobytes usually) portion of an Oracle process's memory. The stack is used to push and pop process variables, and also to hold command-line arguments while they are being processed-that is, popped off the stack.5

Never mention the approach I outline here to your operating system vendor. And it's probably not a good idea to mention this to operating system administrators either, unless they are also Oracle administrators. Also be aware that every operating system uses different words, terms, and algorithms. But this general three-step process provides the guidance you need when understanding if there is a memory bottleneck-excuse me, I mean memory pressure.