Files - Expert Oracle Database Architecture - page 114

• Lots of users modifying the same blocks : Here you might want large redo log files. Since
everyone is modifying the same blocks, you'd like to update them as many times as possible
before writing them out to disk. Each log switch will fire a checkpoint, so you'd like to switch
logs infrequently. This may, however, affect your recovery time.

• Mean time to recover : If you must ensure that a recovery takes as little time as possible, you
may be swayed toward smaller redo log files, even if the previous point is true. It will take less
time to process one or two small redo log files than a gargantuan one upon recovery. The
overall system will run slower than it absolutely could day to day perhaps (due to excessive
checkpointing), but the amount of time spent in recovery will be shorter. There are other
database parameters that may also be used to reduce this recovery time, as an alternative to
the use of small redo log files.

Archived Redo Log
The Oracle database can run in one of two modes: ARCHIVELOG mode and NOARCHIVELOG mode. The difference
between these two modes is simply what happens to a redo log file when Oracle goes to reuse it. “Will we keep a copy
of that redo or should Oracle just overwrite it, losing it forever?” is an important question to answer. Unless you keep
this file, you can't recover data from a backup to that point in time.
Say you take a backup once a week on Saturday. Now, on Friday afternoon, after you have generated hundreds of
redo logs over the week, your hard disk fails. If you have not been running in ARCHIVELOG mode, the only choices you
have right now are as follows:

• Drop the tablespace(s) associated with the failed disk. Any tablespace that had a file on that

disk must be dropped, including the contents of that tablespace. If the SYSTEM tablespace
(Oracle's data dictionary) or some other important system-related tablespace like your UNDO
tablespace is affected, you can't do this. You will have to use the next option instead.

• Restore last Saturday's data and lose all of the work you did that week.

Neither option is very appealing. Both imply that you lose data. If you had been executing in ARCHIVELOG mode,
on the other hand, you simply would have found another disk and restored the affected files from Saturday's backup
onto it. Then, you would have applied the archived redo logs and, ultimately, the online redo logs to them (in effect
replaying the week's worth of transactions in fast-forward mode). You lose nothing. The data is restored to the point of
the failure.
People frequently tell me they don't need ARCHIVELOG mode for their production systems. I have yet to meet
anyone who was correct in that statement. I believe that a system is not a production system unless it is in ARCHIVELOG
mode. A database that is not in ARCHIVELOG mode will, someday, lose data. It is inevitable ; you will lose data
(not might, but will ) if your database is not in ARCHIVELOG mode.
“We are using RAID-5, so we are totally protected” is a common excuse. I've seen cases where, due to a
manufacturing error, all disks in a RAID set froze, all at about the same time. I've seen cases where the hardware
controller introduced corruption into the data files, so people safely protected corrupt data with their RAID devices.
RAID also does not do anything to protect you from operator error, one of the most common causes of data loss. RAID
does not mean the data is safe, it might be more available, it might be safer , but data solely on a RAID device will be
lost someday; it is a matter of time.
“If we had the backups from before the hardware or operator error and the archives were not affected, we could
have recovered.” The bottom line is that there is no excuse for not being in ARCHIVELOG mode on a system where the
data is of any value. Performance is no excuse; properly configured archiving adds little to no overhead. This, and the
fact that a fast system that loses data is useless, means that even if archiving added 100 percent overhead, you still
need to do it. A feature is overhead if you can remove it and lose nothing important; overhead is like icing on the cake.
Preserving your data, and making sure you don't lose your data isn't overhead—it's the DBA's primary job!
Only a test or maybe a development system should execute in NOARCHIVELOG mode. Most development systems
should be run in ARCHIVELOG mode for two reasons: