# RMAN FRA Bloat After Non-CDB to CDB Migration
Issue Analysis and Resolution


# Issue Description

Following a Data Pump full export/import migration from Oracle 12c SE non-CDB to Oracle 19c SE2 CDB, the Fast Recovery Area (FRA) on `/b0` grew to **1.6 TB** against a **600 GB** source database.

The FRA was consuming nearly **3x the expected space**.

---

# Observed Symptoms

1. FRA usage: `1.6 TB total` across `/b0/fast_recovery_area`
2. Source database size: `~600 GB`
3. Expected backup footprint: `~600 GB` (1 image copy) + archivelogs
4. Actual backup footprint:

   * `695 GB` image copy
   * `841 GB` orphaned backup sets
   * Total: `1.6 TB`

---

# FRA Contents at Time of Discovery

```bash
$ du -h /b0/fast_recovery_area/NCDB012/

695G  ./522FB.../datafile
44G   ./522FB.../backupset/2026_05_20
677G  ./backupset/2026_05_19
1.4G  ./backupset/2026_05_21
1.0G  ./521DFA.../datafile
2.4G  ./datafile
110M  ./autobackup
224K  ./archivelog

1.6T total
```

### Breakdown

| Component                     | Size   | Notes               |
| ----------------------------- | ------ | ------------------- |
| Current image copy            | 695 GB | MYAPPDB PDB         |
| Backup set May 20             | 44 GB  | Incremental backup  |
| Orphaned migration backup set | 677 GB | Not tracked by RMAN |
| Current archivelog backup     | 1.4 GB | Expected            |
| PDB$SEED / CDB copies         | Small  | Expected            |

---

# Root Cause Analysis

## Cause 1: Orphaned 677 GB Backup Set from Migration

During the initial post-migration RMAN backup run on May 19, a full backup set was written to the FRA before the image copy strategy was finalized.

When the backup approach was switched to image copies, the original backup set was never cleaned up.

The backup set became **orphaned**:

* physical files still existed
* RMAN catalog no longer tracked them
* `DELETE OBSOLETE` could not remove them

---

## Why `DELETE OBSOLETE` Did Not Remove It

RMAN only removes backups that still exist in the RMAN repository/catalog.

If:

* backup metadata is reset
* retention context changes
* files are moved manually
* migration workflows interrupt tracking

then physical files remain on disk while RMAN has no reference to them.

These become **orphaned backup files**.

---

# Cause 2: LOB Tablespace Autoextension During Import

`LOB_DATA01` was pre-created with:

* 17 datafiles
* initial size `1M`
* `AUTOEXTEND ON`
* `MAXSIZE 32767M`

During Data Pump import, the LOB data caused aggressive autoextension.

## Resulting Tablespace Growth

| Tablespace        | Datafiles | Size Per File | Total   |
| ----------------- | --------- | ------------- | ------- |
| LOB_DATA01        | 17        | ~29 GB        | ~490 GB |
| UNDO              | 1         | 34 GB         | 34 GB   |
| CEN_DATA02        | 1         | 34 GB         | 34 GB   |
| Other tablespaces | Various   | Small         | ~137 GB |

The `LOB_DATA01` tablespace alone accounted for ~490 GB of the final image copy.

This was expected and valid.

---

# Cause 3: Backup Script Missing Cleanup Validation

The nightly backup script did not fully validate:

* expired backups
* orphaned copies
* post-migration repository consistency

Over time, this would allow stale backup artifacts to accumulate.

---

# Resolution

# Step 1 — Crosscheck RMAN Catalog

```sql
rman target /

CROSSCHECK BACKUP;
CROSSCHECK COPY;

LIST EXPIRED BACKUP;
LIST EXPIRED COPY;
```

This validated which files RMAN still recognized.

---

# Step 2 — Remove Existing Backups

Because this was a development system, all existing backups were removed to establish a clean baseline.

```sql
DELETE NOPROMPT BACKUP;
DELETE NOPROMPT COPY;

DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED COPY;

DELETE NOPROMPT OBSOLETE;
```

---

## Production Warning

Do **NOT** run blanket `DELETE BACKUP` operations in production without:

* validated recovery strategy
* alternate backup copies
* retention confirmation

Instead:

1. verify orphaned directories manually
2. confirm they do not appear in `LIST BACKUPSET`
3. remove only confirmed orphaned paths

---

# Step 3 — Remove Orphaned Files Manually

```sql
rman target /

LIST BACKUPSET;
```

The `2026_05_19` backup set path did not appear in RMAN output.

The files were confirmed orphaned and removed manually:

```bash
rm -rf /b0/fast_recovery_area/NCDB012/.../backupset/2026_05_19
```

---

# Step 4 — Take Fresh Level 0 Image Copy

```sql
BACKUP AS COPY INCREMENTAL LEVEL 0
DATABASE
TAG 'IMAGE_COPY';

BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
```

---

## Important RMAN Note

The following syntax is invalid:

```sql
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
```

This produces:

```text
ORA-06045
```

Archivelogs must be backed up separately when using image copy incremental strategy.

---

# Step 5 — Verify FRA Usage

```bash
$ du -sh /b0/fast_recovery_area/

~700G
```

Final FRA size matched the actual image copy footprint.

---

# Prevention

# Improve Nightly RMAN Cleanup

Updated backup workflow:

```sql
run {

  recover copy of database with tag 'IMAGE_COPY'
    until time 'sysdate - ${RECOVERY_WINDOW_DAYS}';

  backup incremental level 1
    for recover of copy
    with tag 'IMAGE_COPY'
    database
    plus archivelog delete all input;

  delete noprompt obsolete;

  delete noprompt expired backup;

  delete noprompt expired copy;
}
```

---

# Monitor FRA Usage Proactively

```sql
SELECT
    name,
    round(space_limit/1073741824,1) limit_gb,
    round(space_used/1073741824,1) used_gb,
    round(space_reclaimable/1073741824,1) reclaimable_gb,
    round(space_used/space_limit*100,1) pct_used
FROM v$recovery_file_dest;
```

---

# Recommended FRA Alert Thresholds

| Threshold | Action                    |
| --------- | ------------------------- |
| 70%       | Warning                   |
| 85%       | Critical                  |
| 95%       | Immediate action required |

---

# FRA Sizing Guidance

| Scenario                      | Recommended FRA Size  |
| ----------------------------- | --------------------- |
| Development / Test            | DB Size × 1.5         |
| Production (7-day retention)  | DB Size × 2           |
| Production (30-day retention) | DB Size × 3–4         |
| Post-migration cleanup window | Add 1× DB size buffer |

---

# Summary

| Item             | Detail                                    |
| ---------------- | ----------------------------------------- |
| Issue            | FRA grew to 1.6 TB after migration        |
| Primary Cause    | 677 GB orphaned backup set                |
| Secondary Cause  | LOB tablespace autoextension              |
| Fix              | Removed orphaned files + rebuilt baseline |
| Prevention       | Improved RMAN cleanup validation          |
| Final FRA Size   | ~700 GB                                   |
| Retention Policy | `RECOVERY WINDOW OF 7 DAYS`               |

---

# Key Migration Takeaway

After any major migration involving RMAN:

Always validate:

* `CROSSCHECK BACKUP`
* `LIST BACKUPSET`
* physical FRA contents

before the first scheduled backup cycle runs.

Migration activities frequently leave orphaned backup artifacts that RMAN cannot automatically clean up.

A **post-migration RMAN audit** should be a mandatory checklist item in every migration project.

---

**Platform:** Oracle 19c SE2 (19.24.0.0.0)
**Backup Strategy:** RMAN Image Copy Incremental Merge
**Operating System:** Oracle Linux 9
**Date:** 2026-05-21