Databases Reference
In-Depth Information
You can verify that your online redo logs are in the new locations by querying the
V$LOGFILE
view. I recommend
as well that you switch your online redo logs several times and then verify from the OS that the files have recent
timestamps. Also check the
alert.log
file for any pertinent errors.
Implementing Archivelog Mode
Recall from the discussion earlier in this chapter that archive redo logs are created only if your database is in
archivelog mode. If you want to preserve your database transaction history to facilitate point-in-time and other types
of recovery, you need to enable that mode.
In normal operation, changes to your data generate entries in the database redo log files. As each online redo
log group fills up, a log switch is initiated. When a log switch occurs, the log writer process stops writing to the most
recently filled online redo log group and starts writing to a new online redo log group. The online redo log groups
are written to in a round-robin fashion—meaning the contents of any given online redo log group will eventually be
overwritten. Archivelog mode preserves redo data for the long term by employing an archiver background process to
copy the contents of a filled online redo log to what is termed an
archive redo log file
. The trail of archive redo log files
is crucial to your ability to recover the database with all changes intact, right up to the precise point of failure.
Making Architectural Decisions
When you implement archivelog mode, you also need a strategy for managing the archived log files. The archive
redo logs consume disk space. If left unattended, these files will eventually use up all the space allocated for them.
If this happens, the archiver can't write a new archive redo log file to disk, and your database will stop processing
transactions. At that point, you have a hung database. You then need to intervene manually by creating space for
the archiver to resume work. For these reasons, there are several architectural decisions you must carefully consider
before you enable archiving:
•
Where to place the archive redo logs and whether to use the fast recovery area to store them
•
How to name the archive redo logs
•
How much space to allocate to the archive redo log location
•
How often to back up the archive redo logs
•
When it's okay to permanently remove archive redo logs from disk
•
How to remove archive redo logs (e.g., have RMAN remove the logs, based on a retention
policy)
•
Whether multiple archive redo log locations should be enabled
•
When to schedule the small amount of downtime that's required (if a production database)
As a general rule of thumb, you should have enough space in your primary archive redo location to hold at least
a day's worth of archive redo logs. This lets you back them up on a daily basis and then remove them from disk after
they've been backed up.
If you decide to use a fast recovery area (FRA) for your archive redo log location, you must ensure that it contains
sufficient space to hold the number of archive redo logs generated between backups. Keep in mind that the FRA
typically contains other types of files, such as RMAN backup files, flashback logs, and so on. If you use a FRA, be aware
that the generation of other types of files can potentially impact the space required by the archive redo log files.
You need a strategy for automating the backup and removal of archive redo log files. For user-managed backups,
this can be implemented with a shell script that periodically copies the archive redo logs to a backup location and
then removes them from the primary location. As you will see in later chapters, RMAN automates the backup and
removal of archive redo log files.
