0517-0519

Previous Table of Contents Next

Page 517

Manual Archiving

If you set the value of the LOG_ARCHIVE_START parameter to FALSE ”the default value ”the Oracle RDBMS instance will use manual archiving. Manual archiving places the control of, and the responsibility for, archiving redo logs in the DBA's hands. When a database runs under manual archiving, it runs unfettered until a redo log must be archived. When that occurs, the database performs no further activity until the DBA intervenes and issues the alter system archive log all command from Oracle Server*Manager or SQL*Plus. For example:

 % svrmgrl SVRMGR> connect internal Connected. SVRMGR> alter system archive log all; Statement processed. 

TIP

Don't use manual archiving for high-transaction databases that require a high degree of availability.

Users cannot perform any operations until the DBA takes the steps necessary to archive the redo logs manually. Therefore, adequate planning is a must for database instances that use manual archiving.

Automatic Archiving

Automatic archiving works in the same way as manual archiving, except that the database takes full responsibility for copying the archive logs to their appropriate destinations. If an error occurs during the copy ”for example, a device might fail or the file system might become full ”the database stops all operations until the problem is rectified. To place the database in automatic archive mode, set the value of the LOG_ARCHIVE_START parameter to TRUE.

Automatic archiving is recommended for high-transaction, high-availability systems, such as those used by OLTP, that cannot afford to have a DBA poised and ready to archive redo logs manually at a moment's notice.

Manual Archiving Versus Automatic Archiving

In manual archiving

• The DBA controls the archiving process.
• The database must wait for the DBA to instigate archive, which can result in database lockups.
• Designing the size , frequency, and number of redo logs and cycles requires additional planning.

Page 518

In automatic archiving

• The database controls the archiving process.
• Free space and the archive destination device must be available. Otherwise, the database locks up and waits for the archive.
• Handling the volume of continuous archive logs requires additional capacity planning and management.

Managing Archive Logs

An integral part of keeping a handle on Archive Log mode is managing the archive files. As discussed, when a database is in Archive Log mode, the contents of each redo log is archived to a file in the designated archiving destination as each redo log becomes full. After a redo log is archived, it can be reused. If the archiving destination is full, the database can no longer write to the specified destination. In turn , the next redo log cannot be written to, which ultimately causes the database to come to a halt, disallowing further transactional activity.

As the DBA, you must implement some sort of process to manage the archive logs. Your objective should be to keep plenty of space free in the archiving destination to allow room for new files. There are two simple ways to do this. One method is to copy the archive logs to a tape device. After the copy has been verified , the original archive logs may be removed from the archiving destination. The other way is to copy the files to another disk until a backup can be made. If an FTP utility is available, you might find yourself using FTP to transfer the archive logs to another machine and then backing them up to tape. This would provide two backups of the archive logs. If you are running Oracle on a UNIX platform, you can schedule scripts in the crontab to copy your archive logs and then remove the original ones to free space in the archiving destination.

CAUTION

Treat an archive log as any other database file. Protect archive logs and ensure that they are included as part of the backup routine. All it takes is the unavailability of one archive log to disable a proper recovery. Additionally, never remove an archive log until you have verified a successful backup or copy to another filesystem.

NOARCHIVELOG Mode

NOARCHIVELOG mode is the default mode used by an Oracle RDBMS instance. In this mode, no archival of the redo logs is made and no special handling is required. However, the DBA needs to guard against disaster scenarios like the one described earlier. Usually, the only databases run in NOARCHIVELOG mode are those that do not have a high volume of transactions, such as decision support databases that contain only summarized information from other applications systems. It is important to ensure that backups are made more often than the redo logs are cycled.

Page 519

Archive Log Mode Versus NOARCHIVELOG Mode

In Archive Log mode

• Additional disk space is required.
• Managing the archive logs entails additional administrative overhead.
• Hot backups are available.
• A complete database recovery can be performed in the event of a media failure.

In NOARCHIVELOG mode

• No additional disk space or overhead is required.
• Only cold backups can be used.
• All the work done since the last backup is lost in the event of a failure.

NOTE

Although you have the option to copy archive logs directly to tape (such as 4mm DAT), it is better to copy the archive to disk and to copy the disk to tape. Aside from the obvious issue of speed, disks tend to be more reliable than tapes. Copying a redo log to disk and then to tape provides a much more resilient backup method.

Requirements for Backups

In addition to ensuring that the required transactional information is available for recovery, you must make routine backups of the database. The backup procedure for an RDBMS is more complicated than simply making copies at the operating system level.

What Is a Database?

In The Wizard of Oz, the Wizard tells Dorothy, "Pay no attention to that man behind the curtain." The same admonishment applies to the overall functionality of the Oracle RDBMS instance.

A database is simply a collection of physical data files. The RDBMS provides a sophisticated set of programs that hide the details of the processing from the world, and enable programmers and users to view this data as tables, views, indexes, and clusters. The truth, though, is that Oracle, like the early flat-file databases that preceded it, does nothing more extravagant than store information in files. The man behind the curtain stands revealed.

Well, almost.

Although all the information stored by the Oracle RDBMS resides in physical data files, the information is accessible only through the tools and utilities provided by Oracle. To attempt

Previous Table of Contents Next