Kort svar: “Table is marked as crashed” betyder, at en databasetabel blev efterladt i en inkonsistent tilstand – typisk efter en afbrudt skrivning. Tag en databasebackup først. Reparér derefter tabellen med REPAIR TABLE via phpMyAdmin, WP-CLI eller WordPress’ eget reparér-værktøj. Og forebyg gentagelser: crashede tabeller er næsten altid MyISAM – konverter dem til InnoDB, og tjek at disken ikke løber fuld.
Symptomerne kan være mærkeligt lokale: widgets forsvinder, indstillinger nulstilles tilsyneladende, søgning fejler, eller dele af wp-admin viser databasefejl – mens resten af sitet kører. I loggen står beskeden klart: Table ‘./db/wp_options’ is marked as crashed and should be repaired. Den her guide reparerer tabellen sikkert og sørger for, at det ikke sker igen.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt og viser mekanismen – det er ikke output fra hostious.io.
Beskeden hører til lagringsmotoren MyISAM. Når en skrivning bliver afbrudt midtvejs – fordi databaseserveren genstartede, disken løb fuld, eller en proces blev dræbt – passer tabellens indeks ikke længere til dens data, og MySQL markerer den som crashed. Den moderne motor InnoDB fører en transaktionslog og retter den slags selv ved opstart; derfor ser man stort set kun fejlen på ældre tabeller, der stadig kører MyISAM.
Rammer fejlen wp_options, kan hele sitet gå ned med en databasefejl – er du der, så se også guiden om fejl ved oprettelse af databaseforbindelse, som dækker de bredere databasenedbrud.
REPAIR TABLE er normalt sikker, men den kan kassere ødelagte rækker for at få tabellen konsistent. Eksportér derfor databasen først – via kontrolpanelets backup-funktion, phpMyAdmin (Eksportér → SQL) eller wp db export. Få minutters arbejde, og du kan altid komme tilbage til udgangspunktet.
Fejlbeskeden i loggen nævner én tabel, men der kan være flere. Tjek dem samlet:
I phpMyAdmin kan du markere alle tabeller og vælge Check table i rullemenuen – så får du samme overblik uden terminal.
Vælg den vej, du har adgang til – resultatet er det samme:
wp db repair reparerer alle tabeller i én omgang.define( 'WP_ALLOW_REPAIR', true ); i wp-config.php, åbn /wp-admin/maint/repair.php, og kør reparationen. Fjern linjen igen bagefter – siden kræver ikke login, så den må ikke blive stående åben.En repareret MyISAM-tabel er stadig en MyISAM-tabel – og dermed klar til at crashe igen ved næste afbrydelse. Tjek motoren i phpMyAdmin (kolonnen “Type”/“Engine”) eller med SHOW TABLE STATUS;. Konverterér MyISAM-tabeller med ALTER TABLE wp_options ENGINE=InnoDB; – én tabel ad gangen, uden for spidsbelastning.
Undersøg samtidig den udløsende årsag: en disk der løber fuld (tjek forbruget i kontrolpanelet), gentagne genstarter af databasen eller backupjobs, der låser tabeller i timevis. På Hostious kører databaser på InnoDB som standard, og supporten kan hjælpe med konverteringen, hvis dit site er flyttet ind med gamle MyISAM-tabeller.
Sagen er lukket, når CHECK TABLE melder OK for alle tabeller, symptomerne (tomme widgets, fejlende søgning) er væk, loggen ikke får nye “marked as crashed”-linjer, og WP_ALLOW_REPAIR-linjen er fjernet fra wp-config.php igen. Vender fejlen tilbage på samme tabel, er det den underliggende årsag – disk, genstarter eller motoren – der ikke er løst endnu.
Som regel ikke – reparationen genopbygger primært indekset. Men stærkt ødelagte rækker kan blive kasseret, og derfor tager du backup først. Så er værste udfald, at du gendanner og prøver en anden vej.
Fordi årsagen består: MyISAM-tabeller kombineret med en disk, der løber fuld, eller en database, der bliver afbrudt. Konverter til InnoDB og få styr på diskplads og stabilitet – så stopper mønsteret.
Spørg først. På administreret WordPress-hosting er databasedrift en del af ydelsen – hos Hostious må du gerne bede supporten køre tjek, reparation og konvertering for dig.