Redo Log

As I said before, REDO Log’s purpose is to store all transactions in case of emergency (data corruption, instance failure, recovery) or other purposes such as performance optimization or data replication.

Let’s have a closer look on how REDO Log operates.

REDO log is being handled by a process called LogWriter. LogWriter empties data from the Instance, specifically from the Log Buffer.

Now check out some bullet points on how REDO log manages data:

  • RedoLog is being handled by LogWriter (from Log Buffer)
  • RedoLog files are divided into groups
    • at least two groups are required for log switching (see below)
  • Each group has members
    • a member is actually a REDO log file
  • Each group must have at least one member
    • nonetheless, at least two members are recommended (why? see below)
  • Each group does not have to have the same number of members as the other groups do
    • though, it’s a good practice to keep the number of members the same
  • Each member (file) in a group has the same size as other members (files) of the same group
    • it is not necessary to have every group of the same size! though it’s a good practice to keep them the same
    • the idea behind having multiple members within a group is to have a backup in case that one member (file) gets corrupted, LogWriter can use the other member for a continuous processing
    • whenever LogWriter writes into the group, it writes to all members simultaneously
  • When LogWriter empties the log buffer it will write data to a particular group
    • this is called “CURRENT” group
    • once the “CURRENT” group is full, the log writer will switch to the next group
    • if there is no “unused” group left anymore, it will switch back to the first group and start all over again with overwriting the existing data there
    • the only condition for overwriting is, that the group must be “INACTIVE”
      • a group will become “INACTIVE” if
        • the group has been CHECKPOINTed
        • when LogWriter  switches from G1 to G2, G2 becomes CURRENT and G1 is still ACTIVE
        • if the checkpoint is applied, it will become inactive
      • the group has been ARCHIVEd
        • after a switch, a copy of the Redo Log content is moved into Archived Log (ARC process) and then G1 can be tagged as inactive
  • best practice for a log switch interval is every 20 minutes