ORA-16004: backup database requires recovery — What It Means and How to Fix It
ORA-16004 is an Oracle error that occurs when you attempt to back up a database — typically via RMAN — while the database has not yet completed its required recovery process. This most commonly surfaces in Data Guard / Standby Database environments or after an incomplete recovery on a Primary Database. Oracle intentionally blocks the backup to protect data integrity until the database is in a fully recovered, consistent state.
Top 3 Causes and Fixes
Cause 1: Standby Database Has Unapplied Archive Logs (MRP Not Complete)
If the Managed Recovery Process (MRP) on a Standby DB is stopped or lagging, the database is not fully synchronized, and RMAN will throw ORA-16004 when a backup is attempted.
Fix: Verify and restart MRP, then confirm sync before backup.
-- Check MRP status on Standby
SELECT PROCESS, STATUS, SEQUENCE#
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'MRP0';
-- Restart MRP if stopped
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
-- Check for archive log gaps
SELECT * FROM V$ARCHIVE_GAP;
-- Confirm apply lag is acceptable
SELECT NAME, VALUE
FROM V$DATAGUARD_STATS
WHERE NAME IN ('apply lag', 'transport lag');
-- Run RMAN backup only after MRP is active and lag is minimal
BACKUP DATABASE PLUS ARCHIVELOG;
Cause 2: Incomplete Recovery Without OPEN RESETLOGS
After performing a Point-in-Time Recovery or SCN-based recovery on a Primary DB, if ALTER DATABASE OPEN RESETLOGS is not executed before the backup job runs, Oracle considers the database still in recovery mode.
Fix: Complete the recovery with RESETLOGS, then immediately take a full backup.
-- Verify database state
SELECT STATUS, RESETLOGS_CHANGE#, RESETLOGS_TIME
FROM V$DATABASE;
-- Open database with RESETLOGS after incomplete recovery
ALTER DATABASE OPEN RESETLOGS;
-- Immediately take a full backup (strongly recommended after RESETLOGS)
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
-- Confirm backup job completed successfully
SELECT START_TIME, END_TIME, STATUS, INPUT_TYPE
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY START_TIME DESC
FETCH FIRST 3 ROWS ONLY;
Cause 3: RMAN Catalog / Control File Metadata Mismatch
If the RMAN catalog or control file metadata is out of sync with the actual database state — for example after a RESETLOGS event that wasn't followed by a catalog resync — Oracle may incorrectly flag the database as requiring recovery.
Fix: Resync the RMAN catalog and crosscheck backups.
-- Connect to RMAN with catalog
-- rman TARGET / CATALOG rman_user/password@catalog_db
-- Resync catalog metadata
RESYNC CATALOG;
-- Crosscheck all backups for consistency
CROSSCHECK BACKUP;
DELETE EXPIRED BACKUP;
-- List current backups to validate state
LIST BACKUP SUMMARY;
-- Validate database files without actually restoring
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
Quick Prevention Tips
1. Add a pre-backup health check to your RMAN scripts.
Before any scheduled backup runs, automatically query V$MANAGED_STANDBY, V$ARCHIVE_GAP, and V$DATAGUARD_STATS to confirm the Standby is healthy and fully caught up. Abort the backup job automatically if the apply lag exceeds a defined threshold (e.g., 30 minutes).
-- Sample pre-backup check
SELECT NAME, VALUE
FROM V$DATAGUARD_STATS
WHERE NAME = 'apply lag';
2. Always run RESYNC CATALOG after any RESETLOGS event.
Make it a hard rule in your operational runbook: every OPEN RESETLOGS must be followed immediately by a catalog resync and a full RMAN backup. This prevents metadata drift and eliminates false positives for ORA-16004.
-- Post-RESETLOGS mandatory steps
RESYNC CATALOG;
BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
Related Oracle Errors
| Error Code | Description |
|---|---|
| ORA-01113 | File needs media recovery — often seen alongside ORA-16004 |
| ORA-01194 | File needs more recovery to be consistent |
| ORA-16000 | Database open for read-only access (common on Standby) |
| RMAN-06026 | Some targets not found — catalog/DB mismatch |
📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.
Top comments (0)