Oracle's archivelog mode is a safety mechanism whereby
Oracle can "roll forward", by applying the "after images" of
all changed rows. It is where the entries in redo logs are
saved prior to the point in time where a new incarnation of the log
overwrites the previous log. Internally, Redo is a critical
recovery component, and its entries
contain changes to data, indexes and undo segments (as well as
commit markers and other 'housekeeping' items such as end-of-job
and commit checkpoints).
Archiving makes sure that the redo
component is protected. When in backup mode, some tablespace
redo entries are blocks rather than change vectors. Running in archivelog mode has some
significant overhead to an Oracle databases, especially those with
high DML activity. With this in mind, it is important to
remember that redo and archivelog mode are two different things.
Oracle archivelog mode was created back in the days
when disk failures were common and the ability to "replay" the DML
transactions was critical to disk failure recovery. The
decision to run in ARCHIVELOG vs. NOARCHIVELOG mode was a gamble,
weighing the additional overhead of managing and archiving the
Oracle redo logs, vs. he probability of an unrecoverable disk
However, times change. Today's
disks are far more reliable than ever before, and
triple-mirrored disks have a
mean-time-between-failures (MTBF) that is expressed
in centuries. We also see hardware-level disk
backups that ensure recoverability to a point in
time without data loss.
We also see the new
Solid State Disks with online backups to tape
and disk, and disk-level hot backups that can
reliably take incremental backups while he instance
is accepting updates. Some shops are also
using Oracle Streams replication and tools such as
Quest Shareplex to replicate Oracle databases in
real-time, further reducing the need to recover and
roll forward from Oracle redo logs.
I have heard of Oracle customers who
choose to run their databases in NOARCHIVELOG mode
because they are comfortable with their low-level of
risk from disk failure, and they take hardware-level
majority of Oracle databases require ARCHIVELOG mode
to ensure recoverability, and no Oracle professional
should consider turning on NOARCHIVELOG mode without
making management aware of the risks of disk failure
(the MTBF from the disk vendor), and the risks of
It is important to remember that
the need for disk recovery does not come solely from disk failure. In
fact, there are many different reasons for recovery to be required,
including such influences as security issues caused by developers working
in a production environment or improperly tested code in an application.
The risks of running in NOARCHIVELOG Mode
So what are the risks of running in NOARCHIVELOG
Mode? There are several areas where the archived redo logs
would be handy:
In a case where a singe table needs to be recovered.
corruption: A software corruption might occur in a
table or index structure.