Query the V$RECOVERY_PROGRESS view to monitor and assess Redo Apply 
performance. This view contains the following columns: 
 
V$RECOVERY_PROGRESS 
 
COLUMN DESCRIPTION 
Average 
Apply Rate 
 Redo Applied / Elapsed Time includes time spent actively applying redo and 
time spent waiting for redo to arrive 
Active 
Apply Rate 
 Redo Applied / Active Time is a moving average over the last 3 mins. 
Excludes time spent waiting for redo to arrive. 
Apply 
Time/Log 
 Active apply time averaged per redo log file. 
Checkpoint 
Time/Log 
 Log boundary checkpoint time averaged per redo log file 
Last 
Applied 
Redo 
 SCN and timestamp of the last redo applied. This is the time as stored in 
the redo stream and used to compare where the standby database is 
relative to the primary. 
 
The most useful statistic is the Active Apply rate because the Average Apply Rate 
includes idle time spent waiting for redo to arrive, making the Average Apply Rate 
a poor indicator of apply performance. 
In a Data Guard physical standby environment, it is important to determine if the 
standby database can recover redo as fast as, or faster than, the primary database 
can generate redo. The simplest way to determine application throughput in terms 
of redo volume is to collect Automatic Workload Repository (AWR) reports on the 
primary database during normal and peak workloads, and determine the number of 
bytes per second of redo data the production database is producing. You can then 
compare the speed at which redo is being generated with the Active Apply Rate 
columns in the V$RECOVERY_PROGRESS view to determine if the standby 
database is able to maintain the pace. 
It is not necessary to tune redo apply If the standby database is able to keep pace 
with the primary database during peak periods. If your examination of the 
performance statistics described above indicate that redo apply cannot keep pace, 
and that the resulting apply lag is not the result of an archive log gap, then proceed 
with tuning as described below.