The Achiver process makes a copy of each redo log file as it is filled, and stores that copy in an offline location.
It is possible to run an Oracle database without archiving the redo logs, but archiving enables up to the minute recovery from a failure, so most production databases take advantage of it. The following Slide Show demonstrates what the Archiver process does:
As changes are made to an Oracle database, a log of those changes is written to the redo log files.
As each redo log is filled, the archiver process will begin to copy it to the archive.
The archiver will more or less keep up with the log writer.
If the log writer gets far enough ahead to fill up all the redo log files, then database users will be forced to wait while the archiver copies another file.
When a database is running in archive log mode, then log writer will not overwrite a log file until it has been copied by the archiver.
Once a log file has been copied, processing will resume.
Like the Database Writer, you can have up to ten archiver processes running for a single instance in Oracle.
Multiple Archiver Processes
Oracle allows you to have up to ten Archiver processes running for a single Oracle instance. However, unlike the case with multiple database writer processes, you don't need to manually specify the number of Archiver processes to run.
The Log Writer process automatically invokes additional Archiver processes if the rate of change increases. When the rate of change slows again, the log writer process will terminate some of the extra Archiver processes.
If for some reason you want to exert manual control over the number of Archiver processes that run for a single instance, you can use the
initialization parameter. Placing the following line in your initialization file will cause the instance to start with four Archiver processes:
The name of the parameter is a bit misleading. Even though the word “MAX” is used, it really causes the instance to start with the specified number of Archiver processes. As with the database writer, prior versions of Oracle did not allow multiple Archiver processes. The previous abbreviation for the archiver was ARCH, and you will still see that used in some books.
Archiver Processes (ARCn)
The archiver process (ARCn) copies redo log files to a designated storage device after a log switch has occurred. ARCn processes are present only when the database is in ARCHIVELOG mode, and automatic archiving is enabled. An Oracle instance can have up to 10 ARCn processes (ARC0 to ARC9). The LGWR process starts a new ARCn process whenever the current number of ARCn processes is insufficient to handle the workload.
The alert log keeps a record of when LGWR starts a new ARCn process. If you anticipate a heavy workload for archiving, such as during bulk loading of data, you can specify multiple archiver processes with the initialization parameter
The ALTER SYSTEM statement can change the value of this parameter dynamically to increase or decrease the number of ARCn processes.
However, you do not need to change this parameter from its default value of 1, because the system determines how many ARCn processes are needed, and LGWR automatically starts up more ARCn processes when the database workload requires more.
Archiving is the operation of generating an archived redo log file. Archiving is either automatic or manual and is only possible when the database is in ARCHIVELOG mode. An archived redo log file includes the redo entries and the log sequence number of the identical member of the online redo log group.
The archived redo log contains a copy of every group created since you enabled archiving.
When Oracle is run in ARCHIVELOG mode, the ARC0-ARCt (Archiver) background processes make a copy of each redo log file before overwriting it. These archived redo log files are usually written to a disk device. The archived redo log files may also be written directly to a tape device, but this tends to be very operator-intensive. You can perform file system backups of a database while that database is open, provided the database is running in ARCHIVELOG mode. An online backup involves setting each tablespace (or the entire database) into a backup state, backing up the related datafiles, and then restoring the tablespaces to their normal state.