DBRECOVER for Oracle

A customer about to purchase DBRECOVER for Oracle hit three blockers in the trial. Their database is corrupted, with no backups and no Data Pump dump. The questions and the answers below are useful for anyone running the demo before deciding to buy.

Q1. Our DB uses the EL8ISO8859P7 character set, but the demo cannot select it. All data shows as garbage.

EL8ISO8859P7 (Greek, ISO 8859-7) is supported from the 2020-09 build of DBRECOVER for Oracle onwards. Download the current build (which is up to date with all character-set patches) here: DBRECOVER for Oracle (latest).

To make sure the displayed text is correct:

Identify the correct database character set first. If the database can be partially mounted, run SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';. If not, look at PROPS$ in SYSTEM01.DBF via DBRECOVER's SCAN BASE TABLES; the row for NLS_CHARACTERSET still holds the original value.
Set the matching character set in DBRECOVER's session properties before exporting. Mismatched character sets are the most common cause of "all data is unreadable" reports.

Q2. We can't upload data — is this a trial limitation?

The trial limits the number of rows you can export per table; it does not limit your ability to load datafiles or browse rows. If "upload" means loading datafiles into the tool, that is unrestricted in the trial. Use the trial to verify that:

Every table you care about appears in the tree.
Row previews show correct values (text, numbers, dates).
You can export a small sample successfully.

Buying a license then unlocks unlimited row export to flat files, INSERT statements, or directly to a target Oracle instance.

Q3. We are using non-dictionary mode and objects come out with numeric ids. How do we recover real names? The DB is unavailable.

Non-dictionary mode is only required when the SYSTEM tablespace (SYSTEM01.DBF) is missing or unreadable. If SYSTEM01.DBF exists at all and can be partially read, switch back to dictionary mode and enable SCAN BASE TABLES. DBRECOVER will scan past damaged blocks, recover rows from OBJ$, TAB$, COL$, USER$, and rebuild a synthetic dictionary so that tables come back with their real schema.owner.table_name and column names.

If SYSTEM01.DBF is truly destroyed (zeroed out, completely encrypted, or physically lost), the only remaining option is non-dictionary mode plus external metadata:

Any old DDL script, expdp SQLFILE output, or schema export gives you the table and column names.
A working copy of the application's DDL repository (Liquibase, Flyway, etc.) is enough to relabel OBJ#XXXX back to SCHEMA.TABLE and rename COL01..COLn back to real column names.
Match objects to their original names by row count, by sample values, and by column types. DBRECOVER lets you preview rows for each OBJ#, which makes the mapping straightforward when you know the application.

Recommended pre-purchase validation

Run the trial against a copy of all datafiles (never the originals).
Confirm dictionary or non-dictionary mode based on whether SYSTEM01.DBF is usable.
Set the correct character set up front.
Export a short sample of one critical table to flat file and confirm the values are correct in your target system.
Only then buy the license to remove the row-export limit.

If you need help during the validation, contact [email protected] with the database version, platform, character set, and the list of datafiles you have available.

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.