Data Guard Stuck After New PDB Creation in Oracle AI Database 26ai – Root Cause and Fix ORA-01110

Creating a new Pluggable Database (PDB) on a primary database is usually a routine task. However, in Oracle AI Database 26ai, DBAs often face an unexpected issue where Data Guard recovery on the physical standby gets stuck immediately after a new PDB is created on the source.

This article walks through a real production scenario, explains why Data Guard breaks, and shows the exact steps to fix ORA-19723 and UNNAMED datafile issues safely — without rebuilding the standby.

---

Problem Overview

After creating a new PDB (SALSE_PDB) on the primary database, managed recovery on the physical standby (teststby) stopped and began reporting errors similar to the following:

ORA-19723: cannot re-create plugged in data file 13
ORA-01111: name for data file 13 is unknown
ORA-01110: data file 13: '/u01/app/oracle/product/23.26.0.0/dbhome_1/dbs/UNNAMED00013'
ORA-27037: unable to obtain file status
Linux Error: No such file or directory

At this point:

• Redo transport is working
• Managed recovery is stuck
• The standby database cannot apply changes for the new PDB

---

Why This Happens

This issue occurs due to a timing and configuration mismatch during PDB creation.

Root Causes

1. New PDB created on primary
2. New datafiles generated for the PDB
3. Standby attempts to create matching datafiles
4. standby_file_management is not set to AUTO
5. Oracle creates a placeholder file: UNNAMED00013
6. Recovery halts because Oracle cannot map the datafile correctly

This is not a bug — it’s expected behavior when standby automation is incomplete.

---

Symptoms You’ll See

• Data Guard configuration shows DISABLED
• Managed recovery stops silently
• Standby alert log reports UNNAMED datafiles
• PDB remains in MOUNTED state on standby
• ALTER DATABASE CREATE DATAFILE ... AS NEW fails with ORA-19723

---

Failed Attempt: Manual Datafile Creation

A common first reaction is to manually create the datafile:

alter database create datafile
'/u01/app/oracle/product/23.26.0.0/dbhome_1/dbs/UNNAMED00013'
as NEW;

❌ This fails with:

ORA-19723: cannot re-create plugged in data file

Why?
Because this datafile belongs to a plugged-in PDB, and Oracle does not allow manual recreation in this scenario.

---

Correct Fix: Step-by-Step Solution

Step 1: Check PDB Status on Standby

show pdbs;

Output shows the new PDB stuck in MOUNTED mode:

CON_ID  CON_NAME    OPEN MODE
4       SALSE_PDB  MOUNTED

---

Step 2: Switch to the Affected PDB

alter session set container=SALSE_PDB;

---

Step 3: Offline and Drop the UNNAMED Datafile

This tells Oracle to forget the broken placeholder.

alter database datafile '/u01/app/oracle/product/23.26.0.0/dbhome_1/dbs/UNNAMED00013' offline drop;

✅ This command succeeds and clears the blockage.

---

Step 4: Enable Automatic Standby File Management

This is the most critical fix.

alter system set standby_file_management='AUTO';

Without this parameter, every new PDB or datafile can break Data Guard again.

---

Data Guard Broker State Check

At this point, the broker may show the configuration as DISABLED.

dgmgrl /

show configuration;

Output:

DGMGRL> show configuration

Configuration - PROD to STBY

  Protection Mode: MaxPerformance
  Members:
  test     - Primary database
    teststby - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
DISABLED

Re-enable the configuration

enable configuration;

---

Restart Managed Recovery

Oracle automatically resumes recovery once the file issue is resolved:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY

You’ll see logs like:

• Parallel media recovery started
• Standby redo logs applied
• New PDB datafiles created automatically in ASM
• TEMP tablespaces dropped and recreated
• UNDO and USERS tablespaces synchronized

---

Confirmation in Alert Log

Successful recovery messages include:

SALSE_PDB(4): Successfully added datafile 14
SALSE_PDB(4): Successfully added datafile 15
SALSE_PDB(4): Successfully added datafile 16
Recovery successfully copied files for SYSTEM, SYSAUX, UNDOTBS1

This confirms:

• The new PDB is fully synchronized
• Data Guard is healthy
• No rebuild is required

---

Best Practices to Prevent This Issue

Always Set This on Standby

standby_file_management='AUTO'

Before Creating New PDBs on Primary

• Ensure managed recovery is running
• Verify sufficient space in ASM / FRA
• Monitor standby alert log during PDB creation

After Creating a PDB

• Check show pdbs on standby
• Confirm PDB opens automatically after recovery

---

Key Takeaways

• UNNAMED datafiles after PDB creation are configuration issues, not corruption
• Never manually recreate PDB datafiles
• Dropping the UNNAMED file and letting recovery re-create it is the correct approach
• Oracle AI Database 26ai handles this cleanly when properly configured
• No Data Guard rebuild is needed if handled correctly

---

Final Thoughts

Oracle AI Database 26ai Data Guard is extremely resilient, but PDB operations require correct standby automation. A single missing parameter can stop recovery — yet the fix is simple once you understand what’s happening internally.

This scenario is a perfect example of why real-world DBA experience matters more than theory.