Database Reference
In-Depth Information
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 FRA 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 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.
If your business requirements are such that you must have a certain degree of high availability and redundancy,
then you should consider writing your archive redo logs to more than one location. Some shops set up jobs to copy
the archive redo logs periodically to a different location on disk or even to a different server.
Setting the Archive Redo File Location
Before you set your database mode to archiving, you should specifically instruct Oracle where you want the archive
redo logs to be placed. You can set the archive redo log file destination with the following techniques:
LOG_ARCHIVE_DEST_N
database initialization parameter.
•
Set the
•
Implement a FRA.
