Databases Reference
In-Depth Information
You must carefully decide whether you really want to create redo logs in the fast recovery area. The arguments
pro and con are the same as for the question of putting the control file in the FRA (see Recipe 3-8). Read up on those
arguments, and arrive at your own conclusion.
Advantages of Putting Redo Log Members in the FRA
In summary, the argument for putting at least one member of a redo log group in the fast recovery area hinges on the
assumption that the fast recovery area and the main database disks are located in such a way that the probability of
both going down at the same time is very slim, almost to the point of being negligible. You attain that probability by
putting the fast recovery area disks on a SAN or NAS other than where the main database is located. Even if the fast
recovery area and main database are both on the same SAN (or NAS), if they do not share the same physical disks,
then it further reduces the probability of simultaneous failure. The idea is to make sure that whatever causes the main
database disks to go down will not affect the fast recovery area disks. This way, should the main database disks get
corrupted, you can still access the backup of the database files in the fast recovery area.
With the assumption we've just described, the idea of putting one member of an online redo log group on the
fast recovery area ensures that at least one member of the group will still be available in case the main database disks
experience a failure. For instance, suppose your database has three log groups, each with two members, and one
member of each group is on the fast recovery area, as shown in Figure
3-1
.
Group 1
g1m1
g1m1
Group 2
g2m1
g2m2
g3m1
g3m2
Group 3
Main Database Storage
Flash Recovery Area
Figure 3-1.
Ideal placement of redo log members if FRA is used as a location
The members in Figure
3-1
are named in the following form: g<group#>m<member#>. Since the database is in
archivelog mode, each log file group can be in one of three states:
Current: The online redo log group is the current group. If the group fails, the database
immediately aborts with an error. If all the members of the group are damaged, then you
need to perform an incomplete recovery from previous backups.
Active: The group is not the current one, but it was earlier. Now it's being archived, and
that operation is not completed yet. If the group fails, the database is not halted, but the
log file will not have been archived, and any subsequent recovery operation will stop at
this group. When an active group fails, you should take a fresh backup of the database so
that you do not need to roll forward from a previous backup with archived redo logs. You
don't want the rollforward operation to be dependent upon a failed group.
Inactive: The group is not current now, and it has already been archived. The loss of this
group does not affect database operations, and it doesn't affect any recovery that you
might perform in the future.
