Oracle architecture-Oracle background process

As we mentioned earlier, Oracle instances consist of a memory structure and a group of background processes. The important background processes of Oracle include:

· SMON
· Pmon
· Dbwr
· Lgwr
· Arch
· Ckpt

Next we will introduce the functions of each process one by one.

I. SMON

SMON (system monitor)-a system monitoring process that restores an instance when the instance is started and cleans temporary segments that are no longer in use.

The SMON process must complete all system-level tasks. Pmon is interested in a single process. Unlike SMON, pmon is based on the system level. It is a database "Garbage Collector ". SMON does the following work:
· Clear temporary space
· Merge free space
· Resume the transaction for the original unavailable files
· Restore instances of failed nodes in RAC
· Clear OBJ $
· Shrink rollback segments
· Offline rollback segments

Ii. pmon

The pmon background process clears the processes of failed users and releases the resources that the users are currently using.Pmon is responsible for releasing the lock and making it available to other users. Like SMON, pmon periodically wakes up and checks whether it needs to be used.

Pmon is responsible for cleaning up and releasing resources and rolling back uncommitted transactions after a connection is aborted with an exception.
Pmon is also responsible for monitoring other Oracle background processes and restarting these background processes if necessary.
Pmon also registers the instance with the Oracle TNS Listener.

Iii. dbwr

Dbwr (Database writing program) background processes are responsible for managing the content in the data block cache and dictionary cache. It writes the modified block from SGA to the data file in batches.

Although each database instance only has one SMON and one pmon process running, you can have multiple dbwr processes at the same time depending on the platform and operating system.

Dbwn writes dirty blocks in the buffer cache, which is usually used to free up more space in the cache (releasing the cache to read other data ), or to promote the checkpoint (forward the location in the online redo log file. If a failure occurs, Oracle will independently recover the instance from this location .)

We can see that the performance of dbwn may be very important. If the writing speed of the block is not fast enough and the buffer cannot be quickly released, the number of waits and the waiting time of the free buffer waits and write complete waits start to increase.Multiple dbwn can be configured. In fact, up to 20 dbwn can be configured.

In the best case, dbwn writes blocks to the disk using asynchronous I/O. When asynchronous I/O is used, dbwn collects a batch of blocks to be written and submits them to the operating system. Dbwn does not wait for the operating system to actually write the block; instead, it returns immediately and collects the next batch of blocks to be written. When the operating system completes the write operation, it asynchronously notifies dbwn that the write operation has been completed. In this way, dwbn can work faster than all operations in serial mode.

According to the definition, the block writer process writes the block to all disks, that is, the block is distributed to each disk. That is,Dbwn will do a lot of distributed writing. When you perform an update, you can modify the index blocks stored in multiple locations, and modify the data blocks randomly distributed to the disk. On the other hand,Lgwr completes a large number of sequential writes to the redo log.This is an important difference.

Distributed writing is much slower than sequential writing. By caching dirty blocks in SGA and completing large-scale sequential writing by the lgwr process, the performance can be improved. Dbwn completes its tasks in the background (very slow), while lgwr completes its tasks while the user waits (this task is relatively fast), so that we can get better overall performance.

Iv. lgwr

The lgwr background process writes the online redo log buffer content to the online redo log file.

Lgwr batch writes log entries to online redo log files. Redo log buffer entries always contain the latest database statusThis is because the dbwr process can wait until it writes the modified data blocks in the data block buffer to the data file.

Lgwr is a process in which the content written by log files is redone online and directly read from the redo log buffer when the database is operating normally. Contrary to dbwr's random access to data files, online redo log files are written in sequence. If the online redo log file is an image file, lgwr also writes content to the image log file.

For Oracle 8, multiple lgwr I/O slave processes can be created to improve the Write Performance of online redo log files. the lgwr _ io_sl AVEs parameter of the ora file is determined. In Oracle 8 I, this parameter is no longer available, and lgwr I/O is derived from the process's dbwr _ IO _ slaves setting value.

If one of the following conditions is met, the lgwr process will refresh and output the redo log buffer content to the disk:
· Refresh the output every 3 seconds
· When any transaction sends a commit
· Redo log buffer is 1/3 full or contains 1 MB of buffered data

For these reasons, the allocation of a large redo log buffer is not practical, and Oracle cannot use this buffer completely.

V. Arch

The lgwr background process cyclically writes data to online redo log files. When the first log file is filled, the data is written to the second log file. After the second log file is filled, write the log file to the third log file. Once the last redo log file is filled up, lgwr begins to overwrite the content of the first redo log file.

When Oracle runs in archivelog (archive log) mode, the database backs up the log file before it begins to overwrite the redo log file.These archived redo log files are usually written to a disk device. It can also be directly written into tape devices, but this often increases the operator's labor intensity.

This archiving function is completed by the arch (archive process) background process. databases that use this performance will encounter redo log disk conflicts when processing big data transactions, this is because arch is preparing to read another log file when lgwr is writing a redo log file. If the target disk of the archived log is full, the database will be locked. In this case, arch is frozen and lgw r writing is prohibited. Further transaction processing is prohibited in the database. This situation continues until the space of the archived redo log file is cleared.

Online redo logs (lgwr) are used to "correct" data files when a power failure (instance suspension) occurs, while archived redo logs are different, it is used to "correct" data files in the case of a hard disk failure.

Arch usually copies online redo log files to at least two locations (redundancy is the key to not losing data !). These locations may be disks on the local machine, or, more specifically, at least one disk on the other to cope with catastrophic failures.

Vi. ckpt

Ckpt (Checkpoint Process) is used to reduce the time required for instance recovery. The checkpoint causes dbwr to write all modified data blocks after the previous checkpoint to the data file, and update the data file header and control file to record the checkpoint.

When an online redo log file is filled up, the checkpoint process automatically appears. You can use the log_checkpoint_interval parameter in the init. ora file of the database instance to set a frequent checkpoint.

Note:
The checkpoint process does not really create a checkpoint, as its name implies. Creating a checkpoint is mainly a task of dbwn. Ckpt is only the first part of the file to update the data file to help build the process (dbwn) of the check point ).

Note: All content in this article are taken from csdn netizen Fang yousong's technical blog (the author's blog address: http://blog.csdn.net/truexf)
And Tom Kyte's Oracle9i & 10g programming art press