Back to Scenarios

Instance Damaged, but Only One Database Needs Recovery?

Recover Single Database Directory

Scenario Description

An instance contains multiple databases, but one business database needs priority recovery. The full directory survives, while the instance is unusable. Identify databases, select the target and export it without mixing other databases into the results.

Possible Causes

  • An instance-level failure affects several databases.
  • Recovery must proceed in business-priority batches.
  • Multiple databases contain identically named tables.

Challenges

Conventional recovery often requires complete files, a running instance or a usable backup. In these situations, choose a method based on the evidence that survives.

Common Errors and Symptoms

  • - The business database is inaccessible, but a directory copy survives.
  • - Only appdb should be exported, with other databases retained for later work.
  • - Individual target tables may lack files or definitions.

Why Traditional Methods Fail

  • - Normal tools cannot connect to the damaged instance.
  • - Copying a database directory by name does not establish layouts or system-tablespace dependencies.
  • - Success for some tables does not complete the database recovery.

PDU Solution

PDU initializes a complete directory copy that is no longer being written and lists the databases it identifies. Select the target with use, review the table definitions, then export DDL and data separately. Completion depends on the actual results for the selected tables.

Recovery Principle

  1. Initialize Directory
  2. Select Business Database
  3. Confirm Target Tables
  4. Export Separately

PDU Core Capabilities

  • List identified databases in a frozen directory.
  • Select recovery scope by database name.
  • Inspect the target database’s tables and definitions.
  • Export the target database’s DDL separately.
  • Run data export for the selected database.
  • Record failures and unresolved dependencies per table.

Recovery Steps

  1. 1

    Initialize the Database Directory

    Directory Conflict

    Launch PDU from a directory outside the source files. Internal tasks are saved in .pdu-work and exported SQL is written directly to the launch directory. Do not put recovery output in the original data directory.

  2. 2

    View Available Databases

    Use \l; to view identified databases. Do not force same-name files to represent a database that was not identified.

  3. 3

    Enter the Database and View Tables

    Use the corresponding command example below, replacing paths, objects and identity parameters with evidence from this run.

  4. 4

    Export Database Data

    Export only confirmed usable tables. Retain original status when the database inventory has missing entries; successful initialization does not mean that all data has been recovered.

  5. 5

    Understanding the Exported Data

    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.

  6. 6

    Exporting Multiple Databases

    Run use, unload ddl and unload db separately for each database, preserving individual output and original errors.

Quick Command Examples

Preserve frozen sources and launch PDU outside them. Write configuration snippets to pdu.ini and execute PDU commands after startup. Replace example paths, versions, times and task identities with actual evidence.

# Initialize the Database Directory

param datadir /recovery-input/mysql/data;
b;
\l;
use appdb;
\dt;

# View Available Databases

\l;

# Enter the Database and View Tables

use appdb;
\dt;
\d orders;

# Export Database Data

unload ddl appdb;
unload db appdb;

Export Results

Table Data SQL

Exported data is saved directly in the directory where PDU was started, for example orders.sql. Larger results are split into orders_2.sql and subsequent files.

Table Definitions

Use unload ddl for directory-mode definitions; preserve the matching original DDL for single-file recovery.

Native Recovery Records

Internal tasks are stored in .pdu-work beneath the launch directory, retaining success, failure, errors and checkpoints.

After export, record PDU’s native success and failure counts and original errors, retaining checkpoints. Resume uses native records and file metadata without rereading exported data or automatic trial import.

Prerequisites

  • Alongside the database subdirectory, preserve required system dictionaries, FRM/SDI and external tablespaces.
  • A subdirectory alone does not guarantee successful initialization. Use file extraction or DropScan when metadata is missing.
  • Prepare a matching program, license and sufficient space. Keep original evidence read-only and place the PDU launch directory outside the sources.

Important Notes

  • Preserve system and external tablespaces required by target tables; do not trim sources by database directory alone.
  • Keep results from different databases distinct and decide target imports separately.
View Detailed Steps for This Recovery Method
MySQL 场景案例