Oracle Data Recovery

Oracle database recovery begins at the physical drive. When your storage has failed, RMAN cannot read its backup sets, and DBMS_REPAIR cannot mark blocks it cannot reach. We image the failed drives using PC-3000, reassemble ASM diskgroups from raw disk images, reconstruct control files, and export intact tablespaces. Oracle 11g through 21c. No data, no fee.

Start a Recovery All Database Services

No Data = No Charge

ASM + Datafile Recovery

PC-3000 + Block Repair

Nationwide Mail-In

Written by

Louis Rossmann

Founder & Chief Technician

Updated March 2026

Oracle Storage Architecture

An Oracle database instance relies on several file types that must remain consistent with each other. Understanding this architecture explains why Oracle recovery is more involved than copying files off a drive.

Datafiles (.dbf): Contain tablespace data, organized into Oracle blocks. The default block size is 8KB, but DBAs can configure it from 2KB to 32KB at tablespace creation. Each block has a header with transaction slots (Interested Transaction List entries), a row directory, row data, and a checksum controlled by the DB_BLOCK_CHECKSUM parameter.
Control files (.ctl): Binary files that map datafiles to tablespaces, track the current System Change Number (SCN), and store RMAN backup records. Oracle requires all multiplexed control file copies to be consistent. If all copies reside on the same failed storage, the instance cannot mount.
Redo logs: Online redo log groups are written cyclically by the LGWR process. Oracle enforces write-ahead logging: LGWR flushes redo entries to disk before DBWR writes modified blocks to the datafiles. Archived redo logs (if ARCHIVELOG mode is enabled) are copies of filled online redo log groups, used for point-in-time recovery.
ASM (Automatic Storage Management): Oracle's built-in volume manager. ASM splits datafiles across diskgroup member disks using allocation units (AU) sized 1MB to 64MB. ASM metadata lives in the disk header of each member disk. Losing that header means the diskgroup refuses to mount and every datafile in it becomes inaccessible.
SYSTEM and SYSAUX tablespaces: These contain the data dictionary, which maps every object in the database. If the datafiles for SYSTEM or SYSAUX are corrupted, the instance cannot mount at all. Recovery of these two tablespaces is the first priority in any Oracle recovery.

Oracle Error Codes We Handle

Error	Meaning	Typical Cause
ORA-01578	Oracle block corruption detected. The block checksum or header validation failed during a read.	Bad sectors on the platter, power loss during DBWR flush, SSD firmware bug causing silent bit corruption.
ORA-00600	Internal error code. A catch-all for kernel-level failures, often accompanied by a block read failure argument.	Drive returning stale or garbled data. Firmware corruption causing incorrect LBA mapping. RAID controller cache returning wrong blocks.
ORA-00354	Corrupt redo log block header. The instance crashes during the recovery phase and refuses to open.	Online redo log on a failing drive. LGWR wrote to a bad sector. Power failure during log switch.
ORA-01110	Datafile not accessible. Oracle cannot read the specified datafile during startup or recovery.	Drive offline, failed SAS/SATA connection, ASM disk deregistered after physical failure.
ORA-00205	Error identifying control file. The instance cannot locate or read any control file copy.	All control file copies on the same failed volume. ASM diskgroup containing the control file will not mount.

Why ASM Complicates Physical Recovery

Most Oracle deployments in production use ASM rather than a conventional file system. ASM provides redundancy and I/O distribution, but it creates a layer of abstraction between the physical disk and the Oracle datafiles that makes recovery from drive failure more difficult.

ASM stripes data across member disks using allocation units (AUs). A single datafile may span hundreds of AUs distributed across multiple physical drives. The mapping between AUs and physical disk offsets is stored in ASM metadata at the beginning of each disk. If that metadata header is overwritten or unreadable due to physical damage, the ASM instance cannot mount the diskgroup, and standard Oracle tools (RMAN, asmcmd, DBMS_FILE_TRANSFER) have no access to the data.

Recovery requires imaging every member disk in the diskgroup with PC-3000, then parsing the ASM extent maps from the raw images. Each allocation unit is identified by its AU header, and the datafile is reassembled by following the extent chain. For diskgroups with external redundancy (no ASM mirroring), every member disk must yield a usable image. For normal or high redundancy, ASM mirrors provide a second copy of each AU, which increases the chance of a complete recovery if one member disk is severely damaged.

ASM diskgroups frequently run on hardware RAID arrays. When the RAID controller fails or the array degrades, both the RAID parity structure and the ASM extent mapping need reconstruction. This is a two-layer recovery: rebuild the RAID first, then reassemble the ASM diskgroup from the reconstructed virtual disks.

Why RMAN and DBMS_REPAIR Cannot Fix a Dead Drive

RMAN (Recovery Manager): Oracle's native backup and recovery tool. RMAN performs block media recovery by reading backup sets and applying archived redo logs to restore corrupted blocks to a consistent state. This works well when the database is on healthy storage and RMAN backups exist on separate media. It fails in two common scenarios: the RMAN backup sets are on the same failed storage as the database, or no archived logs exist covering the corruption window (common when NOARCHIVELOG mode was used).

DBMS_REPAIR: This PL/SQL package marks corrupt blocks as "soft corrupt" so queries skip them instead of returning ORA-01578 errors. DBMS_REPAIR does not recover data. It hides the problem. Every row in a soft-corrupt block is permanently inaccessible through normal SQL. The package is a stopgap for keeping a partially damaged database online while planning a recovery, not a solution.

Data Pump (expdp): If the Oracle instance can partially mount, Data Pump can export intact tablespaces or individual tables. This requires the SYSTEM tablespace and data dictionary to be healthy. If the SYSTEM datafile is on the failed drive, Data Pump cannot start. Even when it runs, it skips any table whose underlying blocks are corrupt, producing an incomplete export with no indication of which rows were lost.

Before attempting any recovery command: Power down the server. Do not restart the Oracle instance, as automatic crash recovery may overwrite redo log data needed for reconstruction. Do not drop or recreate control files. Do not run ALTER DATABASE OPEN RESETLOGS on a damaged instance. Each operation modifies on-disk structures and reduces the data available for physical recovery. Contact us for a free evaluation of the drive's physical condition.

Our Oracle Recovery Workflow

Drive assessment and forensic imaging

Evaluate the physical condition of every drive in the storage array using PC-3000 diagnostics. Mechanically sound drives are imaged directly with write-blocking. Drives with failed heads undergo a head swap in the 0.02µm ULPA-filtered clean bench before imaging. For multi-disk ASM configurations, all member disks are imaged to separate healthy media.

ASM diskgroup or filesystem extraction

For ASM deployments: parse the ASM disk headers and AU extent maps from each member disk image. Reassemble datafiles by following the extent chain across disks. For filesystem-based deployments (ext4, XFS, or NTFS on Windows): mount the cloned image and extract the .dbf, .ctl, and redo log files. If the filesystem metadata is damaged, parse the inode tables directly to locate file extents.

Control file reconstruction

If the control files are missing or corrupt, rebuild them from the datafile headers (which contain the tablespace ID, relative file number, and creation SCN) and the redo log headers (which contain the log sequence number and thread information). The reconstructed control file allows the Oracle instance to mount and access the data dictionary.

Block-level integrity scan and repair

Scan every Oracle block in each datafile. Validate block headers, ITL (Interested Transaction List) entries, row directory pointers, and checksums. Build a map of healthy blocks, repairable blocks, and unrecoverable blocks. Repair damaged block headers by recalculating checksums and reconstructing the row directory from intact row data.

Tablespace export and validation

Mount the repaired database in a sandboxed Oracle instance. Run RMAN's VALIDATE command (read-only, no repair) against each datafile to confirm block integrity. Export the data using Data Pump (expdp) for a portable dump file, or deliver as a transportable tablespace set. For CDB/PDB databases (12c+), export at the PDB level to preserve container isolation.

Delivery and verification

Provide a file listing with row counts per table so you can verify completeness before paying. Deliver recovered data on an encrypted external drive or via secure transfer. We can ship nationwide; see our mail-in recovery process for logistics.

Oracle Versions and Editions

Oracle's on-disk block format is consistent across Enterprise, Standard, and Express Edition (XE) within the same database version. A datafile created by Enterprise Edition 19c uses the same block structure as one created by Standard Edition 19c. Edition differences affect features (partitioning, RAC, compression), not the physical storage format. Recovery tooling and procedures are identical regardless of edition.

Version differences matter more. Key changes by version:

11g: Standard non-CDB architecture. Single data dictionary per instance. ASM uses 1MB allocation units by default.
12c: Introduced Container Database (CDB) and Pluggable Database (PDB) multitenant architecture. Each PDB has its own data dictionary stored in the PDB's SYSTEM tablespace. Recovery must account for the root container (CDB$ROOT) metadata in addition to individual PDB datafiles.
18c / 19c: Long-term support releases. 19c is the most deployed Oracle version in production. Same CDB/PDB model as 12c with incremental on-disk format changes. ASM supports larger AU sizes (up to 64MB) for high-throughput workloads.
21c: Added blockchain tables and immutable rows at the block level. These use standard Oracle blocks with additional metadata in the block header. Recovery procedures are unchanged; the extra metadata is preserved during block repair.

CDB/PDB Multitenant Recovery

Starting with Oracle 12c, most deployments use the multitenant architecture: a single Container Database (CDB) hosts one or more Pluggable Databases (PDBs). The CDB root container (CDB$ROOT) holds shared metadata, while each PDB maintains its own SYSTEM tablespace and data dictionary.

This architecture adds a layer to recovery. The CDB root's SYSTEM tablespace must be recovered first, because it contains the container ID mapping that links each datafile to its PDB. Without this mapping, recovered datafiles cannot be associated with the correct pluggable database, and Data Pump exports will fail with ORA-65040 errors.

For deployments running multiple PDBs on shared storage, a single drive failure can affect PDBs with different criticality levels. We recover and validate each PDB independently, providing per-PDB row counts and integrity reports so you can prioritize which databases to restore first.

Pricing

Oracle recovery pricing is based on the physical condition of the drives. ASM diskgroup reassembly, control file reconstruction, and block-level datafile repair are included at no additional charge. For RAID arrays underlying your ASM diskgroups, each member drive is priced separately.

Service Tier	Price	Description
Simple CopyLow complexity	$100	Your drive works, you just need the data moved off it Functional drive; data transfer to new media Rush available: +$100
File System RecoveryLow complexity	From $250	Your drive isn't recognized by your computer, but it's not making unusual sounds File system corruption. Accessible with professional recovery software but not by the OS Starting price; final depends on complexity
Firmware RepairMedium complexity – PC-3000 required	$600–$900	Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access Standard drives at lower end; high-density drives at higher end
Head SwapHigh complexity – clean bench surgery50% deposit	$1,200–$1,500	Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench 50% deposit required. Donor parts are consumed in the repair
Surface / Platter DamageHigh complexity – clean bench surgery50% deposit	$2,000	Your drive was dropped, has visible damage, or a head crash scraped the platters Platter scoring or contamination. Requires platter cleaning and head swap 50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

All tiers: Free evaluation and firm quote before any paid work. No data, no fee on simple copy, file system, and firmware tiers. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.

Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost. For ultra-high-capacity drives (20TB and above), the target drive costs approximately $400+ due to the large media required. All prices are plus applicable tax.

No Data, No Fee

Guarantee

2.49M+

Subscribers

4.9

1,837+ Google Reviews

Since 2008

Established

Repairs on Video

Full Transparency

As Featured In

Data Recovery Standards & Verification

Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to make sure your hard drive is handled safely and properly. This approach allows us to serve clients nationwide with consistent technical standards.

Validated Clean Zone

Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.

Transparent History

Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.

Media Coverage

Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.

Aligned Incentives

Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.

Technical Oversight

Louis Rossmann

Louis Rossmann's well trained staff review our lab protocols to ensure technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.

We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.

See our clean bench validation data and particle test video

Oracle Recovery FAQ

Can you recover data from an ASM diskgroup that will not mount?

Yes. ASM stores its own metadata in the disk header of each member disk. If the header is overwritten or the disk has physical damage, the diskgroup refuses to mount and all datafiles become inaccessible. We image each physical disk, parse the ASM allocation unit map from the recovered images, and reassemble the datafiles at the block level without requiring a running ASM instance.

What happens if all copies of the control file are lost?

Oracle requires at least one valid control file to mount the instance. The control file maps datafiles to tablespaces and tracks the current SCN (System Change Number). If all copies are on the same failed storage, we reconstruct the control file from the datafile headers and redo log headers, which contain enough metadata to rebuild the mapping. This allows the instance to mount and the data dictionary to become readable.

Can RMAN recover data from a physically failed drive?

No. RMAN reads backup sets and archived logs from disk or tape. If the storage holding both the live database and the RMAN backups has physically failed, RMAN has nothing to read. RMAN also cannot perform block media recovery without valid archived logs covering the corruption window. Physical drive imaging with PC-3000 must happen first; RMAN is useful only after the raw data has been recovered to healthy media.

What does ORA-01578 mean and can you fix it?

ORA-01578 indicates Oracle detected a corrupt block in a datafile. The block checksum does not match, or the block header contains invalid data. This is often caused by bad sectors, power loss during a write, or SSD firmware bugs. We recover the underlying drive, extract the datafile, and repair the corrupt blocks by reconstructing headers and recalculating checksums from the row data still present in the block body.

Do you support all Oracle versions and editions?

We recover datafiles from Oracle 11g through 21c, including Enterprise, Standard, and Express Edition (XE). The on-disk block format is identical across editions within the same version. CDB/PDB multitenant architecture (12c and later) adds container-level metadata that we account for during reconstruction.

How is Oracle recovery priced?

Pricing is based on the physical condition of the drives holding your datafiles. File system corruption: from $250. Firmware repair: $600-$900. Head swap: $1,200-$1,500. ASM reassembly, control file reconstruction, and block repair are included at no additional charge. No data, no fee.