오라클 프로세스 관련 설명
원본 링크(Oracle Proccesses) : http://www.cuddletech.com/articles/oracle/node76.html원본 링크(Background Processes 11g) : http://aravindbabugidijala.wordpress.com/2011/02/23/background-processes-11g/
Oracle Proccesses
Oracle is a big beast, to say the least. It’s composed of a variety of diffrent componants. Each database is run as an instance. A database server can run multiple instances at a time. Each instance is made up of diffrent componants. We can see these as seperate procceses at the system level.
bash-2.05$ ps -ef | grep -i ben oracle 342 1 0 13:35:59 ? 0:00 ora_pmon_BEN oracle 344 1 0 13:35:59 ? 0:00 ora_mman_BEN oracle 346 1 0 13:35:59 ? 0:01 ora_dbw0_BEN oracle 348 1 0 13:36:00 ? 0:01 ora_lgwr_BEN oracle 350 1 0 13:36:00 ? 0:00 ora_ckpt_BEN oracle 352 1 0 13:36:00 ? 0:04 ora_smon_BEN oracle 354 1 0 13:36:00 ? 0:00 ora_reco_BEN oracle 356 1 0 13:36:00 ? 0:02 ora_cjq0_BEN oracle 358 1 0 13:36:00 ? 0:00 ora_d000_BEN oracle 360 1 0 13:36:01 ? 0:00 ora_s000_BEN oracle 514 329 0 15:22:24 pts/2 0:00 grep -i ben oracle 366 1 0 13:36:22 ? 0:00 ora_qmnc_BEN oracle 368 1 0 13:36:28 ? 0:04 ora_mmon_BEN oracle 370 1 0 13:36:28 ? 0:01 ora_mmnl_BEN oracle 372 1 1 13:36:31 ? 0:15 ora_j000_BEN oracle 512 1 0 15:19:33 ? 0:00 ora_q000_BEN
All these procceses make up the instance of the database BEN running on this machine. Lets break it down.
- <dt>**pmon**</dt><dd>The *process monitor* performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. PMON also checks on the dispatcher processes (described later in this table) and server processes and restarts them if they have failed.

</dd><dt>**mman**</dt><dd>Used for internal database tasks.

</dd><dt>**dbw0**</dt><dd>The *database writer* writes modified blocks from the database buffer cache to the datafiles. Oracle Database allows a maximum of 20 database writer processes (DBW0-DBW9 and DBWa-DBWj). The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. The database selects an appropriate default setting for this initialization parameter (or might adjust a user specified setting) based upon the number of CPUs and the number of processor groups.

</dd><dt>**lgwr**</dt><dd>The *log writer* process writes redo log entries to disk. Redo log entries are generated in the redo log buffer of the system global area (SGA), and LGWR writes the redo log entries sequentially into a redo log file. If the database has a multiplexed redo log, LGWR writes the redo log entries to a group of redo log files.

</dd><dt>**ckpt**</dt><dd>At specific times, all modified database buffers in the system global area are written to the datafiles by DBWn. This event is called a *checkpoint*. The checkpoint process is responsible for signalling DBWn at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.

</dd><dt>**smon**</dt><dd>The *system monitor* performs recovery when a failed instance starts up again. In a Real Application Clusters database, the SMON process of one instance can perform instance recovery for other instances that have failed. SMON also cleans up temporary segments that are no longer in use and recovers dead transactions skipped during system failure and instance recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online.

</dd><dt>**reco**</dt><dd>The *recoverer* process is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases and automatically complete the commit or rollback of the local portion of any pending distributed transactions.

</dd><dt>**cjq0**</dt><dd>Job queue processes are used for batch processing. The CJQ0 process dynamically spawns job queue slave processes (J000...J999) to run the jobs.

</dd><dt>**d000**</dt><dd>*Dispatchers* are optional background processes, present only when the shared server configuration is used.

</dd><dt>**s000**</dt><dd>Dunno.

</dd><dt>**qmnc**</dt><dd>A *queue monitor* process which monitors the message queues. Used by Oracle Streams Advanced Queuing.

</dd><dt>**mmon**</dt><dd>Performs various manageability-related background tasks.

</dd><dt>**mmnl**</dt><dd>Performs frequent and light-weight manageability-related tasks, such as session history capture and metrics computation.

</dd><dt>**j000**</dt><dd>A job queue slave. (See cjq0)

</dd><dt>**q000**</dt><dd id="aeaoofnhgocdbnbeljkmbjdmhbcokfdb-mousedown">Dunno.</dd>
Background Processes 11g
11g has come up with some good new background processes. Which we will discuss in this session
ABMR – auto block media recovery background process – Filters duplicate BMR requests and performs flood control. When a request of block media recovery comes to ABMR, then ABMR spawns BMRn slave processes to perform block media recovery dynamically. repairing of corrupted blocks on primary site by obtaining the same block from standby site and the vice versa on active standby from primary site. Get terminated when idle for long time along with slave processes. It is BMRn slave processes which actually fetches blocks from real time standby database.
DBRM – database resource manager background process – Sets resource plans if resource plan is enabled otherwise this process is idle. It sets resource plans and performs various operations related to enforcement of those resource plans.
DIA0..9 – diagnostic process 0 to 9 background processes – this process is responsible for dead lock resolution and hand detection. this process triggers another background process called as DIAG to perform diagnostic tasks such as performing diagnostic dumps. DIAG is also responsible for execution of global oradebug commands. DIAG also performs diagnostic dumps as requested by other processes or during instance termination.
EMNC - event monitor coordinator background process – This process coordinates event management and notification activity including streams event notification, continuous query notification, Fast application notifications. EMNC spaws EMON slave processes E000…4. These processes work on the system notifications in parallel, offering a capability to process a larger volume of notifications, a faster response time, and a lower shared memory use for staging notifications.
FBDA - flash back data archiver background process – When a table data get commited by transactions the pre image of the effected rows of table from undo tablespace is stored by this process into flashback data archives so that historical pre images of data for a long term can be querried. this process also maintains metadata of current rows and tracks how much data has been updated. this process also responsible for space, partitioning of tablespaces and retention of flashback data archives. this process keeps track of how far archiving of tracked transactions has progressed.
GEN0 – general task execution background process – the main goal of this process is to offload those processes which potentially blocking other processes. these required tasks are for sql and DML. Other processes request GEN0 to perform those tasks which can safely be run at background and that other process can concentrate on its task and GEN0 notifies back once given task is done.
Innn - Disk and Tape I/O Slave processes background process – these processes are spawned by other background processes such as DBWR, LGWR or an RMAN backup session. I/O slave process can be configured on platforms where asynchronous I/O support is not available. These slaves are started by setting the corresponding slave enable parameter in the server parameter file. The I/O slaves simulate the asynchronous I/O behavior when the underlying platform does not have native support for asynchronous I/O.
Lnnn - Pooled Server Background processes - handles client requests in Database Resident connection pooling. In Database Resident Connection Pooling, clients connect to a connection broker process. When a connection becomes active, the connection broker hands off the connection to a compatible pooled server process. The pooled server process performs network communication directly on the client connection and processes requests until the client releases the server. After being released, the connection is returned to the broker for monitoring, leaving the server free to handle other clients.
Nnnn - Connection broker background processes – monitors idle connections and hands off active connections in database resident connection pooling. In Database Resident Connection Pooling, clients connect to a connection broker process. When a connection becomes active, the connection broker hands off the connection to a compatible pooled server process. The pooled server process performs network communication directly on the client connection and processes requests until the client releases the server. After being released, the connection is returned to the broker for monitoring, leaving the server free to handle other clients.
RCBG - result cache background process – This process is used for handling invalidation and other messages generated by server processes attached to other instances in Oracle RAC
RPnn - Replay processing/Capture processing background process -
RPnn are worker processes spawned by calling<code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir,parallel_level). Each worker process is assigned a set of workload capture files to process.
Worker processes execute in parallel without needing to communicate with each other. After each process is finished processing its assigned files, it exits and informs its parent process.
The number of worker processes is controlled by the <code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">parallel_level parameter of<code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE. By default, <code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">parallel_level is null. Then, the number of worker processes is computed as follows:
When <code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">parallel_level is <code style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; vertical-align: baseline; font-family: Monaco, Consolas, 'Andale Mono', 'DejaVu Sans Mono', monospace; font-size: 13px; background-position: initial initial; background-repeat: initial initial; ">1, no worker processes are spawned.
SMCO - space management coordinator background process – this process spawns Wnnn slave processes to do space management tasks like space reclamation and space allocation.
VKRM - Virtual scheduler for resource manager background process – VKRM manages the CPU scheduling for all managed Oracle processes. The process schedules managed processes in accordance with an active resource plan.
VKTM - Virtual keeper of time process - VKTM acts as a time publisher for an Oracle instance. VKTM publishes two sets of time: a wall clock time using a seconds interval and a higher resolution time (which is not wall clock time) for interval measurements. The VKTM timer service centralizes time tracking and offloads multiple timer calls from other clients.