6. ARCn
ARCn is background process spawn in ARCHIVELOG DB mode, where n ranges from 0-9
ARCn copies online redo log files to a designated storage device after
- A log switch has occurred
- alter database archivelog current; is executed
- No more online redo log file is available & to be overwritten
An Oracle instance can have up to 10 ARCn processes (ARC0 to ARC9). The LGWR process starts a new ARCn process whenever the current number of ARCn processes is insufficient to handle the workload. The alert file keeps a record of when LGWR starts a new ARCn process.
Dynamic LOG_ARCHIVE_MAX_PROCESSES can be set to max 10.
Starting from one ARCn process oracle automatically starts up more ARCn processes till LOG_ARCHIVE_MAX_PROCESSES when the database workload requires more.
Arch can be stopped and started dynamically with alter system archive log stop|start or using below commands (deprecated 10g onwards)
archive log list
archive log stop
archive log start
archive log next
archive log all
archive log n
Query v$archive_processes to find out how many arch processes are running
7. RECO
In a distributed database, the recoverer process (RECO) automatically resolves failures in distributed transactions.
The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction. When RECO re-establishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from each database's pending transaction table any rows that correspond to the resolved transactions
8. RVWR
The Recovery Writer process is responsible for writing to the flashback logs in the flash recovery area.
These logs are required to restore the database to a previous point in time by using the "flashback" option for Oracle databases (Oracle 10g and later)
MMON is a Memory Monitor background process (10g onwards)
MMON gathers memory statistics (snapshots) stores this information in the AWR (automatic workload repository).
MMON is also responsible for issuing alerts for metrics that exceed their thresholds.
Statistics gathered by MMON snaps are used by ADDM (Automatic Database Diagnostic Monitor) to generate database workload & performance report helpful for tuning
MMON computes short duration metrics every 15 seconds and long duration metrics every 60 seconds
10. MMNL
MMNL is a Memory Monitor Light background process that assists the MMON process.
This process will flush the ASH buffer to AWR tables when the buffer is full or a snapshot is taken.
11. MMAN
MMAN is Memory Manager Background process (10g onwards)
MMAN manages ASSM (Automatic Shared Memory management) by dynamically resizing SGA dynamic components
MMAN is spawn whenever SGA_TARGET parameter is set to non-zero value i.e. when ASSM is enabled
It dynamically resizes Database buffer, Shared Pool, Large Pool, Java Pool memory components based on workload
v$sga_dynamic_components view shows memory components & their dynamic values
12. CJQn
CJQn is a Job Queue background Process.
Oracle Database uses job queue processes to run user jobs, often in batch mode.
A job is a user-defined task scheduled to run one or more times. For example, you can use a job queue to schedule a long-running update in the background. Given a start date and a time interval, the job queue processes attempt to run the job at the next occurrence of the interval.
Oracle Database manages job queue processes dynamically, thereby enabling job queue clients to use more job queue processes when required. The database releases resources used by the new processes when they are idle.
Dynamic job queue processes can run a large number of jobs concurrently at a given interval. The sequence of events is as follows:
The job coordinator process (CJQ0) is automatically started and stopped as needed by Oracle Scheduler.
The coordinator process periodically selects jobs that need to be run from the system JOB$ table.
New jobs selected are ordered by time.
The coordinator process dynamically spawns job queue slave processes (Jnnn) to run the jobs.
The job queue process runs one of the jobs that was selected by the CJQ0 process for execution. Each job queue process runs one job at a time to completion.
After the process finishes execution of a single job, it polls for more jobs. If no jobs are scheduled for execution, then it enters a sleep state, from which it wakes up at periodic intervals and polls for more jobs. If the process does not find any new jobs, then it terminates after a preset interval.
The initialization parameter JOB_QUEUE_PROCESSES represents the maximum number of job queue processes that can concurrently run on an instance. However, clients should not assume that all job queue processes are available for job execution.
The coordinator process is not started if the initialization parameter JOB_QUEUE_PROCESSES is set to 0.
No comments:
Post a Comment