Introduction

A Data Guard standby can be online and still have a recovery problem.

A healthy standby should be checked from several perspectives:

  • Database role

  • Redo transport

  • Redo apply

  • Transport lag

  • Apply lag

  • Archive gaps

  • Standby redo logs

  • Database connectivity

  • Storage

  • Data Guard Broker status

Checking only whether the standby database is running is not enough.

Check the Database Role

Start by confirming the role and open mode.

SELECT
    name,
    db_unique_name,
    database_role,
    open_mode,
    protection_mode,
    protection_level
FROM v$database;

On a physical standby, the expected role is normally:

PHYSICAL STANDBY

The open mode depends on the configuration and whether Active Data Guard is being used. The first check should confirm that the database is in the expected role and state.

Check Data Guard Processes

On the standby, check the Data Guard processes.

SELECT
    process,
    status,
    thread#,
    sequence#
FROM v$managed_standby;

Depending on the Oracle Database version and configuration, processes such as the following may appear:

RFS
MRP0
ARCH

RFS receives redo from the primary. MRP0 is associated with managed recovery on a physical standby. The process status should be interpreted together with transport and apply information.

Check Apply Status

One of the most important standby checks is whether redo apply is running.

SELECT
    process,
    status,
    thread#,
    sequence#
FROM v$managed_standby
WHERE process LIKE 'MRP%';

If the managed recovery process is not running when it should be, investigate why redo apply has stopped. Possible causes include:

  • Missing archived logs
  • Datafile problems
  • Configuration issues
  • Network problems
  • Recovery errors
  • Manual intervention The alert log and Data Guard-related views should be checked for the specific error.

Check Apply Lag

Apply lag shows how far the standby is behind the primary from an apply perspective.

SELECT
    name,
    value,
    time_computed,
    datum_time
FROM v$dataguard_stats
WHERE name IN (
    'transport lag',
    'apply lag',
    'apply finish time'
);

Two values are particularly important:

transport lag
apply lag

Transport lag indicates delay in getting redo from the primary to the standby. Apply lag indicates delay in applying the received redo. These represent different parts of the redo flow.

Understand the Redo Flow

A simplified Data Guard redo path is:

Primary
   |
   v
Redo Transport
   |
   v
Standby RFS
   |
   v
Standby Redo Logs
   |
   v
Redo Apply
   |
   v
Standby Database

A problem can occur at any point in this path. For example:

Primary
   |
   X
Transport problem

is different from:

Primary
   |
   v
Standby
   |
   X
Apply problem

The lag metrics help determine where to investigate.

Check Archive Gaps

An archive gap can prevent the standby from applying redo. Check for gaps with:

SELECT
    thread#,
    low_sequence#,
    high_sequence#
FROM v$archive_gap;

If rows are returned, investigate the missing archive sequences. A gap should not simply be ignored because the standby database is still open. The missing redo may prevent recovery from progressing.

Check Received and Applied Redo

For a physical standby, compare the received and applied redo sequences.

SELECT
    thread#,
    sequence#,
    applied,
    completion_time
FROM v$archived_log
WHERE thread# = 1
ORDER BY sequence# DESC
FETCH FIRST 20 ROWS ONLY;

The APPLIED column helps identify whether archived redo has been applied. For RAC environments, remember that multiple redo threads may exist. Check each relevant thread when evaluating redo progress.

Standby Redo Logs

Standby redo logs are an important part of redo transport and real-time apply configurations. Check the standby redo log configuration with:

SELECT
    group#,
    thread#,
    sequence#,
    bytes / 1024 / 1024 AS size_mb,
    status
FROM v$standby_log
ORDER BY thread#, group#;

Verify that the standby redo logs are:

  • Present
  • Correctly sized
  • Assigned to the expected threads
  • Available for use The exact number required depends on the Data Guard configuration and redo threads.

Check Archive Destinations

On the primary, review the configured archive destinations.

SELECT
    dest_id,
    status,
    destination,
    target,
    error,
    gap_status,
    synchronized,
    synchronization_status
FROM v$archive_dest
WHERE target = 'STANDBY';

The ERROR column is particularly useful. A destination can be configured but still have an active transport problem. Always check both the status and the error information.

Check Standby Connectivity

Data Guard depends on reliable Oracle Net connectivity between the primary and standby. Basic checks should include:

  • Listener availability
  • Service resolution
  • TNS connectivity
  • Firewall connectivity
  • Network latency
  • Required ports From the database perspective, archive destination errors can also reveal connectivity problems. For example:
SELECT
    dest_id,
    status,
    error
FROM v$archive_dest
WHERE target = 'STANDBY';

A transport error here should be investigated before looking at unrelated database parameters.

Check the Alert Log

The alert log should be part of a Data Guard health check. Look for messages related to:

  • Redo transport
  • Recovery
  • Archive gaps
  • Datafile errors
  • I/O errors
  • Network errors
  • Managed recovery
  • Broker Views can tell you the current state. The alert log often provides additional information about how that state was reached.

Data Guard Broker

If Data Guard Broker is configured, use it as another source of health information. From DGMGRL:

SHOW CONFIGURATION;

Then:

SHOW DATABASE VERBOSE '<standby_db_unique_name>';

Broker can expose configuration and status information for the Data Guard environment. A validation command can also be used:

VALIDATE DATABASE VERBOSE '<standby_db_unique_name>';

The exact output depends on the Oracle version and Broker configuration. Broker output should be considered together with the database views and alert logs.

Storage and FRA

A standby can stop receiving or applying redo because of storage problems. Check filesystem or ASM capacity and the Fast Recovery Area. For the database view:

SELECT
    name,
    space_limit / 1024 / 1024 AS limit_mb,
    space_used / 1024 / 1024 AS used_mb,
    space_reclaimable / 1024 / 1024 AS reclaimable_mb
FROM v$recovery_file_dest;

High FRA utilization can cause archive-related problems if space cannot be reclaimed. Storage checks should therefore be part of regular Data Guard monitoring.

A Simple Health Check

A basic health review can follow this order:

Database Role
      |
      v
Transport
      |
      v
Receive
      |
      v
Apply
      |
      v
Transport / Apply Lag
      |
      v
Archive Gap
      |
      v
Standby Redo Logs
      |
      v
Broker / Alert Log
      |
      v
Storage

This follows the actual redo path through the environment.

Switchover Readiness

A standby may be healthy for normal redo apply but still require additional checks before a switchover. Before planned role transitions, verify:

  • Transport is healthy
  • Apply is current
  • No archive gap exists
  • Required services are available
  • Standby redo logs are configured
  • Broker configuration is healthy
  • Application dependencies are understood A Data Guard health check and a switchover readiness check are related but are not exactly the same thing.

Conclusion

A Data Guard standby should be treated as an active recovery component, not simply another database instance. A useful health check verifies: Role → Transport → Receive → Apply → Lag → Gaps → Storage → Configuration The most important point is to understand where redo is in the process. If transport is delayed, investigate the primary-to-standby path. If redo is received but not applied, investigate the standby recovery process. If an archive gap exists, identify the missing redo. If storage or FRA capacity is low, resolve that before it affects recovery. Regular checks make it much easier to identify Data Guard problems before the standby is actually needed.