DBRECOVER for Oracle FAQ: Complete Guide to Licensing, Technical Operations & Troubleshooting

This is typically caused by one of three issues:

1. Case Sensitivity: The license is bound to the DB_NAME in a case-sensitive manner. Oracle internally stores DB_NAME in uppercase. Ensure you entered ORCL not orcl.
2. Version Mismatch: Your key may be generated for a specific version (e.g., 2009 version) while you're running a different version (e.g., 23rc1). Different versions may use different key algorithms. Download and try the matching software version.
3. Internal Name Recognition: If your file headers are severely damaged, the software may not detect the real DB_NAME and will fall back to an internal default name (such as SHITANRUANJIAN or SAMIL). Check the log_dbrecover.txt log file to see what DB_NAME the software detected. If it shows an internal name, contact support for a special key matching that internal name.

No. DBRECOVER uses a strict "single-database-single-license" policy. The license key is algorithmically bound to the target database's DB_NAME. This means for every unique client database you service, you must purchase a separate license.

For service providers with high purchase frequency, contact our sales team at [email protected] to inquire about volume discounts.

The Enterprise Edition is priced at $1,350 USD per database. Payment is processed through Stripe, and an electronic receipt is automatically sent.

If you require a formal invoice with company tax information (VAT number, company name, address), send your details to [email protected] after payment completion, and we will manually issue one.

No refunds are provided. Due to the special nature of data recovery services, we enforce a "try before you buy" policy.

Before purchasing:

1. Download the free Community Edition
2. Use the "Examine Records Count" feature to scan your datafiles
3. Verify that you can see table structures and preview data (limited to 10,000 rows per table)

If you can see data in the Community Edition, it confirms the data is recoverable. Once a license key is issued, the transaction is final.

You are currently running the Community Edition (trial version), which has a hard-coded limit of 10,000 rows per table for export. This is not a software bug or data loss.

After entering a valid Enterprise Edition license key and restarting the software, this restriction is automatically lifted, allowing full data export.

Java Environment Issue (Legacy versions only):

• DBRECOVER 2512 and later: Includes bundled JRE — no separate Java installation required
• Older versions (23rc1 and earlier): Require Java Runtime Environment (JRE) 1.8 or higher
• If using an older version, ensure JAVA_HOME environment variable is correctly configured

Antivirus False Positive:

DBRECOVER performs low-level disk sector reading operations that may trigger heuristic detection in security software. This behavioral pattern is similar to what ransomware does (reading raw disk data), causing Windows Defender and other antivirus programs to flag it as a threat.

This is a false positive. To resolve:

1. Add the DBRECOVER directory to your antivirus exclusion list
2. Re-extract the ZIP file
3. Run the application

Yes, and this is the recommended approach.

DBRECOVER has built-in byte-order (endianness) conversion functionality. You can:

1. Copy the datafiles (.dbf) from your Unix server to a Windows PC
2. Load them in DBRECOVER on Windows
3. The software automatically detects and handles Big Endian format from AIX/HP-UX/Solaris

This "off-site recovery" strategy avoids the risk of configuring Java on a damaged production server and provides a better GUI experience on Windows.

This typically occurs when the scanner encounters corrupted data blocks causing logical loops. Try these steps:

1. Switch Versions: If using version 23rc1, download and try the older but more stable 2009 version.
2. Narrow Scope: Don't load all datafiles at once. Start with only the core business tablespace files.
3. Switch Modes: If Dictionary Mode hangs, the SYSTEM.DBF is likely corrupted. Switch to Non-Dictionary Mode.

Your choice depends on the health of your SYSTEM tablespace (typically SYSTEM.DBF):

Dictionary Mode:

• When to use: When you have a healthy, intact SYSTEM.DBF file
• What you get: Full table names, column names, and schema structure — just like browsing in a normal database
• Experience: Navigate Schema → Table Name in a tree view, export tables by name

Non-Dictionary Mode:

• When to use: When SYSTEM.DBF is lost, corrupted, or overwritten
• What you get: Raw data segments identified only by DATA_OBJECT_ID (e.g., OBJ(12345) instead of T_ORDER)
• Experience: You must manually identify tables by sampling data content and deducing what each object represents

No. LOB Segments are storage areas for Large Objects (images, long text, BLOBs). They are attached to a parent table, not standalone tables.

You cannot extract meaningful structured data directly from a LOB segment. You must:

1. Find the parent Table Segment that owns this LOB
2. Recover the main table data first
3. LOB data is typically extracted along with the main table (if the structure is intact)

Two major versions are available:

Recommendation: Use version 2512 for most recovery scenarios. Keep the 2009 version as a fallback for Oracle 11g and earlier databases if the modern version encounters issues.

This occurs when the datafile headers are severely corrupted and the software cannot read the real DB_NAME. The software falls back to internal default names like SHITANRUANJIAN or SAMIL.

Solution:

1. Check log_dbrecover.txt to confirm what name was detected
2. Contact support — you will receive two keys: one for your real DB_NAME and one for the internal name
3. Use whichever key matches what the software detects

A "fuzzy" file is one where the data blocks contain changes from different points in time — the file is internally inconsistent. This happens when:

• Database crashed while datafiles were being written
• Hot backup was interrupted before END BACKUP
• Storage snapshots captured files at different moments

DBRECOVER can still read data from fuzzy files — it doesn't require consistency like the Oracle kernel does. You may lose uncommitted transactions, but committed data in the blocks can be recovered.

Use the Community Edition free trial:

1. Download from DBRECOVER for Oracle page
2. Load your datafiles
3. Use "Examine Records Count" or browse tables
4. If you can see tables and preview rows (up to 10,000), your data is recoverable

The Community Edition has identical recovery capabilities — only the export row count is limited.