Normal ARCH Processing

Let us review the normal flow of events while ARCH copies the online redo log files to the archive destination. The normal processing of ARCH starts with the opening of the log file members. If none of the log file members can be opened, ARCH signals an error. Otherwise, all the members that can be opened are opened. For instance, if you have three members in a redo log file group and one is bad, ARCH opens the other two and proceeds with the archive process.
ARCH then reads the headers of the redo log file members and validates the information with the control file information. ARCH then reads a group of data blocks, verifies the blocks and copies them to the archive destination. In earlier versions of Oracle, the data was not verified and you did not know that you had a bad block until you did a restore, not the best time to be notified. ARCH does not check the contents of the data blocks.
ARCH rotates reading blocks from each log file. If a log file member is read successfully, the log file is noted as good. If the next log file member read fails, ARCH tries to read the corresponding blocks from the log file that was noted as good. If a log file member fails three times, it is considered bad and is not used for subsequent operations. If you have log file members on different drives, your disk IO is distributed among the drives. Let us review this process pictorially with a system containing two redo log groups and two members per group.

In Oracle, the ARCH (Archiver) process plays a crucial role in archiving redo log files to ensure data recoverability. The flow of events in normal archive processing can be described in the following steps:

1. Redo log file switch: When the current redo log file becomes full, Oracle performs a log switch. The filled redo log file is marked as inactive, and the database starts writing to the next available redo log file.
2. Check for Archive Log Mode: The ARCH process checks if the database is in Archive Log Mode. If the database is in No Archive Log Mode, no further action is taken. If the database is in Archive Log Mode, the process continues.
3. Archive destination: Oracle checks the configured archive log destinations using the LOG_ARCHIVE_DEST_n parameters (where n is a number from 1 to 31). These destinations can be local or remote and can have different attributes, like mandatory or optional.
4. Archiver process (ARCH) activation: If the database is in Archive Log Mode, the ARCH process is activated. The ARCH process is responsible for copying the inactive redo log files to the specified archive destinations.
5. Copy inactive redo log files: The ARCH process reads the inactive redo log files and copies them to the archive destinations in the form of archive log files. During this process, the inactive redo log files remain available for other processes, such as Oracle Recovery Manager (RMAN) or Oracle Data Guard.
6. Completion and status update: Once the ARCH process has successfully copied the redo log files to the archive destinations, it updates the control file to indicate that the redo log files have been archived. If there is an issue during the archiving process, the database raises an error, and the DBA must resolve the issue to ensure proper archiving.
7. Redo log file reuse: After the redo log files have been successfully archived, they become eligible for reuse. When the database needs to switch to a new redo log file and all the available redo log files have been used, the oldest archived redo log file will be overwritten.

The ARCH process in Oracle is essential for maintaining a consistent and recoverable database by archiving redo log files. Understanding the flow of events in normal archive processing helps DBAs ensure that the database is properly configured for archive logging and that the archiving process is functioning as expected.