Background Processes

Database Writer (Mandatory Process)

Writing changed database blocks from the buffer cache to the disc in Oracle Database is done by the Database Writer (DBW) process. To make sure that the database updates are saved to a disc, it runs continually in the background. By lowering the likelihood of data loss in the event of any breakdown, the DBW procedure aids in maintaining the consistency and durability of the database. To achieve effective database operations, the DBW process must be monitored and tuned for maximum performance.


Log Writer (Mandatory Process)

The redo log buffer is written to disc by the Log Writer (LGWR) process in Oracle Database. The database updates are kept in the redo log buffer until the LGWR procedure writes them to the disc. The redo log file, which may be utilized for recovery in the event of any failure, is created as a result of the LGWR process, which makes sure that all database changes are recorded. The integrity and consistency of the database are crucially maintained by the LGWR procedure. To maintain effective database operations, it is crucial to monitor the LGWR process and modify it for maximum performance.


Checkpoint (Mandatory Process)

All dirty buffers in the buffer cache must be written to the data files by the Checkpoint procedure in Oracle Database. A checkpoint serves as a point of synchronization between the data files on the disc and the database buffers in memory. The control file and datafile headers are updated by the checkpoint procedure to reflect the most recent checkpoint made. To balance the I/O load on the system and maintain effective database operations, the checkpoint frequency must be tuned. Database performance may suffer if frequent checkpoints are skipped and recovery takes longer.


SMON (Mandatory Process)

In Oracle Database, the System Monitor (SMON) process is in charge of temporary segment cleanup, free space coalescence, and instance recovery. Applying redo logs and rolling back uncommitted transactions, SMON handles the recovery procedure in the event that the database instance breaks. In order to boost database speed, it locates fragmented free space and consolidates it. SMON also clears out temporary segments that users have established in order to stop the buildup of extra data. The SMON procedure is vital for maintaining optimal database performance as well as the consistency and availability of the database.


PMON (Mandatory Process)

For monitoring and managing failed processes, releasing related memory and locks, and clearing away resources required by the processes, Oracle Database's Process Monitor (PMON) is in charge. PMON monitors for failing processes on a regular basis and tries to restart them. If a failed process cannot be restarted, it is marked as terminated and all resources connected to it are cleaned away. To avoid potential resource contention problems, PMON additionally makes sure that any shared memory and locks utilized by the failing process are released. Overall, PMON manages failing processes and releases resources as required, contributing to the stability and dependability of the Oracle Database.


RECO

Oracle Database's Recoverer (RECO) procedure is in charge of restoring distributed transactions that have lost confidence as a result of communication breakdowns. Several database instances are used in a distributed transaction, and RECO tracks the transaction to look for any communication issues. The transaction is left in an in-doubt state if there is a communication breakdown, which means it cannot be committed or rolled back. RECO is in charge of resolving the in-doubt transaction by getting in touch with the other database instances and figuring out how it turned out. RECO commits or rolls back the transaction after the result has been decided, maintaining the consistency of the distributed transaction. Overall, RECO is crucial for preserving the consistency and dependability of distributed transactions in the Oracle Database.

Previous Post Next Post

Contact Form

Loading...