Databasetabel beskadiget: „marked as crashed“ – reparér sikkert

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, find alle ramte tabeller med CHECK TABLE, og reparér dem med REPAIR TABLE via phpMyAdmin, WP-CLI eller WordPress’ eget reparationsværktøj. Forebyg gentagelser: crashede tabeller er næsten altid MyISAM, så konvertér dem til InnoDB, og sørg for, at disken ikke løber fuld.

Fagligt gennemgået: 2. oktober 2026

Symptomerne kan være mærkeligt lokale: widgets forsvinder, indstillinger ser ud til at være nulstillet, søgningen 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.

Denne guide viser, hvordan du reparerer tabellen sikkert, hvad du gør, hvis reparationen fejler, og hvordan du sørger for, at det ikke sker igen.

Før du ændrer noget: Tag en fuld eksport af databasen, og notér, hvilke tabeller fejlbeskeden nævner. Kør ikke reparationer, konverteringer eller myisamchk, mens en import, en backup eller et stort plugin-job kører mod samme database.

Hvorfor crasher en tabel?

Beskeden hører til lagringsmotoren MyISAM (og MariaDB’s beslægtede motor Aria). 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 databasen 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 – ofte på sites, der er installeret for mange år siden, eller på tabeller, som et plugin har oprettet med MyISAM som motor.

De typiske udløsere er:

• Fuld disk eller kvote: databasen kan ikke skrive færdig og efterlader halve indeksopdateringer.
• Uventet genstart: databaseserveren eller hele serveren stopper uden en ren nedlukning.
• Dræbte processer: en langvarig forespørgsel bliver afbrudt, mens den skriver til tabellen.
• Kopiering af rå databasefiler: filerne er kopieret, mens databasen kørte, i stedet for at blive eksporteret.

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.

Sådan genkender du fejlen

Fejlen viser sig forskelligt, alt efter hvilken tabel der er ramt. Brug tabellen til at koble symptomet til den sandsynlige tabel, før du går i gang:

Symptom	Sandsynlig tabel	Bemærkning
Hele sitet viser databasefejl	wp_options	WordPress kan ikke læse sine grundindstillinger
Indlæg eller sider mangler, søgning fejler	wp_posts eller wp_postmeta	Ofte delvise fejl på bestemte sider
Login eller brugerprofiler driller	wp_users eller wp_usermeta	Kan ligne et rettighedsproblem
Kategorier og menuer forsvinder	wp_terms, wp_term_taxonomy, wp_term_relationships	Menuer gemmes også som termer
Fejl kun i et bestemt plugin	Pluginets egne tabeller (logs, statistik, sessions)	Logtabeller vokser ofte hurtigt og crasher oftere

Fejlnummeret siger også noget. Error 145 svarer til „marked as crashed and should be repaired“, mens Error 144 betyder „crashed and last repair failed“ – altså at databasen allerede har forsøgt en reparation uden held. Det sidste kræver lidt mere omtanke, se afsnittet om reparationer, der fejler.

1. Tag en backup før alt andet

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 backupfunktion, phpMyAdmin (Eksportér → SQL) eller WP-CLI. Få minutters arbejde, og du kan altid komme tilbage til udgangspunktet.

wp db export backup-foer-reparation.sql

Fejler eksporten på netop den crashede tabel, så eksportér resten af databasen og notér, hvilken tabel der ikke kom med. En nylig automatisk backup fra hostingen er også et godt sikkerhedsnet – tjek datoen, før du stoler på den.

2. Find de ramte tabeller

Fejlbeskeden i loggen nævner én tabel, men der kan være flere. Tjek dem samlet:

Med WP-CLI tjekker du hele databasen på én gang. Kommandoen bruger værktøjet mysqlcheck i baggrunden:

wp db check

Vil du tjekke en enkelt tabel direkte i SQL, fx i phpMyAdmins SQL-fane:

CHECK TABLE wp_options;

I phpMyAdmin kan du også markere alle tabeller og vælge Check table i rullemenuen – så får du samme overblik uden terminal. Kig efter rækker, hvor status ikke er OK.

3. Reparér tabellen

Vælg den vej, du har adgang til – resultatet er det samme:

• phpMyAdmin: markér de ramte tabeller, og vælg Repair table. Enkelt og visuelt.
• WP-CLI: wp db repair reparerer alle tabeller i én omgang.
• SQL: REPAIR TABLE wp_options; reparerer én navngiven tabel.
• WordPress’ eget værktøj: tilføj linjen nedenfor 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.

define( 'WP_ALLOW_REPAIR', true );

WordPress’ værktøj har to knapper: „Repair Database“ og „Repair and Optimize Database“. Brug den første. Optimering genopbygger tabellerne og kan tage lang tid på store databaser – det er ikke nødvendigt for at løse fejlen.

Kør CHECK TABLE igen bagefter. Melder alle tabeller OK, er selve reparationen lykkedes.

Når reparationen fejler

Får du „The storage engine for the table doesn’t support repair“, er tabellen InnoDB – og så er det ikke MyISAM-fejlen, du står med. InnoDB-korruption håndteres helt anderledes (bl.a. med serverindstillingen innodb_force_recovery) og er en opgave for hostingudbyderen eller en databaseadministrator, ikke noget, du bør prøve dig frem med på et live-site.

Melder en MyISAM-tabel stadig fejl efter en almindelig reparation, er der tre muligheder i stigende risiko:

1. Grundigere reparation: REPAIR TABLE wp_options EXTENDED; genopbygger indekset række for række. Det er langsommere, men finder mere.
2. Gendan tabellen fra backup: er tabellen lille eller sjældent ændret, er det ofte hurtigere at gendanne netop den tabel fra den seneste gode backup.
3. Serverværktøjer: myisamchk og REPAIR TABLE … USE_FRM er sidste udveje. myisamchk må ikke køre, mens databaseserveren bruger tabellen, og USE_FRM findes ikke i MySQL 8. Lad hostingudbyderen stå for begge.

Er den ramte tabel en ren logtabel fra et plugin – fx besøgsstatistik eller en redirect-log – kan det være enklere at tømme den med pluginets egen funktion i stedet for at redde gamle logrækker. Tjek først, at tabellen ikke indeholder data, du har brug for.

4. Forebyg: konvertér til InnoDB

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“ eller „Engine“), eller find alle MyISAM-tabeller i databasen med denne forespørgsel:

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND ENGINE = 'MyISAM';

Konvertér derefter tabellerne én ad gangen, uden for spidsbelastning:

ALTER TABLE wp_options ENGINE=InnoDB;

Tre ting er værd at vide før konverteringen:

• Reparér først: konvertér ikke en tabel, der stadig er markeret som crashed. Kør reparationen og CHECK TABLE, og konvertér bagefter.
• Plads og tid: ALTER TABLE bygger tabellen op på ny, så der skal være ledig diskplads svarende til mindst tabellens størrelse, og store tabeller kan være låst i et stykke tid.
• Fuldtekstsøgning: moderne MySQL- og MariaDB-versioner understøtter FULLTEXT-indeks i InnoDB, så plugins med egen søgning fungerer normalt fint efter konverteringen. Test søgningen bagefter.

5. Find den udløsende årsag

Konverteringen fjerner sårbarheden, men årsagen kan stadig give andre problemer. Undersøg derfor:

• Diskforbruget: tjek forbruget i kontrolpanelet. Ligger du tæt på grænsen, så ryd op i gamle backups, logfiler og revisioner, eller opgradér pladsen.
• Genstarter: spørg hostingudbyderen, om databaseserveren har været genstartet eller er løbet tør for hukommelse på tidspunktet for fejlen.
• Tunge job: backupjob, imports og oprydningsplugins, der låser tabeller længe, kan blive afbrudt af timeouts. Læg dem uden for travle tidspunkter.

Er dit site flyttet ind med gamle MyISAM-tabeller, kan supporten hjælpe med tjek, reparation og konvertering.

6. Bekræft, at sagen er lukket

Sagen er lukket, når alle punkter er opfyldt:

• CHECK TABLE (eller wp db check) melder OK for alle tabeller.
• Symptomerne – tomme widgets, fejlende søgning, databasefejl i wp-admin – er væk.
• Loggen får ingen nye „marked as crashed“-linjer det næste døgn.
• Forespørgslen efter MyISAM-tabeller returnerer ingen rækker.
• Linjen med WP_ALLOW_REPAIR 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.

Læs også

• Hub: WordPress fejl og fejlfinding
• Fejl ved oprettelse af databaseforbindelse i WordPress
• Kritisk fejl i WordPress: find den konkrete PHP-fejl
• Hvad er en MySQL-database?
• WordPress hosting hos Hostious – daglig backup med selvbetjent gendannelse og dansk support døgnet rundt

Ofte stillede spørgsmål om crashede tabeller

Mister jeg data ved REPAIR TABLE?

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.

Hvorfor sker det igen og igen?

Fordi årsagen består: MyISAM-tabeller kombineret med en disk, der løber fuld, eller en database, der bliver afbrudt. Konvertér til InnoDB, og få styr på diskplads og stabilitet – så stopper mønsteret.

Kan en InnoDB-tabel også blive „marked as crashed“?

Nej, beskeden hører til MyISAM og Aria. InnoDB retter afbrudte skrivninger selv via sin transaktionslog. Er en InnoDB-tabel beskadiget, ser fejlen anderledes ud og skal håndteres af hostingudbyderen.

Skal jeg selv reparere på administreret hosting?

Spørg først. På administreret WordPress-hosting kan supporten ofte køre tjek, reparation og konvertering for dig – hos Hostious kan du kontakte den danske support døgnet rundt.