0053-0055

Previous Table of Contents Next

Page 53

Offline/Archived Redo Logs

The offline or archived redo logs are exact copies of the online redo logs that have been filled; it is optional whether you ask Oracle to create these. Oracle only creates them when the database is running in Archive Log mode. If the database is running in Archive Log mode, the ARCH background process wakes up and copies the online redo log to the offline destination (typically another disk drive) once it becomes full. While this copying is in progress, Oracle uses the other online redo log. If you have a complete set of offline redo logs since the database was last backed up, you have a complete record of changes that have been made. You could then use this record to reapply the changes to the backup copy of the database files if one or more online database files are lost.

Other Supporting Files

When you start an Oracle instance (in other words, when the Oracle background processes are initiated and the memory structures allocated), the instance parameter file determines the sizes and modes of the database. This parameter file is known as the INIT.ORA file. (The actual name of the file has the Oracle instance identifier appended to the filename.) This is an ordinary text file containing parameters for which you can override the default settings. The DBA is responsible for creating and modifying the contents of this parameter file.

On some Oracle platforms, a SGAPAD file is also created, which contains the starting memory address of the Oracle SGA.

System and User Processes

In this part, we discuss some of the Oracle system processes that must be running for the database to be useable, including the optional processes and the processes that are created for users connecting to the Oracle database.

Mandatory System Processes

The four Oracle system processes that must always be up and running for the database to be useable include DBWR (Database Writer), LGWR (Log Writer), SMON (System Monitor), and PMON (Process Monitor).

DBWR (Database Writer)

The database writer background process writes modified database blocks in the SGA to the database files. It reads only the blocks that have changed (for example, if the block contains a new record, a deleted record, or a changed record). These blocks are also called dirty blocks. The database writer writes out the least recently used blocks first. These blocks are not necessarily written to the database when the transaction commits; the only thing that always happens on a commit is that the changes are recorded and written to the online redo log files. The database blocks will be written out later when there are not enough buffers free in the SGA to read in a new block.

Page 54

LGWR (Log Writer)

The log writer process writes the entries in the SGA's redo buffer for one or more transactions to the online redo log files. For example, when a transaction commits, the log writer must write out the entries in the redo log buffer to the redo log files on disk before the process receives a message indicating that the commit was successful. Once committed, the changes are safe on disk, even though the modified database blocks are still in the SGA's database buffer area waiting to be written out by DBWR. The SMON can always reapply the changes from the redo logs if the memory's most up-to-date copy of the database blocks is lost.

SMON (System Monitor)

The system monitor process looks after the instance. If two transactions are both waiting for each other to release locks and neither of them can continue (known as a deadlock or deadly embrace), SMON detects the situation and one of the processes receives an error message indicating that a deadlock has occurred.

SMON also releases temporary segments that are no longer in use by the user processes that caused them to be created.

During idle periods, SMON compacts the free-space fragments in the database files, making it easier and simpler for Oracle to allocate storage for new database objects or for existing database objects to grow.

In addition, SMON automatically performs recovery when the Oracle instance is first started (if none of the files have been lost). You won't see a message indicating that instance recovery is occurring, but the instance might take longer to come up.

PMON (Process Monitor)

The process monitor monitors the user processes. If any failure occurs with the user processes (for example, if the process is killed in the middle of a transaction), PMON automatically rolls back the work of the user process since the transaction started (anything since the last COMMIT or ROLLBACK). It releases any locks taken out and other system resources taken up by the failed process.

PMON also monitors the dispatcher and shared server processes, which are part of the multithreaded server setup, and restarts them if they have died.

Optional System Processes

As well as the four mandatory system processes, there are a number of optional system processes that you can initiate.

ARCH (Archiver)

When the database is running in Archive Log mode and you've started the archiver background process, the archiver process makes a copy of one of the online redo log files to the archive destination (the exact location is specified in an INIT.ORA parameter). In this way, you can have

Page 55

a complete history of changes made to the database files recorded in the offline and the online redo logs.

There is no point in keeping the archiver background process running if the database is not running in Archive Log mode.

CKPT (Checkpoint Process)

A checkpoint occurs when one of the online redo log files fills; it will be overwritten when one of the other online redo logs fills. If the redo log file is overwritten, the changes recorded in that file are not available for reapplying in case of system failure. At a checkpoint, the modified database buffer blocks are written down to the relative safety of the database files on disk by the database writer background process. This means that you won't need the record of changes in the event of system failure with lost memory areas. After a checkpoint occurs, the redo log can be reused.

At a checkpoint, all the database file headers and redo log file headers are updated to record the fact that a checkpoint has occurred. The LGWR background process performs the updating task, which could be significant if there are a large number of database and redo log files. The entire database might have to wait for the checkpoint to complete before the redo logs can record further database changes. To reduce the time it takes for LGWR to update the database and redo log file headers, you can initiate the checkpoint process.

A checkpoint can occur at other times, such as when the entries in the redo log files reach a limit defined by the database administrator.

NOTE

Whether or not the CKPT background process is initiated, checkpointing still occurs when one of the redo log files fills.

RECO (Recoverer)

You use the recoverer background process when there is a failure in a distributed transaction (a transaction where two or more databases are updated), and one or more of the databases involved need to either commit or roll back their changes. If initiated, the Recoverer attempts to automatically commit or roll back the transaction on the local database at timed intervals in synchronization with the Recoverer processes on the other Oracle databases.

There is no point in keeping the Recoverer background process running if you're not using distributed transactions on the database.

LCK (Lock)

You use the lock background process in the parallel server setup of Oracle where more than one instance is running against the same set of database files. The LCK processes running on all instances will synchronize locking between the instances. If a user connects to one instance

Previous Table of Contents Next