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 failu

Redo records can also be written to a redo log file before the corresponding
transaction is committed. If the redo log buffer fills, or another transaction commits,
LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even
though some redo records may not be committed. If necessary, the database can
roll back these changes.
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 the data segment block for the table, the undo segment data
block, and 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 records are buffered in a circular fashion in the redo log buffer of the SGA (see
"How Oracle Database Writes to the Redo Log") and are written to one of the redo
log files by the Log Writer (LGWR) database background process. Whenever a
transaction is committed, LGWR writes the transaction redo records from the redo

Redo log files that are required for instance recovery are called active redo log files. LGWR returns to the first redo log file and writes to it. the database can roll back these changes. Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled. Active (Current) and Inactive Redo Log Files Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. How Oracle Database Writes to the Redo Log The redo log of a database consists of two or more redo log files. If archiving is disabled (the database is in NOARCHIVELOG mode). LGWR begins writing to the next available redo log file. The redo log file that LGWR is actively writing to is called the current redo log file. LGWR flushes all of the redo log entries in the redo log buffer to a redo log file.log buffer of the SGA to a redo log file. starting the cycle again. If necessary. If the redo log buffer fills. a filled redo log file is available to LGWR after the changes recorded in it have been written to the datafiles and the file has been archived. Figure 10-1 illustrates the circular writing of the redo log file. When the current redo log file fills. even though some redo records may not be committed. Redo log files that are no longer required for instance recovery are called inactive redo log files. or another transaction commits. and assigns a system change number (SCN) to identify the redo records for each committed transaction. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). . LGWR writes to redo log files in a circular fashion. If archiving is enabled (the database is in ARCHIVELOG mode). The numbers next to each line indicate the sequence in which LGWR writes to each redo log file. When the last available redo log file is filled. a filled redo log file is available after the changes recorded in it have been written to the datafiles. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed Redo records can also be written to a redo log file before the corresponding transaction is committed.

then when the last redo log file is full. a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. When the database archives redo log files. the archived log retains its log sequence number. Choosing Between NOARCHIVELOG and ARCHIVELOG Mode This section describes the issues you must consider when choosing to run your database in NOARCHIVELOG or ARCHIVELOG mode. then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARCn) has archived its contents.If you have enabled archiving (the database is in ARCHIVELOG mode). the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files. During crash. regardless of whether the current redo log file is completely filled. instance. you can configure log switches to occur at regular intervals. You can also force log switches manually. LGWR continues by overwriting the first available active file. Each online or archived redo log file is uniquely identified by its log sequence number. Normally. If archiving is disabled (the database is in NOARCHIVELOG mode). or media recovery. Log Switches and Log Sequence Numbers A log switch is the point at which the database stops writing to one redo log file and begins writing to another. If you cannot afford to lose any data in your database in the event . and contains these topics: Running a Database in NOARCHIVELOG Mode Running a Database in ARCHIVELOG Mode The choice of whether to enable the archiving of filled groups of redo log files depends on the availability and reliability requirements of the application running on the database. A redo log file that is cycled back for use is given the next available log sequence number. Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. However.

NOARCHIVELOG mode protects a database from instance failure but not from media failure. You cannot recover transactions subsequent to that backup. you can only restore the database to the point of the most recent full database backup. To restore a database operating in NOARCHIVELOG mode. nor can you use online tablespace backups taken earlier while the database was in ARCHIVELOG mode. Therefore. if you decide to operate a database in NOARCHIVELOG mode. are available for instance recovery. you enable the archiving of the redo log. The archiving of filled groups has these advantages: A database backup. Running a Database in ARCHIVELOG Mode When you run a database in ARCHIVELOG mode. Therefore. If you keep an archived log. If a media failure occurs while the database is in NOARCHIVELOG mode. together with online and archived redo log files. you disable the archiving of the redo log. frequent intervals. In NOARCHIVELOG mode you cannot perform online tablespace backups. Only the most recent changes made to the database. the group is available for reuse by LGWR. take whole database backups at regular. which are stored in the online redo log groups. guarantees that you can recover all committed transactions in the event of an operating system or disk failure. The archiving of filled redo log files can require you to perform extra administrative operations. .of a disk failure. when a filled group becomes inactive after a log switch. you can use only whole database backups taken while the database is closed. Running a Database in NOARCHIVELOG Mode When you run your database in NOARCHIVELOG mode. use ARCHIVELOG mode. you can use a backup taken while the database is open and in normal system use. The database control file indicates that a group of filled redo log files cannot be reused by LGWR until the group is archived. A filled group becomes available for archiving immediately after a redo log switch occurs. The database control file indicates that filled groups are not required to be archived.

An archived redo log file is a copy of one of the filled members of a redo log group. automatic archiving is usually best. For convenience and efficiency. .You can keep a standby database current with its original database by continuously applying the original archived redo logs to the standby. if you are multiplexing your redo log. This process is only possible if the database is running in ARCHIVELOG mode. The process of turning redo log files into archived redo log files is called archiving. You can configure an instance to archive filled redo log files automatically. The process of turning redo log files into archived redo log files is called archiving. The archived redo log contains a copy of every group created since you enabled archiving. For example. you can perform coordinated distributed database recovery. known collectively as the archived redo log. or you can archive manually. then the archiver process (ARCn) will archive one of these member files. However. Figure 11-1 illustrates how the archiver process (ARC0 in this illustration) writes filled redo log files to the database archived redo log. then ARCn can still archive the identical b_log1. What Is the Archived Redo Log? Oracle Database lets you save filled groups of redo log files to one or more offline destinations. known collectively as the archived redo log. if any database in a distributed database is in NOARCHIVELOG mode. If all databases in a distributed database operate in ARCHIVELOG mode. It includes the redo entries and the unique log sequence number of the identical member of the redo log group. This process is only possible if the database is running in ARCHIVELOG mode. and if group 1 contains identical member files a_log1 and b_log1. recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOG mode @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Oracle Database lets you save filled groups of redo log files to one or more offline destinations. Should a_log1 become corrupted. You can choose automatic or manual archiving.

close before a table was dropped. IF not running archivelog mode.When the database is running in ARCHIVELOG mode. You can use archived redo logs to: Recover a database Update a standby database @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@2 f your database is running in ARCHIVELOG mode. Normally we use rman to do this. it copies all transactions to the archivelog destination. This enables you to restore your database to any point in time. For example. How regularly depends on the cost of loosing transactions. If your transactions are really important it could be smart to copy the archivedlog files to a second DC on a very regularly basis. a reason to run your databases in archivelog mode. the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived. The transactions are always written to the redolog files but when they are full. In general you start restoring the database and perform a recovery until time. If you can handle loosing one day. Normally production backups are made with the database online. you copy daily. they are only saved when running in archivelog mode. something like rman run { . most sites copy a few times/hour or even use standby databases that receive the transactions in a near sync way. This restore operation starts with restoring a full backup where you can apply the archives until you reach the point in time where you want to stop the recovery. in a disaster scenario you might loose all transactions made since the last backup. The background process ARCn automates archiving operations when automatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall behind. Again.

a used online redo log group must be copied to one or more archive destinations before it can be reused. recover database. All information about transactions recorded in that redo log group is lost. . such as direct path loads). To prevent nightmares from happening.set until time to_date('20140914 14:22'. open the database with a reset logs option.1 Implications of Running in NOARCHIVELOG Mode Running your database in NOARCHIVELOG mode imposes severe limitations on your backup and recovery strategy. In NOARCHIVELOG mode. You can run your database in one of two modes: ARCHIVELOG mode or NOARCHIVELOG mode.'yyyymmdd hh24:mi').3. alter database open resetlogs. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Deciding Between ARCHIVELOG and NOARCHIVELOG Mode The redo logs of your database provide a complete record of changes to the datafiles of your database (with a few exceptions. it might be smarter to get involvement from a dba. Archiving the redo log preserves all transactions stored in that log.3. You must shut your database down cleanly before you can take a backup in NOARCHIVELOG mode. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2. restore database. the online redo log groups are simply overwritten when the log is reused. In ARCHIVELOG mode. } when ready and not done a full media recovery. You cannot perform online backups of your database. so that they can be used in recovery operations later.

).You cannot use any data recovery techniques that require the archived redo logs. therefore you almost always want to backup your archive logs. as described in "Forms of Data Recovery". the database is created in NOARCHIVELOG mode. $ sqlplus /nolog . This command will check to see if you have altered your database to run in ARCHIVELOG mode. Restore the entire database from the most recent backup. it may be preferable to run in NOARCHIVELOG mode in spite of the limitations that this choice imposes upon your recovery options. These include complete and point-in-time media recovery. You almost always will want to run in ARCHIVELOG mode. which uses the archived redo logs. and then drop the files.. you have two main options for recovery: Drop all objects that have any extents located in the affected files. and more advanced recovery techniques such as pointin-time recovery of individual tablespaces and Flashback Database (described in Oracle Database Backup and Recovery Advanced User's Guide. By default. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2 Administer the Archived Redo Logs An Oracle database can run in one of two modes. but all data in the affected files is lost.. If you are running in NOARCHIVELOG mode and you must recover from damage to datafiles due to disk failure. See my notes on how to check if running in ARCHIVELOG mode. (Recovering changes since the backup would require performing media recovery. When performance requirements are extreme or disk space limitations are severe. and lose all changes to the database since the backup. The remainder of the database is intact.) .

When in NOARCHIVELOG mode the database runs normally. The archived redo logs are created via the ARCH process. These copies are called archived redo logs. Oracle will continue to try to archive the log file. If Oracle cannot archive the online redo log (for example. In ARCHIVELOG mode. then Oracle would have to overwrite them. the destination directory for the archived redo logs is filled up). SQL> select log_mode from v$database. For example. If the log files can not be written out. connected. the database will make copies of all online redo logs after they are filled. and prepare the archived redo log destination directories. you have to shutdown the database to back it up. Using the ARCHIVELOG Mode So. At the same time. First you must put the database in ARCHIVELOG mode and you must also configure the ARCH process. The ARCH process copies the archived redo log files to one or more archive log destination directories. Thus. The use of ARCHIVELOG mode requires some configuration of the database. Unfortunately. once an online redo log has been filled. it cannot be reused until it has been archived. There are some down sides to running the database in ARCHIVELOG mode. but there is no capacity to perform any type of point in time recovery operations or online backups. the big corporate types tend to frown when a weeks worth of current production accounting data is lost forever.SQL> connect / as sysdba. This is not good because it means we would lose the data that was in those . we have a problem. While this might be fine for a development environment. SQL> archive log list. once the database runs out of available online redo logs. you will want to run Oracle in ARCHIVELOG mode. and when you recover the database you can only recover it to the point of the last backup. it will switch to the next online redo log and keep working. if you wish to avoid the wrath of the CEO and angry end-users.

the database will be freed. db_recovery_file_dest_size . By default in Oracle Database 10g and beyond. Until the file has been archived.2g . We recommend that the db_recovery_file_dest parameter be set to a directory location that is separate from the location of the Oracle software. Use the alter system command to set these parameters if you do not want to use the default values. You will find examples of the use of the alter system command to change parameters earlier in this chapter.ORACLE_BASE/flash_recovery_area . In the next sections we will look at how to configure the database for ARCHIVELOG mode and how to put the database in ARCHIVELOG mode. You do not want to accidentally fill up ORACLE_HOME or cause performance issues due to contention.This is the location of the flash recovery area. You can see how an incorrect configuration of the database when it is in ARCHIVELOG mode can eventually lead to the database suspending operations because it can not archive the current online redo logs. If this size limit is exceeded. in an effort to protect the database.This is the maximum size that can be used by the flash recovery area. and processing can proceed as normal. Oracle will send archived redo logs to the flash recovery area and we recommend this configuration. your redo logs. Once the log file has been archived. you will want to set two parameters as seen in the following list: db_recovery_file_dest . and your data files. . As a result of this.files since Oracle could not archive the file. the database will simply stop processing user requests. Oracle will not overwrite data in an online redo log file until that log file has been archived. you must clear out space or database operations will eventually stall. To properly setup the flash recovery area. Configuring the database for ARCHIVELOG Mode One of the main features of a database that is in ARCHIVELOG mode is that it generates copies of the online redo logs called archived redo logs.

our database has a directory called: C:\Oracle\product\flash_recovery_area\BOOKTST Under this directory are individual directories for various file types such as ARCHIVELOG where the archived redo logs will reside. Oracle Database 10g does not require this. a directory for the database will be created in the location defined by the db_recovery_file_dest parameter. and finally open the database. Putting the database in ARCHIVELOG Mode Once you have configured the flash recovery area. When the database is in ARCHIVELOG mode. you will start the database in mount mode with the startup mount command.When the flash recovery area is configured. Then put the database in ARCHIVELOG mode. we note that shutdown immediate is the best option). Unfortunately. . you can put the database in ARCHIVELOG mode. it will start the ARCH process automatically. Total System Global Area 272629760 bytes Fixed Size Variable Size 788472 bytes 103806984 bytes Database Buffers 167772160 bytes Redo Buffers 262144 bytes Database mounted. SQL> startup mount ORACLE instance started. Here is an example of how this all works from the command line: SQL> shutdown immediate Database closed. ORACLE instance shut down. this requires that the database be shutdown first with the shutdown command (however. For example. Database dismounted. Once you have shutdown the database. In earlier versions of Oracle you had to enable a special Oracle process called ARCH by setting another parameter. from earlier in the chapter.

we do a directory listing in that directory and you should see archived redo logs in the directory. SQL> alter database open. go to the directory that is named for today?s date. In my case. each represents a different date such as 2005_03_09 for March 3. Once the database is in ARCHIVELOG mode. 1005. I?ll go to the 2005_03_16 directory. Now.SQL> alter database archivelog. Under that directory you will find individual directories. first force a log switch with the alter system switch logfile command. Here is an example of what you will see on your computer: C:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG005_03_16 >dir Volume in drive C has no label. Database altered. The directory structure on my computer looks like this: C:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG005_03_09 It might look a little different on your computer (sometimes Oracle does different things on different Operating Systems) but it should be pretty easy to figure it out. To do this. Then check the flash recovery area to make sure an archived redo log is created. Next. Volume Serial Number is 50FD-2353 . Database altered. it will start generating archived redo logs. Note! Oracle flash recovery area re-named to fast recovery area The archived redo logs will be in the flash recovery area in the ARCHIVELOG directory. It's always a good idea to make sure that the archived redo logs are getting generated.

v$log_history .Information about archived redo logs. v$parameter .Shows the location of the flash recovery area where archived redo logs are created. Archived Redo Log Data Dictionary Views Oracle provides data dictionary views for the archived redo logs as seen in this list: v$archived_log . you know archiving is working all right.Directory of c:\Oracle\product\flash_recovery_area\BOOKTST\ARCHIVELOG005_03_16 If you are seeing files get generated here.Contains information on previous redo logs @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@ .