MAA - Oracle 10gR2 Redo Transport and Network Best Practices

Maximum Availability Architecture
select 'Instance'||thread#||': Last Applied='||max(sequence#)||'
resetlogs_change#='||resetlogs_change#||')'
from v$archived_log
where applied = (select decode(database_role, 'PRIMARY', 'NO', 'YES')
from v$database)and thread# in (select thread# from gv$instance)
and resetlogs_change# = (select resetlogs_change# from v$database)
group by thread#, resetlogs_change#
order by thread#;
The above query will return the latest sequence applied on the standby as well as
the latest sequence archived on the primary database for each thread. There is an
archive log gap if the last applied sequence on the standby is one or more
sequences behind the latest archived on the primary.
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
Active
Apply Rate
Apply
Time/Log
Checkpoint
Time/Log
Last
Applied
Redo
Redo Applied / Elapsed Time includes time spent actively applying redo and
time spent waiting for redo to arrive
Redo Applied / Active Time is a moving average over the last 3 mins.
Excludes time spent waiting for redo to arrive.
Active apply time averaged per redo log file.
Log boundary checkpoint time averaged per redo log file
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
Oracle Active Data Guard: Oracle Data Guard 11g Page 29