Databases Reference
In-Depth Information
the data files) from the archived redo log files. Archivelog mode ensures that after every online redo log switch, the
contents of the logs are successfully copied to archived redo log files.
When in archivelog mode, Oracle will not allow an online redo log file to be overwritten until it is copied to an
archived redo log file. If Oracle cannot copy an online redo log file to an archived redo log file, then your database will
stop processing and hang. Therefore, it's critical that you have a strategy to manage the available free space where the
archived redo log files are being stored.
We must point out that when working with a production database, you need an intelligent strategy for implementing
archiving, mainly for two reasons. First, the archive redo logs are crucial for recovering transactions in the event of a
failure. Therefore, you need a strategy for backing up these files. Second, the archive redo logs consume disk space; if left
unattended, these files will eventually consume all the space allocated for them. If this happens, the archiver background
process can't write a new archive redo log file to disk, and your database will stop processing transactions. At this point
you have a hung database. You need to manually intervene by creating space for the archiver to resume work.
For these reasons, there are several architectural decisions you must carefully consider before implementing
archiving in a production environment:
•
Where to place the archive redo logs, and whether to use the fast-recovery area (FRA) to store
the archive redo logs
•
How to name the archive redo logs
•
How much space should be allocated 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
•
Whether multiple archive redo log locations should be enabled
•
When to schedule the small amount of downtime that's required to enable archiving
Minimally, 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 (see Chapter 3 for complete details on how to use a FRA).
You need a strategy to automate the backup and removal of archive redo log files. As you see in later chapters in
this topic, RMAN automates the backup and removal of archive redo log files.
If your business requirements are such that you must have a high degree of 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 tape, or even copy them to a different server.
Connecting to RMAN
Problem
You want to connect to RMAN and prepare to perform backup and recovery tasks.
Solution
To connect to RMAN, you need to establish the following:
•
OS environment variables
•
Access to a privileged operating system (OS) account or schema with
sys*
privileges (
sysdba
,
sysoper
, or
sysbackup
)
