When restoring or recovering an Oracle database using Recovery Manager (RMAN), you might see the ORA-19870 error. This error can stop your recovery process cold—often at the worst possible moment. For any operations administrator, knowing what triggers ORA-19870 and how to fix it is crucial. In this guide, we’ll explain why this error appears, what it means in practice, and how you can resolve it step by step.
What Is ORA-19870 Error？
The ORA-19870 error shows up during restore operations in Oracle databases. The full message usually reads: “ORA-19870: error while restoring backup piece <filename>.” Often, you’ll see other errors alongside it—like ORA-19507 or ORA-19504—which provide more detail about what went wrong. Think of ORA-19870 as a warning light on your dashboard; it tells you something failed when RMAN tried to read or write a backup piece but doesn’t always tell you exactly why.
This error signals that RMAN hit an I/O-related problem during restore. It’s not usually the root cause itself but points to deeper issues like missing files or storage problems.
Why Does ORA-19870 Occur？
ORA-19870 is a symptom—not a root cause—of trouble during restores. When you see this error, check these common causes:
1. Insufficient Disk Space: If your Fast Recovery Area (FRA) or target directory is full, Oracle cannot write restored files.
2. Missing or Inaccessible Files: Backup pieces may have been moved or deleted since they were cataloged by RMAN—or their permissions may have changed.
3. Corrupted Backup Files: Sometimes physical damage to backup files leads to read failures.
4. RMAN Catalog Metadata Issues: If RMAN’s records don’t match reality—for example if files were moved outside of RMAN—it can trigger this error.
5. Configuration Mismatch: Incorrect settings for DB_RECOVERY_FILE_DEST or similar parameters can also cause problems.
Usually, another Oracle error follows ORA-19870 in your logs; pay close attention to those details—they often point straight to the underlying issue.
Before You Begin: Essential Pre‑Checks
Before diving into specific fixes for ORA‑19870, take a few minutes for basic checks that often save hours later.
First, review any additional errors shown after ORA‑19870 in your RMAN log or alert log—they often reveal whether space issues, permission problems, or missing files are involved.
Next, verify file permissions on both source backups and destination directories:
Make sure the Oracle software owner (often oracle) has read access on backup locations and write access where restores will land.
On Linux/Unix systems use ls -l /path/to/backup to check ownerships and permissions quickly.
Also confirm that all referenced backup pieces exist at their expected paths:
If permissions are off—or if files are missing—you must correct these before proceeding with deeper troubleshooting steps.
Method 1: Fixing ORA‑19870 by Freeing Space
Running out of disk space is one of the most frequent reasons for seeing ORA‑19870 during restores. When Oracle cannot write restored data due to lack of space in either the FRA or target directory, everything grinds to a halt.
Start by checking available space in your recovery area using SQL:
SELECT * FROM V$RECOVERY_FILE_DEST;
Look at SPACE_USED versus SPACE_LIMIT—if they’re close together (or equal), you need more room fast.
To free up space:
1. Open RMAN
2. Run DELETE OBSOLETE; This removes backups no longer needed based on retention policy
3. Then run DELETE EXPIRED ARCHIVELOG ALL; This clears out archived logs marked as expired
If cleaning up isn’t enough—or if time is tight—you can temporarily increase FRA size right away (see Method 3 below). Just remember: quick fixes should be followed by proper storage planning so this doesn’t happen again next time!
After freeing up space (or expanding FRA), retry your restore operation from RMAN prompt:
RMAN> RESTORE DATABASE;
If low disk space was blocking progress before, things should now proceed smoothly without triggering another ORA‑19870 event.
Method 2: Resolving ORA‑19870 Using RMAN Commands
Sometimes this error pops up because RMAN tries referencing backup pieces that no longer exist—or which have become inaccessible due to changes outside its control (like manual file moves).
To get things back in sync:
1. Start with a crosscheck:
RMAN> CROSSCHECK BACKUP;
RMAN> CROSSCHECK ARCHIVELOG ALL;
This tells RMAN to verify which backups physically exist where expected—and mark others as expired if missing.
2. Clean up expired entries:
RMAN> DELETE EXPIRED BACKUP;
RMAN> DELETE EXPIRED ARCHIVELOG ALL;
3. If you’ve moved backup pieces manually using OS tools—for example after archiving old backups elsewhere—you need to register them again so RMAN knows where they live now:
RMAN> CATALOG START WITH '/new/path/to/backup/';
This command scans /new/path/to/backup/ recursively and catalogs every valid backup piece found there—updating metadata so future restores reference only real files present on disk.
Once cleanup is complete—and any relocated backups are cataloged—try running your restore again from within RMAN prompt as usual:
RMAN> RESTORE DATABASE;
With metadata cleaned up and paths corrected, most cases of spurious ORA‑19870 disappear immediately.
Method 3: Fixing ORA‑19870 by Increasing Recovery Area Size
Sometimes even after deleting obsolete data there just isn’t enough room left for large restores—especially if database growth has outpaced storage planning over time.
Oracle stores its backups plus archived logs inside the Fast Recovery Area (FRA). If this gets too small relative to current needs—even briefly—a restore attempt fails with our familiar friend: ORA‑19870!
To fix permanently:
1. Connect as SYSDBA user via SQL*Plus or similar tool
2. Increase FRA size using SQL command below (replace <new_size> appropriately):
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = <new_size> SCOPE=BOTH;
For example,
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G SCOPE=BOTH;
3. Confirm change took effect:
SELECT * FROM V$RECOVERY_FILE_DEST;
With extra headroom available in FRA—and perhaps after clearing some old data too—you should find subsequent restores succeed without further incident from disk constraints alone.
Remember: always monitor ongoing usage trends so future growth doesn’t catch you off guard!
How Vinchin Backup & Recovery Protects Your Oracle Database?
For organizations seeking robust protection against errors like ORA‑19870 and aiming for reliable Oracle database management at scale, adopting an enterprise-level solution becomes essential. Vinchin Backup & Recovery stands out as a professional platform supporting today’s mainstream databases—including Oracle first and foremost—as well as MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB environments commonly found across enterprises worldwide.
Vinchin Backup & Recovery delivers features such as incremental backup tailored for Oracle workloads; batch database backup operations; flexible data retention policies including GFS retention options; cloud backup with tape archiving support; and instant any-point-in-time recovery capabilities—all designed for operational efficiency while minimizing risk of data loss or downtime through automation and advanced scheduling controls.
Managing protection tasks through Vinchin Backup & Recovery’s intuitive web console requires just four straightforward steps:
Step 1. Select the Oracle database to back up
Step 2. Choose the backup storage
Step 3. Define the backup strategy
Step 4. Submit the job
Recognized globally among enterprise users—with top ratings for reliability—Vinchin Backup & Recovery offers a fully featured 60-day free trial so you can experience its power firsthand; click download now and join thousands who trust their critical data protection needs to Vinchin solutions.
ora 19870 FAQs
Q1: Can network interruptions cause an ora 19870 error?
Yes; unstable network connections between primary server and remote storage may interrupt reading/writing of backup pieces leading to ora 19870 during restore jobs.
Q2: How do I quickly verify directory permissions before starting an Oracle restore?
Run ls -ld /your/directory/path as root; ensure owner matches oracle user/group & mode allows required read/write access.
Q3: What should I do if my only available copy of a needed backup piece fails validation?
Attempt recovery from alternate full/incremental backups covering same period; otherwise consider point-in-time recovery strategies using remaining archive logs.
Conclusion
Resolving ora 19870 requires careful checks around disk usage limits,freshness of catalog records, and health of actual backups. A disciplined approach prevents repeat incidents. For comprehensive protection, Vinchin delivers automated monitoring, reliable scheduling, and rapid recovery—all designed specifically for demanding enterprise environments worldwide.
