Marking Architectural Decisions- Managing Control Files, Online Redo Logs,and Archivelogs
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 cannot 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 is okay to permanently remove archive redo logs from disk
• How to remove archive redo logs using RMAN based on a retention policy
• Whether multiple archive redo log locations should be enabled
• When to schedule the small amount of downtime that is required
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 have been backed up.
If you decide to use a fast recovery area (FRA) for your archive redo log locations, 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 an FRA, be aware that the generation of other types of files can potentially impact the space required by the archive redo log files. There are parameters that can be set to manage the FRA and provide a way to resize the space for recovery in order for the database to continue instead of having to increase space on the file system.
The parameters DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE set the file location for the FRA and the size of the space to be used by the database. These can also prevent one database filling up the space for other databases that might be on the same server. The ASM diskgroup FRA can be created to manage the space using
ASM. DB_RECOVERY_FILE_DEST = +FRA will allow the database to use the FRA disk group. Again, there are advantages of managing space behind the scenes in a scenario that fills up space. Using these parameters along with ASM removes specific file systems and allows for more options to quickly address issues with archive logs and use the recovery areas. FRA is recommended for this since the parameters are dynamic and allow for changes to occur to prevent the database from hanging. This should be included in the planning and architecting of the archive mode of the database.
You need a strategy for automating the backup and removal of archive redo log files. RMAN automates the backup and removal of archive redo log files. In later chapters we will provide details on RMAN backups and recovery.
