Oracle programming Art Study Notes (11)-Oracle Process

Oracle instances mainly have three types of processes (in Windows, they are actually threads ):
· Server process: these processes are completed based on customer requests. Server processes include dedicated servers and shared servers: http://www.bkjia.com/database/201110/108827.html

· Background process: these processes are started with the database and used to complete various maintenance tasks, such as writing blocks to disks, maintaining online redo logs, and clearing abnormal and aborted processes.
· Subordinate processes: these processes are similar to background processes, but they must perform some additional work on behalf of background or server processes.

You can use the following statement to query the background processes in the system. In this view, rows of paddr and not 00 are all processes running on the system.
Select paddr, name, description from v $ bgprocess order by paddr desc;

PADDR NAME DESCRIPTION
------------------------------------------------------------------------------
35486804 CJQ0 Job Queue Coordinator
35485CFC SMCO Space Manager Process
354851F4 VKRM Virtual sKeduler for Resource Manager
354830DC qmnc aq Coordinator
354825D4 ARC3 Archival Process 3
35481ACC ARC2 Archival Process 2
35480FC4 ARC1 Archival Process 1
3547F9B4 ARC0 Archival Process 0
3547D89C MMNL Manageability Monitor Process 2
3547CD94 MMON Manageability Monitor Process
3547C28C RECO distributed recovery
3547B784 SMON System Monitor Process
3547AC7C CKPT checkpoint
3547A174 LGWR Redo etc.
3547966C DBW0 db writer process 0
35478B64 MMAN Memory Manager
3547805C DIA0 diagnosibility process 0
35477554 PSP0 process spawner 0
35476A4C DBRM DataBase Resource Manager
35475F44 DIAG diagnosibility process
3547543C GEN0 generic0
35474934 VKTM Virtual Keeper of TiMe process
35473E2C PMON process cleanup
00 RSMN Remote Slave Monitor
...
00 XDWK cell automation worker actions

Row 295 has been selected.

Background processes include some essential processes and some optional processes.

The following are some important background processes.
1.PMON: Process Monitor(Process Monitor)
· Responsible for cleaning the connection after an exception is aborted
· Monitors other background processes and restarts these background processes if necessary.
· Register an Oracle instance with the Oracle TNS Listener

2.SMON: System Monitor(System Monitor)
· Clear temporary space
· Merge free space
If you are using a dictionary-managed tablespace, SMON is responsible for obtaining consecutive idle segments in the tablespace and merging them into a larger idle segment.
· Recover the transaction for the original unavailable files: This is similar to the role of SMON when the database is started
· Restore instances of failed nodes in RAC
· Clear OBJ $
· Shrink rollback segments
· Offline rollback segments
Offline rollback segments of an active transaction. In this case, the rollback segments are not actually offline, but are marked as "going offline ". In the background, SMON regularly tries to set it offline until it succeeds.
· Many other maintenance work.
SMON will wake up regularly or be awakened by other background processes to perform these maintenance tasks.

3.RECO: distributed database recovery(Distributed Database Recovery)

4.CKPT: Checkpoint Process(Checkpoint Process)
Creating a checkpoint is to write dirty blocks (modified blocks) from the block buffer cache to the disk. When Oracle switches the log file, a checkpoint is marked (created. Oracle needs to push the checkpoint. After it advances the checkpoint, it no longer needs the online redo log files it just filled up.
The checkpoint process does not really establish a checkpoint. Creating a checkpoint is mainly a task of DBWn. CKPT is only the first part of the file to update the data file, to assist in creating a Checkpoint Process (DBWn)

5.DBWn: Database block writer(Database Block Writer)
The background process that writes dirty blocks to the disk. DBWn writes dirty blocks in the buffer cache, which is usually used to free up more space in the cache (releasing the buffer to read other data ), or to promote the checkpoint (to forward the location in the online redo log file, if a failure occurs, Oracle will read from this location to restore the instance ).
You can configure multiple DBWn to make full use of the hardware system capabilities.
If possible, DBWn writes the block to the disk using asynchronous I/O. When asynchronous I/O is used, DBWn collects a batch of blocks to be written, submits them to the operating system, returns them immediately, and collects the next batch of blocks to be written. When the operating system completes the write operation, it asynchronously notifies DBWn.

DBWn writes blocks to all disks, that is, distributed across disks. That is to say, DBWn performs a large number of distributed writes );
LGWR writes a large number of sequential writes to the redo log ).
Theoretically, if Oracle has physically written the modified block to the disk during the submission, you can skip writing online redo log files. However, during the submission process, only LGWR will write the redo information of each transaction to the online redo log, and DBWn will refresh the database block in the background and output it to the disk.
The reason for this is that distributed writing is much slower than sequential writing. DBWn completes its tasks in the background (very slow), while LGWR completes its tasks (this task is relatively fast) after the user submits the tasks, it can achieve better overall performance. Technically speaking, this will allow Oracle to execute more unnecessary I/O (write logs and write data files ).

6.LGWR: redo log writer(Log Writer)
The LGWR process is responsible for refresh and output the content in the SGA to the disk.
The duration of Data staying in the redo buffer is not too long. In fact, LGWR will start to refresh the partition to the disk (flush) when one of the following circumstances occurs ):
· Once every 3 seconds
· Whenever a request is submitted
· Requires LGWR to switch log files
· The redo buffer is 1/3 full or contains 1 MB of cached redo log data
For these reasons, if the size of the redo buffer exceeds several MB, it usually makes no sense to the system. If it is a large system with a large number of concurrent transactions, it may be advantageous to the large redo log buffer, because when LGWR outputs a part of the log buffer to the disk, other sessions may fill in new data in the buffer. Generally, if a transaction runs for a long time, a large number of redo logs are generated. Using a larger log buffer is the most beneficial to this transaction.

7.ARCn: archiving process(Archive Process)
The task of the ARCn process is to copy LGWR to another location when it fills up online redo log files.
Online redo logs are used to "correct" data files when a power failure (instance termination) occurs, archive redo logs are used to back up and "correct" data files when data is deleted due to a hard disk failure or misoperation.

If the following warning message is displayed in the server warning log file (alert _ <ORACLE_SID>. log:
Thread 1 cannot allocate new log, sequence 1466
Checkpoint not complete
Current log #3 seq #1465 mem #0:/home/ora10g/oradata/ora10g/redo03.log
The warning message may also indicate Archival required instead of Checkpoint not complete, but the results are almost the same.
If the database tries to reuse an online redo log file, this warning message is output in the following cases.
· DBWn has not completed the checkpointing of the data protected by the redo log)
· ARCn has not copied the redo log file to the archiving target.
For end users, the database actually stops at this time point. DBWn or ARCn will get the highest priority to refresh the output disk of the redo block.

Solution:
· Optimize DBWR or use multiple DBWR processes. Check the I/O generated by the system and check whether a disk (or a group of disks) is "too hot". data needs to be distributed accordingly. This recommendation also applies to ARCn.
· Add more online redo log files or create larger redo log files. This gives DBWn sufficient active space to establish checkpoints, and also gives ARCn enough time to archive logs.
· More frequent and continuous checkpoints. You can modify parameters such as FAST_START_MTTR_TARGET, LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT to force DBWn to refresh dirty output blocks more frequently. The disadvantage is that the buffer cache cannot be fully used.