Oracle Processes - Expert Oracle Database Architecture - page 190

It is interesting to note the naming convention used by these processes. The process name starts with ora_ .
It is followed by four characters representing the actual name of the process, which are followed by _ORA12CR1 . As it
happens, my ORACLE_SID (site identifier) is ORA12CR1 . On UNIX/Linux, this makes it very easy to identify the Oracle
background processes and associate them with a particular instance (on Windows, there is no easy way to do this, as
the backgrounds are threads in a larger, single process). What is perhaps most interesting, but not readily apparent
from the preceding code, is that they are all really the same exact binary executable program—there is not a separate
executable for each “program.” Search as hard as you like, but you will not find the ora_pmon_ORA12CR1 binary
executable on disk anywhere. You will not find ora_lgwr_ORA12CR1 or ora_reco_ORA12CR1 . These processes are all
really oracle (that's the name of the binary executable that is run). They just alias themselves upon startup to make
it easier to identify which process is which. This enables a great deal of object code to be efficiently shared on the
UNIX/Linux platform. On Windows, this is not nearly as interesting, as they are just threads within the process, so of
course they are one big binary.
Let's now take a look at the function performed by each major process of interest, starting with the primary
Oracle background processes. For a complete listing of the possible background processes and a short synopsis of the
function they perform, I will direct you to the appendix of the Oracle Database Reference manual available freely on
http://otn.oracle.com/ .

PMON: The Process Monitor
This process is responsible for cleaning up after abnormally terminated connections. For example, if your dedicated
server “fails” or is killed for some reason, PMON is the process responsible for fixing (recovering or undoing work) and
releasing your resources. PMON will initiate the rollback of uncommitted work, release locks, and free SGA resources
allocated to the failed process.
In addition to cleaning up after aborted connections, PMON is responsible for monitoring the other Oracle
background processes and restarting them if necessary (and if possible). If a shared server or a dispatcher fails
(crashes), PMON will step in and restart another one (after cleaning up for the failed process). PMON will watch all of
the Oracle processes and either restart them or terminate the instance as appropriate. For example, it is appropriate
to fail the instance in the event the database log writer process, LGWR , fails. This is a serious error, and the safest
path of action is to terminate the instance immediately and let normal recovery fix the data. (Note that this is a rare
occurrence and should be reported to Oracle Support immediately.)

■ prior to Oracle 12 c , pMON handled the listener registration tasks. Starting with Oracle 12 c , the listener
registration ( LREG ) background process registers instances and services with a listener.

Note

LREG: Listener Registration Process
The LREG process (available starting with Oracle 12 c ) is responsible for registering instances and services with the
Oracle TNS listener. When an instance starts up, the LREG process polls the well-known port address, unless directed
otherwise, to see whether or not a listener is up and running. The well-known/default port used by Oracle is 1521.
Now, what happens if the listener is started on some different port? In this case, the mechanism is the same, except
that the listener address needs to be explicitly specified by the LOCAL_LISTENER parameter setting. You can also use
the REMOTE_LISTENER parameter to instruct LREG to register a service with a remote listener (which is common in
Oracle RAC environments).
If the listener is running when the database instance is started, LREG communicates with the listener and passes
to it relevant parameters, such as the service name and load metrics of the instance. If the listener was not started,
LREG will periodically attempt (typically every 60 seconds) to contact it to register itself. You can also instruct LREG to
immediately attempt to register a service with the listener via the ALTER SYSTEM REGISTER command (which is useful
in high availability environments).