A database can operate in two distinct modes: NOARCHIVELOG mode (media recovery disabled) or ARCHIVELOG mode (media recovery enabled). The database mode has a profound impact on your backup and recovery strategy.
This section contains these topics:
Learn Oracle - NOARCHIVELOG Mode
If a database is used in NOARCHIVELOG mode, then the archiving of the online redo log is disabled. Information in the control file indicates that archiving is not required for filled groups. Therefore, as soon as a filled group becomes inactive, the group is available for reuse by the LGWR process.
NOARCHIVELOG mode protects a database only from instance failure, not from media failure. Only the most recent changes made to the database, stored in the groups of the online redo log, are available for crash or instance recovery. These changes are sufficient for crash or instance recovery because Oracle will not overwrite an online log that may be needed until its changes have been recorded in the datafiles. However, it will not be possible to perform media recovery by applying archived redo logs.
Learn Oracle - ARCHIVELOG Mode
If an Oracle database operates in ARCHIVELOG mode, then the archiving of the online redo log is enabled. Information in a database control file indicates that a group of filled online redo log files cannot be reused by LGWR until the group has been archived.
The Following figure illustrates how the database's online redo log files are used in ARCHIVELOG mode and how the archived redo log is generated by the process archiving the filled groups (for example, ARC0 in this illustration).
ARCHIVELOG mode permits complete recovery from disk failure as well as instance failure, because all changes made to the database are permanently saved in an archived redo log.
Learn Oracle - Automatic Archiving and the Archiver Background Processes
Oracle DBA can configure an instance to have an additional background process, the archiver (ARCn), which automatically archives each group of online redo log files after it becomes an inactive redo log. Automatic archiving frees Oracle DBA from having to keep track of, and archive, filled groups manually. For this convenience alone, automatic archiving is the choice of most database systems that run in ARCHIVELOG mode. For heavy workloads, such as bulk loading of data, multiple archiver processes can be configured by setting the initialization parameter LOG_ARCHIVE_MAX_PROCESSES.
If Oracle DBA request automatic archiving at instance startup by setting the LOG_ARCHIVE_START initialization parameter, then Oracle starts the number of ARCn processes specified by LOG_ARCHIVE_MAX_PROCESSES during instance startup. Otherwise, the ARCn processes are not started when the instance starts up.
Oracle DBA can interactively start or stop automatic archiving at any time. If automatic archiving was not specified to start at instance startup, and if Oracle DBA subsequently start automatic archiving, then Oracle creates the ARCn background processes. ARCn then remains for the duration of the instance, even if automatic archiving is temporarily turned off and on again, although the number of ARCn processes can be changed dynamically by setting LOG_ARCHIVE_MAX_PROCESSES with the ALTER SYSTEM statement.
The archiver always archives groups in order, beginning with the lowest log sequence number. The archiver automatically archives filled groups as they become inactive. A record of every automatic archival is written in the ARCn trace file by the archiver process. Each entry shows the time the archive started and stopped.
If the archiver encounters an error when attempting to archive a log group (for example, due to an invalid or filled destination), then it continues trying to archive the group. An error is also written in the ARCn trace file and the alert-SID.log. If the problem is not resolved, then eventually all online redo log groups become full, yet not archived, and the system stalls because no group is available to LGWR. Therefore, if problems are detected, then you should either resolve the problem so that the archiver can continue archiving (such as by changing the archive destination) or manually archive groups until the problem is resolved.
Learn Oracle - Manual Archiving
If a database runs in ARCHIVELOG mode, then Oracle DBA can manually archive the filled groups of inactive online redo log files, as necessary, whether or not automatic archiving is enabled or disabled. If automatic archiving is disabled, then Oracle DBA must manually archive filled groups.
For most database systems, automatic archiving is best because Oracle DBA do not have to watch for a group to become inactive and available for archiving. Furthermore, if automatic archiving is disabled and manual archiving is not performed fast enough, then database operation can be suspended temporarily whenever the log writer is forced to wait for an inactive group to become available for reuse.
The manual archiving option is provided so that Oracle DBA can:
When a group is archived manually, the user process issuing the statement to archive a group actually performs the process of archiving the group. Even if the archiver background process is present for the associated instance, it is the user process that archives the group of online redo log files.
- Archive a group when automatic archiving has been stopped because of a problem (for example, the offline storage device specified as the archived redo log destination has experienced a failure or become full)
- Archive a group in a non-standard fashion (for example, archive one group to one offline storage device, the next group to a different offline storage device, and so on)
- Rearchive a group if the original archived version is lost or damaged