1. ITEC474 Redo Log Files

2. Objectives These notes include the purpose of (Online) Redo Log Files:
Learn the architectural approach for structuring Redo Log Files and Groups.
Learn to switch logs and use checkpoints. 
Learn to multiplex Online and Offline Redo Log Files.

3. (Online) Redo Log Files
 Redo Log Files enable the Oracle Server or DBA to redo transactions if a database failure occurs.  ONLY purpose is to enable recovery.
Transactions are written synchronously to the Redo Log Buffer in the System Global Area. 
All database changes are written to redo logs to enable recovery.
As the Redo Log Buffer fills, the contents are written to Redo Log Files. 
This includes uncommitted transactions, undo segment data, and schema/object management information. 
During database recovery, information in Redo Log Files enable data that has not yet been written to datafiles to be recovered. 

4. Redo Log File Organization – Multiplexing
The figure shown above provides the general approach to organizing online Redo Log Files.  Initially Redo Log Files are created when a database is created, preferably in groups to provide for multiplexing.  Additional groups of files can be added as the need arises.

5. Redo Log File Organization – Multiplexing (cont.)
Each Redo Log Group has identical Redo Log Files (however, each Group does not have to have the same number of Redo Log Files).
If you have Redo Log Files in Groups, you must have at least two Groups. The Oracle Server needs a minimum of two online Redo Log Groups for normal database operation. 
The LGWR concurrently writes identical information to each Redo Log File in a Group. 
Thus, if Disk 1 crashes as shown in the figure above, none of the Redo Log Files are truly lost because there are duplicates. 

6. Redo Log File Organization – Multiplexing (cont.)
Redo Log Files in a Group are called Members. 
Each Group Member has an identical log sequence number and is the same size – the members within a group cannot be different sizes. 
The log sequence number is assigned by the Oracle Server as it writes to a log group and the current log sequence number is stored in the control files and in the header information of all Datafiles – this enables synchronization between Datafiles and Redo Log Files.
If the group has more members, you need more disk drives in order for the use of multiplexed Redo Log Files to be effective.

7. Redo Log File Organization – Multiplexing (cont.)
A Redo Log File stores Redo Records (also called redo log entries).
Each record consists of "vectors" that store information about:
changes made to a database block. 
undo block data.
transaction table of undo segments.
These enable the protection of rollback information as well as the ability to roll forward for recovery.
Each time a Redo Log Record is written from the Redo Log Buffer to a Redo Log File, a System Change Number (SCN) is assigned to the committed transaction.

8. Where to Store Redo Log Files and Archive Log Files
 Guidelines for storing On-line Redo Log Files versus Archived Redo Log Files:
1.   Separate members of each Redo Log Group on different disks as this is required to ensure multiplexing enables recovery in the event of a disk drive crash.
2.   If possible, separate Online Redo Log Files from Archived Log Files as this reduces contention for the I/O path between the ARCn and LGWR background processes. 
3.   Separate Datafiles from Online Redo Log Files as this reduces LGWR and DBWn contention.  It also reduces the risk of losing both Datafiles and Redo Log Files if a disk crash occurs.
You will not always be able to accomplish all of the above guidelines – your ability to meet these guidelines will depend on the availability of a sufficient number of independent physical disk drives.

9. Redo Log File Usage Redo Log Files are used in a circular fashion.
One log file is written in sequential fashion until it is filled, and then the second redo log begins to fill.  This is known as a Log Switch.  
When the last redo log is written, the database begins overwriting the first redo log again. 

10. Redo Log File Usage (cont.)
    The Redo Log file to which LGWR is actively writing is called the current log file.
Log files required for instance recovery are categorized as active log files.
Log files no longer needed for instance recovery are categorized as inactive log files.
Active log files cannot be overwritten by LGWR until ARCn has archived the data when archiving is enabled.

11. Log Writer Failure
What if LGWR cannot write to a Redo Log File or Group?  Possible failures and the results are:
At least one Redo Log File in a Group can be written 
Unavailable Redo Log Group members are marked as Invalid, a LGWR trace file is generated, and an entry is written to the alert file – processing of the database proceeds normally while ignoring the invalid Redo Log Group members.
LGWR cannot write to a Redo Log Group because it is pending archiving 
Database operation halts until the Redo Log Group becomes available (could be through turning off archiving) or is archived.

12. Log Writer Failure (cont.)
A Redo Log Group is unavailable due to media failure
Oracle generates an error message and the database instance shuts down.  During media recovery, if the database did not archive the bad Redo Log, use this command to disable archiving so the bad Redo Log can be dropped:
ALTER DATABASE CLEAR UNARCHIVED LOG

13. Log Writer Failure (cont.)
A Redo Log Group fails while LGWR is writing to the members
Oracle generates an error message and the database instance shuts down.  Check to see if the disk drive needs to be turned back on or if media recovery is required.  In this situation, just turn on the disk drive and Oracle will perform automatic instance recovery.
Sometimes a Redo Log File in a Group becomes corrupted while a database instance is in operation. 
Database activity halts because archiving cannot continue.
Clear the Redo Log Files in a Group (here Group #2) with the statement:
ALTER DATABASE CLEAR LOGFILE GROUP 2;

14. How large should Redo Log Files be, and how many Redo Log Files are enough? 
The size of the redo log files can influence performance, because the behavior of the DBWn and ARCn processes (but not the LGWR process) depend on the redo log sizes.
Generally, larger redo log files provide better performance.
Undersized log files increase checkpoint activity and reduce performance.
It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable.
If the LGWR generates trace files and an alert file entry that Oracle is waiting because a checkpoint is not completed or a group has not been archived, then test adding another redo log group (with its files).

15. How large should Redo Log Files be, and how many Redo Log Files are enough? (cont.)
Minimum size for an On-line Redo Log File is 4MB.
Maximum size and Default size depends on the operating system. 
Databases that primarily support on-line, transaction-processing (OLTP) can work successfully with smaller Redo Log Files. 
Set the size large enough so that the On-line Redo Log Files switch about once every 20 minutes. 
If your Log Files are 4MB in size and switches are occurring on the average of once every 10 minutes, then double their size!
You can specify the log switch interval to 20 minutes (a typical value) with the init.ora command shown here that sets the ARCHIVE_LAG_TARGETparameter in seconds
ARCHIVE_LAG_TARGET = 1200 (20 mins) 
or to set the parameter dynamically
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 1200

16. How large should Redo Log Files be, and how many Redo Log Files are enough?  (cont.)
Determine if LGWR has to wait (meaning you need more groups) by:
Check the LGWR trace files – the trace files will provide information about LGWR waits.
Check the alert_SID.log file for messages indicating that LGWR has to wait for a group because a checkpoint has not completed or a group has not been archived.  
The parameter MAXLOGFILES in the CREATE DATABASE command specifies the maximum number of Redo Log Groups you can have – group numbers range from 1 to MAXLOGFILES.
Override this parameter only by recreating the database or control files.
When MAXLOGFILES is not specified, the CREATE DATABASE command uses a default value specific to each operating system – check the operation system documentation.
With Oracle 11g if your exceed the maximum number of Redo Log Groups, Oracle automatically causes the control file to expand in size to accommodate the new maximum number.

17. LGRW & CKPT
LGWR writes from the Redo Log Buffer to the current Redo Log File when:
a transaction commits
the Redo Log Buffer is 1/3 or more full.
There is more than 1MB of changed rows in the Redo Log Buffer
Prior to DBWn writing modified blocks from the Database Buffer Cache to Datafiles.
Checkpoints also affect Redo Log File usage.  
During a checkpoint the DBWn background process writes dirty database buffers (buffers that have modified data) from the Database Buffer Cache to datafiles.
The CKPT background process updates the control file to reflect that a checkpoint has been successfully completed. 
If a log switch occurs as a result of a checkpoint, then the CKPT process updates the headers of the datafiles.

18. LGRW & CKPT (cont.)
Checkpoints can occur for all datafiles in the database or only for specific datafiles.  A checkpoint occurs, for example, in the following situations:
when a log switch occurs.
when an Oracle Instance is shut down with the normal, transactional, or immediate option.
when forced by setting the initialization parameter FAST_START_MTTR_TARGET that controls the number of dirty buffers written by DBWn to datafiles.
when a DBA issues the command to create a checkpoint.
when the ALTER TABLESPACE [OFFLINE NORMAL | READ ONLY | BEGIN BACKUP] command causes check pointing on specific datafiles.
Checkpoint information is also recorded in the alert_SID.log file whenever the LOG_CHECKPOINTS_TO_ALERT initialization parameter is set to TRUE.  The default value of FALSE for this parameter does not log checkpoints.

19. Redo Log File Block Size
With Oracle 11g Release 2 you can specify a block size for online redo log files with the BLOCKSIZE keyword in the CREATE DATABASE, ALTERDATABASE, and CREATE CONTROLFILE statements. The permissible block sizes are 512, 1024, and 4096. 
This example shows use of the BLOCKSIZE parameter to create 512Kb blocks. 
ALTER DATABASE orcl ADD LOGFILE
  GROUP 4 (‘.../redo04a.log',’.../redo04b.log')
  SIZE 100M BLOCKSIZE 512 REUSE;
This query shows the blocksize for your database.
SQL> SELECT BLOCKSIZE FROM V$LOG;
BLOCKSIZE
      512

20. Log Switches and Checkpoints
This figure shows commands used to cause Redo Log File switches and Checkpoints.

21. Adding Online Redo Log File Groups
This figure shows the ALTER DATABASE command option used to add Redo Log File Groups.  This simultaneously adds new log files to the new Group3. 

22. Adding Online Redo Log File Members
This figure shows the ALTER DATABASE command options to add new Log File Members to existing groups.
If the file to be added already exists and is being reused, it must have the same size and you must use the REUSE option in the command immediately after the filename specification. 
Size need not be specified when adding to an existing group.

23. Adding Online Redo Log File Members (cont.)

24. Dropping Redo Log File Groups and Files
 ALTER DATABASE DROP LOGFILE GROUP 3;
Remember, you must keep at least two groups of Online Redo Log Files working.  
You also cannot drop an active (current) Group.  
Sometimes an individual Redo Log File will become damaged (invalid).  You can use the following command to drop the file.  Then use the operating system command to delete the file that stored the invalid Redo Log File, and then recreate the Redo Log File.
ALTER DATABASE DROP LOGFILE MEMBER ' .../SIDredo01a.log';

25. Changing Redo Log File Sizes
Each Redo Log File member in a Group must be identical in size.  If you need to make your Redo Log Files larger, use the following steps.
Use the V$LOG view to identify the current active Redo Log Group. 
SQL> SELECT group#, status FROM v$log;
    GROUP# STATUS
         1 INACTIVE
         2 INACTIVE
         3 CURRENT
         4 INACTIVE
Drop one or more of the inactive Redo Log Groups keeping at least two current Online Redo Log Groups.
Use operating system commands to delete the files that stored the dropped Redo Log Files.
Recreate the groups with larger file sizes.  Continue this sequence until all groups have been resized.

26. Obtaining Redo Log Group and File Information
Two views, V$LOG and V$LOGFILE are used to store information about Online Redo Log files.  
SELECT group#, sequence#, bytes/1024, members, status
FROM v$log;
    GROUP#  SEQUENCE# BYTES/1024    MEMBERS STATUS
         1         31      65536          2 INACTIVE
         2         32      65536          2 CURRENT
         3         30      65536          2 INACTIVE

27. Obtaining Redo Log Group and File Information (cont.)
Possible Status values for this view are:
Unused – the Redo Log Group has never been used – this status only occurs for a newly added Redo Log Group.
Current – the active Redo Log Group.
Active – the Redo Log Group is active, but not the current Group – it is needed for crash recovery and may be in use for block recovery.  It may not yet be archived.
Clearing – the Log is being recreated after an ALTER DATABASE CLEAR LOGFILE command.
Clearing_Current – the current Redo Log Group is being cleared of a closed group.
Inactive – The Group is not needed for Instance Recovery.
SELECT member, status
FROM v$logfile; 
Invalid – the file cannot be accessed and needs to be dropped and recreated.
Stale – the contents of the file are incomplete – drop it and recreate it.
Deleted – the file is no longer in use – you can use operating system commands to delete the associated operating system file.
Blank – the file is in use.

28. Archived Redo Log Files
Archived Log Modes
A production database should always be configured to operate in ARCHIVELOG mode. 
NOARACHIVELOG mode:
The Redo Log Files are overwritten each time a log switch occurs, but the files are never archived.
When a Redo Log File (group) becomes inactive it is available for reuse by LGWR.
This mode protects a database from instance failure, but NOT from media failure.
In the event of media failure, database recovery can only be accomplished to the last full backup of the database! 
You cannot perform tablespace backups in NOARCHIVELOG mode.

29. Archived Redo Log Files (cont.)
ARCHIVELOG mode
Full On-line Redo Log Files are written by the ARCn process to specified archive locations, either disk or tape – you can create more than one archiver process to improve performance. 
A database control file tracks which Redo Log File groups are available for reuse (those that have been archived).
The DBA can use the last full backup and the Archived Log Files to recover the database.
A Redo Log File that has not been archived cannot be reused until the file is archived – if the database stops awaiting archiving to complete, add an additional Redo Log Group.
The following figure shows the archiving of log files by the ARCn process as log files are reused by LGWR.

30. Archived Redo Log Files (cont.)
While archiving can be set to either manual or automatic, the preferred setting for normal production database operation is automatic.  In manual archiving, the DBA must manually archive each Online Redo Log File. 

31. Switching from NOARCHIVELOG to ARCHIVELOG
1.  Connect to the database with administrator privileges (AS SYSDBA) – shutdown the database instance normally with the command:  Shutdown
Note:  You cannot change from ARCHIVELOG to NOARCHIVELOG if any datafiles require media recovery.
2.  Backup the database – it is always recommended to backup a database before making any major changes. 
3.  Edit the init.ora file to add parameters to specify the destinations for archive log files (the next section provides directions on how to specify archive destinations).
4.  Startup a new instance in MOUNT stage – do not open the database – archive status can only be modified in MOUNT stage:  STARTUP MOUNT PFILE=<your pfile location>
5.  Issue the command to turn on archiving and then open the database:
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
6.  Shutdown the database SHUTDOWN IMMEDIATE
7.  Backup the database – necessary again because the archive status has changed.  The previous backup was taken in NOARCHIVELOG mode and is no longer usable.

32. Specifying Archive Destinations and Names
Archive Redo Log files can be written to a single disk location or they can be multiplexed, i.e. written to multiple disk locations.
Archiving to a single destination was once accomplished by specifying the LOG_ARCHIVE_DEST initialization parameter in the init.ora file – it has since been replaced in favor of the LOG_ARCHIVE_DEST_n parameter (see next bullet).
Multiplexing can be specified for up to 31 locations by using the LOG_ARCHIVE_DEST_n parameters (where n is a number from 1 to 31).  This can also be used to duplex the files by specifying a value for the  LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2 parameters.
When multiplexing, you can specify remote disk drives if they are available to the server.

33. Viewing Information on Archive Redo Log Files
Information about the status of the archiving can be obtained from the V$INSTANCE dynamic performance view.  This shows the status for the DBORCLdatabase.
SELECT archiver
FROM v$instance;
ARCHIVE
STARTED
Several dynamic performance views contain useful information about archived redo logs, as summarized in the following table.

34. Dynamic Performance View
Description
V$DATABASE
Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode and whether MANUAL (archiving mode) has been specified.
V$ARCHIVED_LOG
Displays historical archived log information from the control file. If you use a recovery catalog, the RC_ARCHIVED_LOG view contains similar information.
V$ARCHIVE_DEST
Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations.
V$ARCHIVE_PROCESSES
Displays information about the state of the various archive processes for an instance.
V$BACKUP_REDOLOG
Contains information about any backups of archived logs. If you use a recovery catalog, the RC_BACKUP_REDOLOG contains similar information.
V$LOG
Displays all redo log groups for the database and indicates which need to be archived.
V$LOG_HISTORY
Contains log history information such as which logs have been archived and the SCN range for each archived log.