The database Repair action is not a universal fix. It can apply to supported table engines, but ordinary REPAIR TABLE does not repair InnoDB tables in the same way. Diagnose the error and engine before running it.
IN THIS ARTICLE
What you need before you begin
Obtain a current recoverable backup where possible and preserve the error message. Identify the affected database and tables, their storage engines and the service impact. Schedule a maintenance window because checking or repairing tables can block application work.
01 Check whether a DirectAdmin database repair is appropriate
- Review the application and database errors to distinguish corruption from a wrong password, full disk, missing table or invalid query.
- Use the database-management or phpMyAdmin view to identify the affected table engine. If you cannot establish it safely, ask support before attempting repair.
- For an engine that supports the panel repair operation, open MySQL Management, select only the intended database and choose Repair. Read the result for each table.
- For InnoDB corruption or repeated storage errors, stop and involve the server administrator. Recovery may require a backup restore or an engine-specific recovery procedure, not repeated repair clicks.
- After the chosen recovery action, test the application and investigate the original cause, including disk capacity or host storage faults.
02 Example: identify the table engine before repair
Select the intended prefixed database in phpMyAdmin or another authorised SQL client, then inspect its tables with:
SHOW TABLE STATUS;Locate the affected table and read its Engine value. This command reports table information; it does not repair anything. If the table uses InnoDB, retain the original error and follow the administrator-led recovery route described above. If the result is unavailable or unclear, stop before attempting repair and ask support to identify the engine.
How do I verify the database after a repair?
Check the detailed repair or recovery report and validate meaningful records and application writes. A single success message does not establish that all data relationships and business records are correct.
Troubleshoot unexpected results
If repair reports unsupported engine, failed recovery or recurring corruption, preserve the logs and escalate. Do not delete database files, force recovery modes or rebuild tables blindly from a shared-hosting account. Keep the original backup and incident evidence until the recovered database is verified.