We just learned about storing information in our online redo logs.
Let us expand this discussion by introducing archive log files. Archiving is the process of using the ARCH process to copy filled
redo log files to another location on disk or tape. Using archive log mode greatly enhances your backup and recovery options. Let’s say that you do a full database backup on Sunday night and
don’t use archive log mode. If the system crashes on Wednesday and all your disk drives are gone, your only recourse is to restore the Sunday
backup.
Let’s say that your system was set up to support archive log mode and your system crashed on Wednesday. You would then restore your Sunday backup and apply all the changes that have been made since Sunday by using your archive log files. This is a much better alternative than losing several days worth of information. We will discuss this process in greater detail in subsequent modules.
There are some considerations you should keep in mind when you support archive log mode with your database. Using archive log mode is generally a positive thing. The only potentially negative consideration is the last point, more disk space.
- Archiving redo log files work best when you use redo log groups. If there is a corruption on one member of a group,
ARCH reads the information from one of the alternate members.
- As
ARCH writes redo logs to disk or tape, LGWR may have to wait until this process completes before reusing a particular redo log group.
- Archiving of redo logs can be done manually or automatically via
ARCH.
- A database backup with archived redo logs guarantees a point in time recovery.
- With archiving turned on you can produce a valid backup while the system is online.
- Archived log files can be stored in more than one location.
The LOG_ARCHIVE_DEST parameter in your init.ora file indicates the primary archive location. - The
LOG_ARCHIVE_DUPLEX_DEST parameter in your init.ora file indicates the secondary archive location.
- You will need more disk space.