Read this first

Licensing removes DBRECOVER evaluation export caps. It does not magically repair bytes that are missing, overwritten, encrypted, or physically unreadable. The right question is not only "does the full version allow export?" but also "did the scan prove that the specific rows, LOB chunks, and dictionary metadata still exist in the supplied files?"

Table of Contents

1. Short Answer for Busy DBAs

DBRECOVER for Oracle is designed to read Oracle datafiles directly, outside the Oracle instance. In the licensed version, the evaluation export limit is removed for the licensed database name, so recoverable tables can be exported beyond the trial cap. That includes ordinary application tables and recoverable Oracle dictionary base tables such as SOURCE$, OBJ$, USER$, VIEW$, and TRIGGER$.

The important qualifier is recoverable. A licensed export still depends on the physical condition of the datafiles, the availability of the SYSTEM tablespace or enough replacement metadata, the supported Oracle version, the supported data type, and whether the relevant blocks have not been overwritten or encrypted.

Question Practical Answer Important Boundary
Can the full version export all dictionary rows? It removes the evaluation row cap and can export recoverable dictionary table rows. Damaged or missing blocks cannot be exported as valid rows.
Can PL/SQL source be recovered? Yes, when SOURCE$ and related object metadata are readable. Wrapped source remains wrapped. Missing source lines may require manual reconstruction.
Can views and triggers be rebuilt? Often yes, through recovered dictionary metadata and DDL export. Complex dependencies, invalid objects, and missing metadata should be checked after import.
Does it need Oracle to be open? No. It reads DBF files directly. A running target Oracle instance may still be useful for Data Bridge or validation import.
Is Oracle 11.2.0.4 supported? Yes. Oracle 11gR2 datafiles are inside the documented support range. Use the trial scan on the actual files before purchasing an export license.

2. Dictionary Tables and Metadata Rows

Oracle dictionary tables are still tables. They live mainly in the SYSTEM tablespace and store metadata about users, objects, columns, views, triggers, PL/SQL source, segments, extents, and privileges. When a datafile recovery tool can parse the blocks that store those rows, it can treat them like recoverable data.

For the common customer question, "Can the full licensed version export SOURCE$, OBJ$, USER$, views, triggers, and other metadata tables without row limitations?", the practical answer is:

Licensed export answer

A valid license removes the evaluation row cap. If the dictionary table is visible in the scan and its blocks are readable, the licensed export path is intended to export its recoverable contents without the 10,000-row trial truncation.

That answer does not mean every metadata object in a corrupted database is guaranteed to be complete. Dictionary recovery can be affected by corrupted SYSTEM blocks, missing datafiles, broken segment metadata, lost LOB/index segments, character set problems, or severe storage damage.

What "all rows" means in a recovery context

In a healthy online Oracle database, "all rows" means the result of a SQL query. In offline DBF recovery, "all rows" means all rows that can be reconstructed from the supplied physical files. If a row was stored in a block that is now zeroed, encrypted, overwritten by another file, or absent from the evidence set, no license can recreate that row from nothing.

3. PL/SQL Source, Views, and CREATE OR REPLACE Scripts

Procedures, functions, packages, package bodies, and triggers are normally stored as source lines in Oracle dictionary structures, especially SOURCE$, with object identity information from tables such as OBJ$ and USER$. Views are stored differently, commonly through VIEW$ and related metadata. A recovery tool uses these rows to assemble DDL.

PL/SQL objects

Procedures, functions, packages, package bodies, and triggers

If the relevant source lines and object metadata are recoverable, DBRECOVER can export the PL/SQL source and the licensed DDL export function can produce rebuildable CREATE OR REPLACE scripts. After loading into a new Oracle database, compile the objects and review invalid dependencies, grants, synonyms, and referenced schemas.

Views

View text and view DDL

View recovery depends on the availability of the view text and the object metadata that names the owner and view. If those rows are complete, the export can be turned into executable view DDL. If only raw dictionary content is available, a DBA may need to manually assemble or adjust the statement.

Raw versus executable output

Raw SOURCE$ rows are not the same as a full schema rebuild script

Raw dictionary rows are useful evidence, but rebuildable SQL must add object headers, owner names, delimiters, ordering by line number, and sometimes edition or dependency details. DBRECOVER's licensed DDL export is the path intended for executable scripts. If metadata is incomplete, raw export may still help a DBA reconstruct source manually.

Wrapped PL/SQL is not decrypted

If the original Oracle PL/SQL was wrapped or obfuscated, recovery preserves what is stored in the data dictionary. It does not convert wrapped code back to original readable source.

4. Row, Table, Database Size, and Object Limits

A licensed export is not designed around the 10,000-row evaluation cap. For the licensed database, the practical limits become engineering limits rather than trial limits.

Limit Type Licensed Export Position What Actually Limits Recovery
Rows per table No 10,000-row trial cap after valid licensing. Readable blocks, export disk space, output format, runtime, and corruption level.
Number of tables No ordinary artificial table-count cap documented for licensed recovery. Dictionary completeness, memory, scan time, and DBA selection.
Database size Large DBF sets can be scanned and exported, subject to environment resources. I/O throughput, target disk capacity, Java heap, filesystem limits, and damaged storage.
Number of exported objects Recoverable selected objects can be exported after licensing. Metadata quality, object type support, and post-import compilation requirements.
License scope The Oracle license is bound to one specific DB_NAME. A different database name needs its own license.

5. BLOB, CLOB, NCLOB, LONG, XMLTYPE, and BFILE

Data type support matters because metadata recovery and table-row recovery are not the same thing. A table row can be visible while one large object chunk is damaged, or a dictionary row can name an external file that was never stored inside the Oracle datafiles.

Data Type Status Plain-English Explanation
BLOB Supported Binary large objects can be recovered when LOB metadata and LOB data blocks are readable. Validate byte lengths after export.
CLOB Supported Character large objects can be recovered when the LOB chain and database character set handling are intact enough.
NCLOB Supported National character LOBs are supported, but post-export character validation is important.
LONG Supported Legacy LONG text can be exported. This matters for older dictionary structures such as view text.
LONG RAW Supported Legacy binary LONG RAW data can be exported when the underlying row data is readable.
XMLTYPE Not a full logical recovery target Do not assume DBRECOVER can reconstruct XMLType semantics. Some underlying storage may be visible as raw or LOB data, but XMLType rebuild needs case-by-case review.
BFILE Not recoverable as payload from DBF A BFILE stores a locator to an external operating-system file. The actual file content is not inside Oracle datafiles, so DBF recovery can at most recover metadata about the locator if the dictionary is readable.

6. Offline Oracle 11.2.0.4 DBF Recovery

Oracle 11.2.0.4 is a common recovery case, and it is inside DBRECOVER's documented Oracle version range. The tool can load Oracle 11gR2 datafiles directly without requiring the damaged database to mount or open.

This direct-read approach is useful when the database fails during startup because of dictionary corruption, undo corruption, missing control files, file header problems, ORA-00600 errors, ORA-01157, ORA-01194, ORA-01578, or storage damage.

Dictionary Mode versus Non-Dictionary Mode

If SYSTEM datafiles and dictionary metadata are available, Dictionary Mode can show schema names, table names, column names, and object metadata. If SYSTEM is missing or unusable, Non-Dictionary Mode may still scan table-like segments, but table identification and column definitions require more manual work.

Undo corruption usually prevents Oracle from opening cleanly because Oracle must reason about transaction consistency. Offline datafile extraction is different. It reads the stored row pieces and blocks as physical evidence. That can recover business data even when Oracle's own crash recovery cannot complete. However, rows affected by in-flight transactions, deleted data, or damaged undo history should be validated carefully.

7. Evaluation Version vs Licensed Version

The evaluation version exists so you can prove recoverability before buying. A good pre-purchase test is to load the same damaged files, confirm that the target tables and dictionary tables are visible, preview representative rows, and run record-count checks for important tables.

Capability Evaluation Version Licensed Version
Open and scan datafiles Available for assessment. Available.
Preview recoverable tables and rows Available, subject to evaluation limits. Available.
Export table data Limited, commonly up to 10,000 rows per table. Unlocked for the licensed database, subject to recoverability and environment constraints.
Export DDL and PL/SQL rebuild scripts Not the intended production path. Available after valid enterprise license registration.
Technical recovery assistance Not included in the software trial. Not included in the software license; paid support is available separately.
If the trial can read SOURCE$, OBJ$, and USER$

That is strong evidence that the licensed version can export the complete recoverable contents of those same objects without trial truncation. Before purchase, also verify representative PL/SQL source lines, view definitions, LOB-bearing tables, and row counts for the objects that matter most.

8. Technical Support and Verification Checklist

The DBRECOVER for Oracle software license is a self-service software license. Technical support, remote recovery assistance, and custom case work are separate paid services. This distinction matters in emergency cases because some failures require expert interpretation, not just an export button.

Before buying a license, collect this evidence

  • The Oracle version, for example 11.2.0.4, and the exact DB_NAME that the license will bind to.
  • A screenshot or report showing that target schemas and dictionary objects are visible.
  • Record-count checks for the important application tables and dictionary tables.
  • Sample exported rows from SOURCE$, OBJ$, USER$, and any table with BLOB, CLOB, NCLOB, LONG, or LONG RAW columns.
  • Evidence that representative PL/SQL objects can be reconstructed in the right line order.
  • A list of unsupported or risky types such as XMLType, BFILE, user-defined types, object-relational columns, collections, or damaged LOB segments.
  • Enough free disk space for exported CSV, SQL, LOB files, and import validation into a clean Oracle database.

What to validate after export

  • Row counts for each critical table.
  • Checksums or byte sizes for BLOB output files where possible.
  • Character correctness for CLOB and NCLOB output.
  • Compilation status for procedures, functions, packages, package bodies, triggers, and views.
  • Missing grants, synonyms, sequences, jobs, constraints, indexes, or application-specific metadata that may need separate rebuild steps.

Conclusion

A licensed DBRECOVER export is best understood as removing the trial export barrier from data that the scan has already proven recoverable. For Oracle dictionary tables and PL/SQL source, the full version can be the difference between seeing evidence and producing usable export files. But the final outcome still depends on the actual bytes in the DBF files.

For the scenario described here, where the evaluation version already reads SOURCE$, OBJ$, and USER$ from Oracle 11.2.0.4 datafiles, the next practical step is to verify row counts and representative source output, then use the licensed version to export the complete recoverable contents without the evaluation truncation.