Register Missing Log File in Oracle Data Guard Database

calendar Oct 26, 2025 / · 6 min read · Oracle Database Data Guard Archive Logs Physical Standby Database Recovery DBA Scripts Gap Resolution Log Management V$ARCHIVED_LOG  ·
Share on: linkedin copy

Register Missing Log File in Oracle Database

The ALTER DATABASE REGISTER PHYSICAL LOGFILE command is used to manually register archived redo log files in an Oracle Data Guard environment, specifically for physical standby databases. This command becomes essential when automatic log registration fails or when gaps occur in the archive log sequence on standby databases.

Purpose

This SQL command serves a critical role in Oracle Data Guard configurations by allowing database administrators to manually register archived redo log files that were not automatically registered by the standby database. The primary purpose is to resolve gaps in the archive log sequence, ensuring that the standby database remains synchronized with the primary database and can successfully apply all redo data. When the automatic gap resolution mechanism fails or when logs are manually copied to the standby location, this command enables the control file to recognize and catalog these log files for recovery operations.

SQL Code

1alter database register physical logfile '<fullpath/filename>';

Breakdown of Code

The command consists of several components that work together to register a missing log file in the database control file:

ALTER DATABASE - This is the main DDL statement that modifies database-level settings and configurations. It requires the database to be in a mounted state for standby operations.

REGISTER - This keyword instructs Oracle to add an entry for the specified log file into the control file's archive log catalog. The registration process makes the database aware of the log file's existence and location.

PHYSICAL - This specifies that the log file being registered is for a physical standby database rather than a logical standby. Physical standby databases maintain an exact block-by-block copy of the primary database.

LOGFILE - This indicates that an archived redo log file is being registered, not a data file or other database object.

'<fullpath/filename>' - This is the complete file system path and filename of the archived log file to register. The path must follow operating system file naming conventions and point to an existing file.

Key Points

Manual Gap Resolution - When automatic gap resolution fails in Data Guard environments, administrators must manually copy missing archive logs from the primary database to the standby location and register them using this command. This is particularly common during network interruptions or when the FAL (Fetch Archive Log) mechanism cannot retrieve missing sequences.

Database State Requirements - The standby database must be in a mounted state (not open) when executing this command. This ensures the control file can be safely updated with the new log file information.

Sequential Application - After registering missing logs, they must be registered in sequence order to maintain consistency. The managed recovery process will then automatically apply these logs once they are properly registered.

Control File Updates - The REGISTER command only updates the control file to recognize the log file; it does not physically move or copy files. The actual log file must already exist at the specified location before registration.

Common Use Cases

Standby Database Out of Sync - When a physical standby database falls behind the primary due to network issues, deleted logs, or transport failures, administrators identify the missing sequence numbers and manually register each required archive log. This typically happens when querying V$ARCHIVED_LOG reveals gaps in the applied sequences.

After Manual Log Transfer - When archive logs are manually copied to the standby site using scripts or file transfer methods rather than automatic shipping, each transferred log must be registered before the managed recovery process can apply it. This scenario is common in environments with limited network bandwidth or security restrictions.

Post-Backup Restoration - After restoring archive logs from backup to the standby database location, registration is required to make these logs available for recovery operations. This situation occurs when gaps cannot be automatically resolved because the logs no longer exist on the primary database.

Verification Steps

After registering log files, administrators should verify successful registration by querying the V$ARCHIVED_LOG view to confirm the log appears with the correct sequence number. The view's APPLIED column should eventually change from 'NO' to 'YES' once managed recovery processes the registered log. Additionally, checking the V$MANAGED_STANDBY view ensures the MRP (Managed Recovery Process) is actively applying logs.

Best Practices

Always verify log file integrity before registration using checksums or RMAN validation to ensure the file is not corrupted. Register logs in strict sequence order to prevent apply errors. Monitor the alert log on both primary and standby databases for registration and apply errors. Consider using Oracle 18c and later versions which offer automated gap resolution with the RECOVER STANDBY DATABASE FROM SERVICE command, reducing the need for manual registration. Keep backup copies of all archive logs on the primary site until confirmed successful application on the standby.

Example with Multiple Logs

1alter database register physical logfile '/u01/oracle/arch/arch_1_101.arc';
2alter database register physical logfile '/u01/oracle/arch/arch_1_102.arc';
3alter database register physical logfile '/u01/oracle/arch/arch_1_103.arc';

After registration, start managed recovery to apply the logs:

1ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Troubleshooting

If logs fail to apply after registration, check the alert log for specific error messages related to sequence gaps or file corruption. Verify that the log file path is accessible and the Oracle process has read permissions. Ensure the sequence number matches the gap identified in V$ARCHIVED_LOG. If problems persist, consider using incremental backup-based recovery as an alternative approach to resynchronize the standby database.

References

Posts in this series