Depending on the features of Oracle you are using, other focused processes may be visible. Some are listed here with a brief description of their function.
Note Appendix F (Background Processes) of the Oracle Database Reference manual, available on http://otn.oracle.com/, has a complete listing of the background processes and their functions.
Most of the processes described previously are nonnegotiable—you will have them if you have an Oracle instance running. (ARCn is technically optional but is, in my opinion, mandatory for all production databases!) The following processes are optional and will appear only if you make use of the specific feature. The following processes are unique to a database instance using ASM, as discussed in Chapter 3:
•\ Automatic Storage Management Background (ASMB) process: The ASMB process runs in a database instance that is making use of ASM. It is responsible for communicating to the ASM instance that is managing the storage, providing updated statistics to the ASM instance, and providing a heartbeat to the ASM instance, letting it know that it is still alive and functioning.
•\ ReBALance (RBAL) process: The RBAL process also runs in a database instance that is making use of ASM. It is responsible for processing a rebalance request (a redistribution request) as disks are added/ removed to and from an ASM disk group.
The following processes are found in an Oracle RAC instance. RAC is a configuration of Oracle whereby multiple instances, each running on a separate node (typically a separate physical computer) in a cluster, may mount and open a single database. It gives you the ability to have more than one instance accessing, in a full read-write fashion, a single set of database files. The primary goals of RAC are twofold:
•\ High availability: With Oracle RAC, if one node/computer in the cluster fails due to a software, hardware, or human error, the other nodes may continue to function. The database will be accessible via the other nodes. You might lose some computing power, but you won’t lose access to the database.
•\ Scalability: Instead of buying larger and larger machines to handle an increasing workload (known as vertical scaling), RAC allows you to add resources in the form of more machines in the cluster (known as horizontal scaling). Instead of trading your 4 CPU machine in for one that can grow to 8 or 16 CPUs, RAC gives you the option of adding another relatively inexpensive 4 CPU machine (or more than one).
The following processes are unique to a RAC environment. You will not see them otherwise:
•\ Lock monitor (LMON) process: The LMON process monitors all instances in a cluster to detect the failure of an instance. It then facilitates the recovery of the global locks held by the failed instance. It is also responsible for reconfiguring locks and other resources when instances leave or are added to the cluster (as they fail and come back online or as new instances are added to the cluster in real time).
•\ Lock manager daemon (LMD0) process: The LMD process handles lock manager service requests for the global cache service (keeping the block buffers consistent between instances). It works primarily as a broker sending requests for resources to a queue that is handled by the LMSn processes. The LMD handles global deadlock detection/ resolution and monitors for lock timeouts in the global environment. Also, starting with Oracle 12c, there may be LDDn slave processes spawned by the LMD0 process to assist with the workload.
•\ Lock manager server (LMSn) process: As noted earlier, in a RAC environment, each instance of Oracle is running on a different machine in a cluster, and they all access, in a read-write fashion, the same exact set of database files. To achieve this, the SGA block buffer caches must be kept consistent with respect to each other. This is one of the main goals of the LMSn process. In earlier releases of Oracle Parallel Server (OPS), this was accomplished via a ping. That is, if a node in the cluster needed a read-consistent view of a block that was locked in exclusive mode by another node, the exchange of data was done via a disk flush (the block was pinged). This was a very expensive operation just to read data. Now, with the LMSn, this exchange is done via very fast cache-to-cache exchange over the clusters’ high-speed connection. You may have up to ten LMSn processes per instance.
•\ Lock (LCK0) process: This process is very similar in functionality to the LMD process described earlier, but it handles requests for all global resources other than database block buffers.
The following are common background processes seen with most single instance or RAC instances:
•\ Process spawner (PSP0) process: This process is responsible for spawning (starting/creating) the various background processes. It is the process that creates new processes/threads for the Oracle instance. It does most of its work during instance startup.
•\ Virtual keeper of time (VKTM) process: Implements a consistent, fine- grained clock for the Oracle instance. It is responsible for providing both wall clock time (human readable) and an extremely high- resolution timer (not necessarily built using wall clock time, more of a ticker that increments for very small units of time) used to measure durations and intervals.
•\ Virtual sch(K)eduler for Resource Manager (VKRM) process: Scheduler for the Resource Manager. Manages CPU scheduling and managed processes with active resource plans.
•\ Space management coordinator (SMCO) process: This process is part of the manageability infrastructure. It coordinates the proactive space management features of the database such as the processes that discover space that could be reclaimed and the processes that perform the reclamation.