RelationalDBDesign RelationalDBDesign


Tuning Instance   «Prev  Next»
Lesson 11

Redo log tuning Conclusion

This module discussed the major points regarding redo log files and their impact on Oracle performance.
Now you should be able to:
  1. Understand redo log functions
  2. Describe the main tuning techniques for the redo log
  3. Investigate redo log activity for Oracle tasks
  4. Set the redo log parameters
  5. Examine redo log wait statistics
  6. Determine sizes for online redo logs
  7. Set appropriate sizes for the archived redo log file system
  8. Change parameters to relieve redo log contention
  9. Set log_checkpoint_interval to maximize performance


New terms

Here are some terms from this module that may have been new to you:
  1. archive monitor process: This is a process on Unix that monitors the archive process and writes the redo logs to the archives.
  2. archiver process: This process is only active if archive logging is in effect. This process writes the redo log data files that are filled into the archive log data files.
  3. log writer process: This process transfers data from the redo log buffers to the redo log database files.
  4. OEM top session monitor: Enables you to view top processes sorted by any number of redo log statistics.
Now that you are familiar with redo log tuning, we will explore tuning Oracle sort operations.

What Is the Redo Log?

The most crucial structure for recovery operations is the redo log, which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.

Redo Threads

When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a redo thread. In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck. This module described how to configure and manage the redo log on a standard single-instance Oracle Database. The thread number can be assumed to be 1 in all discussions and examples of statements.

Redo Log Contents

Redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to 1) the data segment block for the table, 2) the undo segment data block, and 3) the transaction table of the undo segments. Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.

Redo Log Tuning - Quiz

Before you move on to the next module, click the Quiz ink below to review redo log tuning.
Redo Log Tuning - Quiz