|Lesson 12|| Archived Redo Logs|
|Objective|| Archived redo logs provide point-in-time recovery.|
Archived Redo Logs in Oracle
Generating Change Reports
Explain how archived redo logs provide point-in-time recovery.
You have just learned about how redo logs can be used to replay transactions lost during a system crash. They can also be used to replay transactions when a database has been restored from a backup.
This enables you to restore a database from a backup, and recover it up to the very moment of failure, without losing any committed transactions.
The key to doing this is to save all the redo logs generated since the most recent backup.
You do this by running your database in archive log mode
, which you will learn about later in this course.
How archive log mode works
Recall that Oracle cycles through the redo log files in a circular fashion, reusing each file over and over again.
When you run a database in archive log mode, Oracle makes a copy of each redo log file before it is reused.
The following SlideShow demonstrates how it works:
- The redo logs are spread over disks 1 and 2.
- A log switch has occurred, and Oracle is now writing to redo log group 2.
- At some point after the log switch, Oracle will copy one of the group 1 members to the archive log destination.
- Now Oracle has advanced to redo log group 3, and group 2 is available to be archived
- Oracle fills group 3, and rolls back around to group 1.
- Oracle fills group 1, but cannot advance to group2 because it has not been archived yet.
- Finally, the archiver catches up a bit and group2 is archived.
- Oracle is now free to overwrite redo log group 2, so the log switch can occur.
Archive log mode
Naming of archive log files
As you can see from the SlideShow, the redo log filenames do not carry over when a log file is archived. Instead, archive log files are sequentially numbered. You do have control over the format of the filename through the use of the
LOG_ARCHIVE_FORMAT initialization parameter. You will learn about that in a later course in this series.
Timing of the archiver process
The copying of files is done asynchronously with respect to the log switches and Oracle only copies one member of each group to the archive log destination. When a log switch occurs, the archiver process is notified. The archiver will eventually copy the log file.
As the DBA, you hope this will start right away, but the archiver may be busy with a previous file. The important point is that database users do not have to wait while files are archived. As long as the archiver gets caught up before Oracle needs to reuse that log file,the archiving process will run smoothly.
There are a number of things that affect whether or not the archiver will be caught up at any given moment: disk I/O speed, disk contention, CPU utilization, and the transaction rate. A sudden burst of activity could cause the archiver to slow down for awhile. That is OK, as long as it can keep up with the overall throughput.
This archiving process is one more reason why you must have a minimum of two redo log groups in an Oracle database.
In order for the archiver process to make a copy of a filled redo log file, that file must be closed long enough for the copy to take place.
The only way to close a redo log file and still keep the database running, is to switch to another redo log group, and that's exactly what Oracle8i does.