Recover from Corrupted Data File

I. Initialization

1.1 Configure pdu.ini

Launch PDU in a result directory outside the sources and preserve the original table file and schema. Use a separate copy rather than files from a running instance.

Launch PDU in a result directory outside the sources; this launch directory is the working and output location for the run.

1.2 Start PDU and Execute Initialization

When metadata is complete, execute b; to read the table inventory. If only one IBD remains, use the manual schema path below.

./pdu

II. Add Data File to PDU

2.1 Copy the Corrupted Data File

Preserve the IBD, matching DDL, available SDI/FRM and external dependencies. Place output in another directory.

2.2 Specify the Table File and Definition

Use scan ibd to inspect file information and meta ddl to inspect schema evidence. If multiple indexes exist, confirm the clustered-index ID from matching metadata.

scan ibd /recovery-input/orders.ibd;
meta ddl /recovery-input/orders.sql;

III. Parse the Data File

unload ibd /recovery-input/orders.ibd /recovery-input/orders.sql;

Output contains data only. Normal file export skips delete-marked records. Missing pages and unsupported physical layouts retain original errors and are not treated as a complete export.

IV. Handling External Large Values

Large values depend on complete LOB pages or compressed LOB chains. A surviving main record does not guarantee that every external value remains complete. Retain separate reasons for missing pages, keys and broken chains.

For scattered surviving pages, specify matching table definitions in DropScan and supply the required files. If additional fragments change the pages used for recovery, create a new internal task. SQL is still exported to the launch directory without modifying earlier results.

See the disk-page and replacement-fragment recovery procedure.

Output Files

PDU uses its current directory at startup for tasks and output. Exported SQL files are written directly there, and internal task records are stored in .pdu-work. Export table definitions separately with unload ddl. Recovery commands generate SQL without writing to the target database. The records in .pdu-work retain the program's success and failure counts, original errors and checkpoints.

After export, record the native success and failure counts and original errors reported by PDU, and retain the checkpoint. Resume uses native records and file metadata such as existence and size without rereading exported data.

Common Issues

• Missing FRM/SDI: provide matching schema evidence; retain limits when the layout cannot be confirmed.
• Partition or shared-tablespace files: preserve matching SDI, system tablespaces and path lists.
• Encrypted or compressed files: provide the corresponding physical format and matching keys; do not treat opaque content as valid records.