Diagnosing & Fixing UNNAMED Datafile Errors in Oracle Data Guard
When MRP halts on the standby because it cannot auto-create a datafile added on the primary,
Oracle registers it as an UNNAMED000xx placeholder.
This guide walks through root cause, diagnosis, and a verified resolution path.
What Triggers This Problem?
Oracle Data Guard keeps a standby database current by shipping and applying redo from the primary. When a DBA adds a tablespace or datafile on the primary, the standby's Managed Recovery Process (MRP) must create a matching physical file before it can replay the structural change. If it cannot — because of an incorrect path mapping, a missing directory, or a misconfigured parameter — Oracle does not fail silently. Instead it writes an UNNAMED000xx placeholder to the standby control file and deliberately halts MRP to protect data integrity.
The result is a trio of alert-log errors that look like this:
Three root causes account for the vast majority of cases:
- DB_FILE_NAME_CONVERT is wrong or absent — the standby cannot translate the primary path to a valid local path.
- STANDBY_FILE_MANAGEMENT is set to MANUAL — Oracle will not attempt automatic datafile creation at all.
- The target directory does not exist — the translated path is correct but the OS directory is missing, so file creation fails at the OS layer.
MRP pauses rather than skipping the file to ensure the standby never falls into an inconsistent state. Every redo record that references the new datafile would be unapplyable until the physical file exists, so halting is the only safe choice.
Step-by-Step Resolution
Locate the UNNAMED Datafile on the Standby
Query V$DATAFILE on the standby to retrieve the FILE# and the
placeholder path. You'll need the FILE# in every subsequent step.
| FILE# | NAME | STATUS |
|---|---|---|
| 4 | /u01/app/oracle/product/19.3.0/db_1/dbs/UNNAMED00004 | RECOVER |
Confirm the Source Datafile on the Primary
Use the same FILE# to look up the actual datafile path on the primary database. This is the canonical name Oracle expects when it applies redo.
Check Whether MRP Is Still Running
Before issuing any DDL, confirm MRP status. In most UNNAMED datafile scenarios MRP has already stopped. If it is still running you must cancel it first.
No rows means MRP has already stopped — proceed directly to Step 4.
If MRP is still listed, run
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; before continuing.
Create the Missing Standby Datafile
The ALTER DATABASE CREATE DATAFILE … AS … command atomically replaces the
UNNAMED placeholder in the standby control file and creates the physical file on disk.
Choose the variant that matches your storage configuration.
4a — File-System Standby (Non-ASM)
4b — ASM Standby (Non-OMF)
Specify the UNNAMED path from the ASM disk group and provide the fully qualified ASM alias for the new datafile.
4c — Oracle RAC Standby Using ASM (Non-OMF)
4d — Oracle Managed Files (OMF) — Single Instance or RAC
With OMF enabled, let Oracle name and place the file automatically using
AS NEW. The file lands in the location set by DB_CREATE_FILE_DEST.
Restart the Managed Recovery Process
With the physical file in place, restart MRP so the standby can resume applying redo and close the gap with the primary.
Validate the Datafile Status
Confirm the UNNAMED placeholder is gone and the file is registered as ONLINE.
| NAME | STATUS |
|---|---|
| /u01/app/oradata/STBYDB/newtbs04.dbf | ONLINE |
An ONLINE status confirms successful resolution. MRP will now apply redo records that reference this datafile, and the standby will catch up automatically.
Prevention Checklist
Addressing the error after it occurs is straightforward, but the right goal is never seeing it in the first place. These seven practices cover the main exposure points.
Keep STANDBY_FILE_MANAGEMENT = AUTO
This single parameter is responsible for enabling automatic datafile creation during redo apply. Verify it on every standby instance after provisioning.
Audit DB_FILE_NAME_CONVERT After Path Changes
Storage reorganisations on either side silently invalidate path-translation rules. Re-validate whenever directories change.
Pre-create OS Directories
Even a correct DB_FILE_NAME_CONVERT will produce an UNNAMED file if the translated OS path does not exist. Script directory creation as part of the standby build.
Use OMF on Both Sides
Oracle Managed Files removes manual path-mapping entirely. MRP uses AS NEW internally, making UNNAMED errors structurally impossible in most scenarios.
Monitor MRP After Structural Changes
After every ADD DATAFILE or CREATE TABLESPACE on the primary, query V$MANAGED_STANDBY within minutes to confirm MRP is still applying.
Review the Standby Alert Log Routinely
ORA-01111 appears in the alert log before MRP actually stops. Catching it early means resolving the issue during the same maintenance window.
Validate Sync After Every Structural DDL
Check V$ARCHIVE_GAP and V$DATAGUARD_STATUS after structural changes so any divergence is caught before it compounds.
Takeaways
The ORA-01111 / UNNAMED datafile error is Oracle's way of halting redo apply safely rather
than letting the standby drift into an inconsistent state. Once you know the FILE# and the
correct target path, the fix — ALTER DATABASE CREATE DATAFILE … AS … — takes
seconds to execute. The harder part is understanding why it happened so you do not
encounter it again.
Almost every instance of this error traces back to one of three misconfigurations: STANDBY_FILE_MANAGEMENT left at MANUAL, a stale or missing DB_FILE_NAME_CONVERT entry, or an OS directory that was never created on the standby host. Lock down those three items during the initial standby build and the UNNAMED placeholder becomes a rarely-seen edge case rather than a recurring incident.
ConversionConversion EmoticonEmoticon