Process-related memory can commonly be divided into three areas: code, data, and stack. Different operating systems will give these different names, and will also have different and additional process-related memory categories. AIX in particular has its own way of categorizing process memory. If you need to know the actual memory a process is consuming, use an operating system-specific command. For example, both Solaris and Linux provide the pmap command to get process-level memory details. I'll quickly describe each of the common categories:

* Code: This is the actual computer program code and is sometimes called text. For Oracle systems, the most critical piece of code is the oracle executable, $ORACLE_HOME/bin/oracle. The oracle executable should always be shared, so there are never multiple copies. When installing earlier versions of Oracle, we had to ensure the oracle executable was shared, or memory would be quickly exhausted.

* 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.