Databases Reference
In-Depth Information
Having these explanations in mind, now assume that the status of the online redo log groups in Figure
3-1
is
as follows:
Group 1: Current
Group 2: Active
Group
3
: Inactive
With this information, suppose one member (or even both) of the online redo log group is damaged. Let's see
the consequences. You can find a more detailed description of the redo log failure in Chapter 14; we will look at only
one scenario here. Member g3m1 of Group 3 gets damaged. Since this member is INACTIVE, it has no impact on
the database operation. But when the current log group gets filled, Group 3 must be available, so we need to fix the
damaged member now. The solution is really simple. Since the other member of the group—g3m2—is in a different
part of our storage, in the fast recovery area, that is most likely intact. We can copy it over the damaged file and be on
our way:
$ cp g3m2 g3m1
No other action is required. Had g3m2 been on the same storage area as g3m1, then the probability of g3m2
being intact would have been much less because it would have been prone to the same failure that affected g3m1.
So, there is a strong reason to place redo log group members on different storage areas, even if one of them is not the
fast recovery area. Since we are assuming in case of database failure that the fast recovery area might survive, keeping
one member of the redo log groups will reduce the chances of failure of both members of the online redo log group.
Disadvantages of Placing One Member of the Online Redo Log Group in FRA
Putting members of the redo log groups in the fast recovery area is not a slam-dunk decision either. Let's revisit the
scenario in Figure
3-1
. Suppose that one member—g1m1—of Group 1 fails. Since the group is now current, the failure
of the member will cause a failure in the database, and the database instance will abort.
You can correct the situation by copying the intact member of the online redo log group to the damaged member
and starting the database. Since we describe the process of recovery in case of redo log failure in detail in Chapter 14,
we will skip the details here. The important point to understand is that the sole reason of success in re-creating the
redo log member was because we had an intact copy. Keeping one member of the log file group in the fast recovery
area improves the odds of that, as shown in the previous section. However, on the flip side, the failure of a current redo
log member temporarily shuts the database down, even if you can repair it and bring the database up quickly. This
creates a denial-of-service situation and should be avoided at all costs. Prevention of the loss is the key, not the repair
afterward. The fast recovery area is usually built on cheaper, less reliable disks and is more prone to failure than the
more reliable database disks. Therefore, putting even one member of the redo log group there increases your chances
of failure.
So, in summary, you should decide with care to place a member of the redo log group on the fast recovery area.
You can use the decision grid shown in Table
3-4
to support your decision.
Table 3-4.
Decision Grid to Decide Placement of One Redo Log Member on the FRA
Reliability of the Disk Under
Risk of Temporary Database
Failure the Fast Recovery Area
Acceptable
Not Acceptable
Low
Yes
No
High
Maybe
Yes
