How to Fix “ORA-01111: Name for Data File Is Unknown” in Oracle Standby Databases

One of the most common errors DBAs encounter during standby database recovery is the ORA-01111 message that appears along with ORA-01110 and ORA-01157. These errors can interrupt the recovery process, leaving your standby database out of sync.

If you’ve seen something like this during a RECOVER STANDBY DATABASE command:

SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01111: name for data file 16 is unknown - rename to correct file
ORA-01110: data file 16: '/u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016'
ORA-01157: cannot identify/lock data file 16 - see DBWR trace file

Don’t worry — this is a known behavior in Oracle Data Guard environments and can be fixed with a few steps.

---

Understanding the Error

When you see:

ORA-01111: name for data file 16 is unknown - rename to correct file
ORA-01110: data file 16: '/u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016'

It means Oracle has detected a placeholder datafile on the standby database.
This unnamed datafile (UNNAMED00016) is automatically created when a new datafile is added to the primary database, but the standby file management mode is set to MANUAL — or there wasn’t enough space to create it.

Essentially, Oracle knows a new datafile exists on the primary but cannot create it on the standby, so it marks a placeholder entry.

---

Root Cause

This issue typically happens in one of the following situations:

1. standby_file_management is set to MANUAL
   When manual mode is active, Oracle does not automatically create new datafiles on the standby after you add them on the primary.
2. Insufficient space or permission issues
   If the ASM or filesystem on the standby does not have enough space or lacks permission, Oracle fails to create the datafile, defaulting to UNNAMED####.
3. File path mismatch between primary and standby
   The directory structure may differ, preventing automatic file creation.

---

Quick Example Scenario

• Primary Database: PROD
• Standby Database: STBY
• PDB (Pluggable Database): PDB01
• Missing Datafile: 16 → /u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016

---

Step-by-Step Solution

Follow these steps carefully to resolve the error.

Step 1: Identify the Unnamed Datafile

Run the following query on your standby database:

SQL> SELECT CON_ID, NAME 
FROM v$datafile 
WHERE NAME LIKE '%UNNAMED%';

Output example:

CON_ID     NAME
----------- ------------------------------------------------------------
4           /u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016

---

Step 2: Switch to Manual Mode

Before modifying anything, change the standby file management mode to manual:

SQL> ALTER SYSTEM SET standby_file_management='MANUAL';

This step ensures you can safely create or rename the file without Oracle automatically interfering.

---

Step 3: Connect to the Correct Container

If you’re using a multitenant architecture (CDB/PDB), switch to the affected container:

SQL> ALTER SESSION SET CONTAINER=PDB01;

You must be in the correct pluggable database to execute the datafile creation command.

---

Step 4: Create the Missing Datafile

Now, manually create the datafile to replace the UNNAMED entry.
Use the correct ASM or filesystem location available on your standby:

SQL> ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016' AS '+DATA' SIZE 1G;

SQL> ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016' AS new;

Explanation:

• The first path (/u01/.../UNNAMED00016) is the placeholder.
• The AS clause defines the new correct location.
• The SIZE value can match or exceed the original datafile on the primary.

If you’re using ASM, ensure the disk group name (+DATA) exists and has sufficient space.

---

Step 5: Switch Back to Root Container

Return to the CDB root to restore the default context:

SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;

---

Step 6: Set Standby File Management Back to AUTO

After successful datafile creation, switch back to automatic mode:

SQL> ALTER SYSTEM SET standby_file_management='AUTO';

This enables automatic file management for future file additions.

---

Step 7: Resume Recovery

Now restart the recovery process:

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Monitor the recovery process and ensure no more UNNAMED files exist.

---

Verification

You can confirm the fix by running:

SQL> SELECT name FROM v$datafile WHERE name LIKE '%UNNAMED%';

If the query returns no rows, the issue has been resolved.

Additionally, check Data Guard synchronization:

SQL> SELECT sequence#, applied FROM v$archived_log ORDER BY sequence#;

Ensure logs are being applied successfully without error.

---

Pro Tips for DBAs

Always keep standby_file_management set to AUTO
This avoids manual intervention when adding datafiles on the primary.

ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;

Monitor alert logs
Both primary and standby alert logs will record UNNAMED file creation attempts.

Use consistent directory structures
Ensure both primary and standby databases have identical mount points or ASM disk group paths.

Automate checks with scripts
Periodically check for UNNAMED datafiles using cron jobs or OEM alerts.

Ensure space availability
Always verify free space on the standby disk group before adding datafiles to the primary.

---

Example of Complete Fix

Here’s the summarized command sequence:

SQL> SELECT CON_ID, name FROM v$datafile WHERE name LIKE '%UNNAMED%';
SQL> ALTER SYSTEM SET standby_file_management='MANUAL';
SQL> ALTER SESSION SET CONTAINER=PDB01;
SQL> ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/19.0.0/dbhome_1/dbs/UNNAMED00016' AS '+DATA' SIZE 1G;
SQL> ALTER SESSION SET CONTAINER=CDB$ROOT;
SQL> ALTER SYSTEM SET standby_file_management='AUTO';
SQL> RECOVER STANDBY DATABASE;

---

Conclusion

The ORA-01111 and ORA-01157 errors are indicators that your standby database couldn’t automatically create a new datafile.
By identifying the UNNAMED file, setting the standby_file_management mode correctly, and manually creating the missing datafile, you can restore Data Guard synchronization and resume recovery smoothly.

Following these steps ensures your Oracle standby environment remains consistent, reliable, and resilient against such interruptions.