Process after Oracle Architecture

Background process --- V $ BGPROCESS, which is an Oracle program used to manage the read/write, recovery, and monitoring of databases. Server Process communicates with user process and exchanges data with user process. On Unix machines, the Oracle background process is relative to the operating system process. That is to say, an Oracle background process starts an operating system process. On Windows machines, the Oracle background process is relative to the operating system thread, open the task manager and we can only see one ORACLE..

You can view background processes in Unix as follows:

Ps-ef | grep ora _

The Oracle system has five basic processes:

• DBWR (data file writing process)
• LGWR (Log File writing process)
• SMON (system monitoring process)
• PMON (user process monitoring process)
• CKPT (Checkpoint Process, synchronous data file, log file, control file)

 

A. DBWR

Write the data in the modified data buffer to the corresponding data file.

Maintain an empty BUFFER IN THE SYSTEM

Here are several concepts that are prone to errors:

After an update is submitted, DBWR writes the data to the disk and returns it to the user for submission.

DBWR triggers the CKPT background process

DBWR does not trigger the LGWR Process

The above concepts are all incorrect.

DBWR is a very underlying working process that writes data in the buffer zone to the disk in batches. And any front-end

User processes have almost no relationship and are not controlled by them.

Triggering Conditions for DBWR operation:

A) DBWR times out for 3 seconds;

B) There are not many empty buffers in the system to store data;

C) The CKPT process triggers DBWR.

Oracle allows multiple DBWn processes to run at the same time to share the tedious write load. This is the source of n in DBWn. A database can use up to 20 DBWn processes.

 

B. LGWR

Write the data in the redo log buffer to the redo log file. LGWR is a process that must communicate with the foreground user process. When the data is modified, the system generates a redo log and records it in the redo log buffer. This redo log can be considered as a structure similar to the following:

SCN = 000000001000

Data Block ID

The object ID = 0801.

Data ROW = 02

Data after modification = 0011

At the time of submission, LGWR must write the data in the redo log buffer of the modified data to the log data file, and then notify the foreground process of successful submission, and the foreground process will notify the user. From this point, we can see that LGWR undertakes the task of maintaining system data integrity.

LGWR trigger conditions:

A) User submission;

B) 1/3 of the redo log buffers are not written to the disk;

C) A redo log buffer greater than 1 MB has not been written to the disk;

D) 3 seconds of timeout;

E) If the SCN Number of the data to be written by DBWR is greater than the scn number of the lgwr record, DBWR triggers LGWR writing.

LGWR writes redo entries to online log files in two ways:

Background write and sync write ).

There are four conditions for triggering background write:

1) LGWR starts every three seconds;

2) When DBWR is started, if the redo entry corresponding to the dirty data block is not written into the online log file, DBWR triggers the LGWR process and waits until LRWR is finished;

3) when the number of redo entries reaches 1/3 of the log buffer, LGWR is triggered;

4) when the number of redo entries reaches 1 MB, LGWR is triggered.

The synchronous write trigger condition is:

LGWR is triggered when a user commits a request.

The log buffer is a circular buffer. After LGWR writes log entries in the log buffer to the log file, the server process can write new log entries to the log buffer. LGWR is usually written very quickly to ensure that there is always space in the log buffer to write new log entries.

Note: Sometimes when more log buffers are required, LWGR writes log items before a transaction is committed, and these log items are only made permanent after the transaction is committed.

ORACLE uses the fast Submission mechanism. When a user issues a COMMIT statement, a COMMIT record is immediately placed in the log buffer, but the change in the corresponding data buffer is delayed, they are not written to data files until they are more effective. When a transaction is committed, it is assigned a system modification number (SCN), which is recorded together with the transaction log items in the log. As the SCN is recorded in the log, the restoration operation can be synchronized when the parallel server option is configured.

 

C. SMON

Work includes:

Clear temporary space;

When the system starts, the system instance is restored;

Combine idle space;

Resume the transaction activity from a non-available file;

Recovery of instances of failed nodes in OPS;

Clear the OBJ $ table;

Reduce rollback segments;

Takes the rollback segment offline;

 

D. PMON

It is mainly used to clear invalid user processes and release resources used by user processes. If PMON rolls back unsubmitted

Work, release the lock, and release the SGA resources allocated to failed processes.

 

E. CKPT

Data files, log files, and control files are synchronized. Due to the working principle of DBWR/LGWR

Files, log files, and control files are inconsistent, which requires the CKPT process to synchronize.

CKPT updates the header information of the data file/control file.

CKPT trigger condition:

During log switching;

A) when the database is shut down using the immediate, transaction, and normal options;

B) The values are determined based on the values set in the initial LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, and FAST_START_IO_TARGET files;

C) User-triggered.

Manual configuration is required for starting the following processes

A. ARCH

When the database runs in archive mode, Oracle starts the ARCH process. When the redo log file is full, switch the log file, the old redo log file is copied to one/more specific directories/remote machines by the ARCH process. These replicated redo log files are called archive log files.

B. RECO

Resolves faults in distributed transactions. Oracle can connect to multiple remote databases. Due to network problems, some things are pending. The RECO process tries to establish communication with the remote server. When the fault is eliminated, the RECO process automatically resolves all pending sessions.

C. LCKn

It is used in an environment with parallel server options. Up to 10 processes (LCK0, LCK1 ......, LCK9 ),

Used to block instances.

D. service Process Server Process

Service Process Classification

Dedicated Server Process: a service Process corresponds to a user Process.

MultiTreaded Server Process: a service Process corresponds to multiple user processes and serves user processes in turn.