Database Reference
In-Depth Information
Moving files is usually the quickest and safest way to resolve the archiver error. You can use an OS utility such as
mv
to move old archive redo logs to a different location. If they're needed for a subsequent restore and recovery, you
can let the recovery process know about the new location. Be careful not to move an archive redo log that is currently
being written to. If an archived redo log file appears in
V$ARCHIVED_LOG
, that means it has been completely archived.
You can use an OS utility such as
gzip
to compress archive redo log files in the current archive destination. If you
do this, you have to remember to uncompress any files that may be later needed for a restore and recovery. Be careful
not to compress an archive redo log that is currently being written to.
Another option is to use an OS utility such as
rm
to remove archive redo logs from disk permanently. This
approach is dangerous because you may need those archive redo logs for a subsequent recovery. If you do remove
archive redo log files, and you don't have a backup of them, you should make a full backup of your database as soon
as possible. Again, this approach is risky and should only be done as a last resort; if you delete archive redo logs that
haven't been backed up, then you chance not being able to perform a complete recovery.
If another location on your server has plenty of space, you can consider changing the location to which the
archive redo logs are being written. You can perform this operation while the database is up and running; for example,
SQL> alter system set log_archive_dest_1='location=/u02/oraarch/O12C';
After you've resolved the issue with the primary location, you can switch back the original location.
For most databases, writing the archive redo logs to one location is sufficient. However, if you have any type
of disaster recovery or high-availability requirement, then you should write to multiple locations. Sometimes,
DBAs set up a job to back up the archive redo logs every hour and copy them to an alternate location or even to an
alternate server.
Backing Up Archive Redo Log Files
Depending on your business requirements, you may need a strategy for backing up archive redo log files. Minimally,
you should back up any archive redo logs generated during a backup of a database in archivelog mode. Additional
strategies may include
•
periodically copying archive redo logs to an alternate location and then removing them from
the primary destination
•
copying the archive redo logs to tape and then deleting them from disk
•
using two archive redo log locations
•
using Data Guard for a robust disaster recovery solution
Keep in mind that you need all archive redo logs generated since the begin time of the last good backup to ensure
that you can completely recover your database. Only after you're sure you have a good backup of your database
should you consider removing archive redo logs that were generated prior to the backup.
If you're using RMAN as a backup and recovery strategy, then you should use RMAN to backup the archive redo
logs. Additionally, you should specify an RMAN retention policy for these files and have RMAN remove the archive
redo logs only after the retention policy requirements are met (e.g., back up files at least once before removing from
disk) (see Chapter 5 for details on using RMAN).
Managing Tablespaces and Data files
The term
tablespace
is something of a misnomer, in that it's not just a space for tables. Rather, a tablespace is a
logical container that allows you to manage groups of data files, the physical files on disk that consume space. Once a
tablespace is created, you can then create database objects (tables and indexes) within tablespaces, which results in
space allocated on disk in the associated data files.
