Fix “One or more database tables are unavailable” in WordPress

Checked 11 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

WordPress keeps its settings in the wp_options table, and it checks that table on every page load. If the table cannot be read — deleted by a bad migration, dropped by a failed restore, or damaged — WordPress cannot tell whether the site is installed at all, and it stops with a database error instead of the site. The front end shows the terse “Error establishing a database connection” page, and wp-admin shows the longer message this guide is named for, with a link to the database repair page.

This guide reproduces the break first. A disposable install had its wp_options table renamed away, which is the missing-table equivalent of a table lost in a migration. The homepage returned HTTP 500 with the database error page, and wp-admin returned HTTP 500 with the “tables unavailable” message. The table was then restored, and both came back.

What you need

• Access to the database (phpMyAdmin, your host database manager, or WP-CLI with database access).
• A database backup from before the break — the fix is a restore, not a repair.
• A backup or a staging copy if this is a live site, before touching the database further.

The diagnosis

1. Confirm the symptom on both sides

Load the homepage and wp-admin and note what each shows. In the reproduction, the homepage returned HTTP 500 with the database error page:

Output — homepage with wp_options missing

HTTP 500
<title>Database Error</title>
Error establishing a database connection

wp-admin returned HTTP 500 with the message that names the problem:

Output — wp-admin with wp_options missing

HTTP 500
One or more database tables are unavailable. The database may need
to be repaired.

2. List the tables and find the missing one

Open the database in phpMyAdmin or your host database manager and compare the tables against the ones WordPress expects — wp_options, wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_terms, and the rest. With WP-CLI, the same check is one command:

Command — list the tables

wp db tables

In the reproduction the list had wp_posts, wp_postmeta, and the rest — but no wp_options. That is the table WordPress reads first on every load, which is why its absence stops the whole site rather than one part of it.

One surprise from the reproduction is worth knowing: a missing wp_posts alone does not produce this message. With only that table renamed away, the homepage still returned HTTP 200 and simply showed no posts. The “tables unavailable” message appears when the options table cannot be read, because that is the check WordPress runs before anything else.

The fix

3. Restore the missing table from backup

Restore the missing table from your database backup — in phpMyAdmin, import the backup or the single table; with WP-CLI, restore the database the way your backup tool expects. In the reproduction the renamed table was restored in place, and the homepage returned HTTP 200 immediately:

Command — restore the table (reproduction)

wp db query "RENAME TABLE wp_options_bak TO wp_options;"

Output — homepage after restoring the table

HTTP 200
<title>SRM Test</title>

Verify the site is back

Load the homepage and wp-admin again and check both status codes. In the reproduction both returned HTTP 200 after the table was restored, with the posts, users, and settings intact.

If that didn’t work

If a table is damaged rather than missing, use the repair page

A missing table cannot be repaired — only restored. But a table that exists and is damaged is a different case, and WordPress ships a repair page for it. Add this line to wp-config.php, before the line that reads /* That's all, stop editing! Happy blogging. */:

Code — wp-config.php

define( 'WP_ALLOW_REPAIR', true );

Then open wp-admin/maint/repair.php. In the reproduction that page returned HTTP 200 with “Repair Database” and “Repair and Optimize Database” buttons. The official common-errors guide gives the same route through phpMyAdmin — run CHECK and REPAIR on the damaged table — and warns to back up the database before doing anything to it. Remove the WP_ALLOW_REPAIR line from wp-config.php when you are done: the repair page is open to anyone while the line is there.

If there is no backup

Without a backup there is nothing to restore the table from. The options table holds the site URL, the active theme and plugins, and every setting — it cannot be rebuilt from the files. In that case the recovery is a professional one: a host restore from their own backups, or a rebuild of the settings by hand on a fresh install with the surviving content tables imported. This is the case for keeping database backups in the first place.

What happened

The wp_options table was missing from the database, so WordPress could not read its settings and stopped with a database error — terse on the front end, verbose in wp-admin. The table list showed which one was missing, the table was restored from backup, and the homepage and wp-admin returned HTTP 200.

Where this came from

• The “Error establishing a database connection” causes, and the repair-table route for a damaged table — with the warning to back up first — come from Common WordPress errors — WordPress.org.
• The repair page at wp-admin/maint/repair.php, and the WP_ALLOW_REPAIR line that unlocks it, are WordPress core — read in the installed 7.1.4 source and verified by loading the page.
• The front end showing only the terse message while wp-admin shows the verbose one is WordPress core — dead_db() in wp-includes/functions.php, read in the installed 7.1.4 source.