Recover Deleted Oracle Datafiles Using Linux File Descriptors and BBED

1. Recovering a Deleted Datafile

Scenario: During routine maintenance a DBA accidentally deletes a datafile (e.g., ts_test01.dbf) while the database remains open, causing ORA‑01116 errors.

Problem analysis: In Linux the deleted file’s inode is still held open by the Oracle DBWR process, so the file can be recovered via its file descriptor as long as the database is not shut down.

Recovery steps

Identify the DBWR process ID (e.g., spid 3293) and navigate to /proc/3293/fd.

Locate the descriptor marked (deleted) (e.g., fd 25) that corresponds to the missing datafile.

Copy the file from the descriptor to a new location:

cp /proc/3293/fd/25 /u01/app/oracle/oradata/TSDB/ts_test01.dbf

.

Set correct ownership and permissions for the recovered file.

Redirect the tablespace to the new file (e.g., using ALTER DATABASE DATAFILE '/path/ts_test01.dbf' RESIZE ...) and bring the tablespace online.

If the datafile header checkpoint differs from the control file, perform media recovery to synchronize checkpoints.

After these actions the tablespace becomes online and the database returns to normal operation.

2. Skipping a Missing Archive Log with BBED

Scenario: Storage failure corrupts a datafile and a required archive log (sequence 35) is missing, preventing RMAN media recovery.

Preparation

Take a full RMAN backup of the database.

Insert rows into a test table, issuing ALTER SYSTEM SWITCH LOGFILE every three inserts to generate archive logs 34, 35, 36.

Failure simulation

Abort the database, delete ts_test01.dbf, and manually remove archive log sequence 35.

Recovery steps

Run RMAN> CROSSCHECK ARCHIVELOG ALL to confirm that archive 35 is missing.

Determine the SCN of the missing archive (first change #1243371).

Use BBED to modify the datafile header SCN to a value greater than the missing archive, e.g., 1243381 (hex f5f812).

Recalculate the file checksum with sum apply.

Adjust the RBA (log sequence, block, offset) in the header to point to the next archive (e.g., set RBA to 36.2.16, represented as 24000000.02000000.10000000).

Run RMAN media recovery for the datafile; the database opens, though some data loss or inconsistency may remain.

After the database is online, a full backup should be taken again to re‑establish a reliable recovery baseline.

Key takeaways

Backup verification is essential; missing or corrupted backups must be detected early and a new backup performed. When a database is in a critical state, avoid hasty actions—preserve the current fault state, analyze the root cause, and apply controlled, well‑understood recovery techniques such as file‑descriptor recovery or BBED‑based SCN manipulation.