REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE repariert eine unter
Umständen beschädigte Tabelle. Standardmäßig hat dies
dieselbe Wirkung wie myisamchk --recover
tbl_name. REPAIR
TABLE funktioniert bei MyISAM-
und ARCHIVE-Tabellen. Siehe auch
Abschnitt 14.1, „Die MyISAM-Speicher-Engine“, und
Abschnitt 14.8, „Die ARCHIVE-Speicher-Engine“.
Im Normalfall werden Sie diese Anweisung niemals ausführen.
Im Katastrophenfall kann REPAIR TABLE Ihnen
aber sehr wahrscheinlich alle Daten aus einer
MyISAM-Tabelle wiederherstellen. Treten bei
Ihren Tabellen häufig Beschädigungen auf, dann sollten Sie
versuchen, den Grund dafür zu ermitteln, um REPAIR
TABLE nicht mehr fortlaufend einsetzen zu müssen.
Siehe auch Abschnitt A.4.2, „Was zu tun ist, wenn MySQL andauernd abstürzt“, und
Abschnitt 14.1.4, „MyISAM-Tabellenprobleme“.
Warnung: Wenn sich der Server
während eines REPAIR TABLE-Vorgangs
aufhängt, ist es unabdingbar, unmittelbar nach dem Neustart
eine neue REPAIR TABLE-Anweisung für die
Tabelle abzusetzen, bevor Sie weitere Operationen an ihr
vornehmen. (Es bietet sich ohnehin immer an, zuallererst ein
Backup zu erstellen.) Im schlimmsten Fall haben Sie unter
Umständen eine neue saubere Indexdatei ohne Informationen zur
Datendatei – und könnten im nächsten Schritt
möglicherweise Ihre Datendatei überschreiben! Dies ist ein
unwahrscheinliches, aber durchaus mögliches Szenario.
REPAIR TABLE gibt eine Ergebnismenge mit
den folgenden Spalten zurück:
| Spalte | Wert |
Table |
der Tabellenname |
Op |
ist immer repair
|
Msg_type |
status, error,
info oder
warning
|
Msg_text |
die Nachricht |
Die Anweisung REPAIR TABLE kann unter
Umständen viele Datensätze für die reparierte Tabelle
ausgeben. Der letzte Datensatz hat den
Msg_type-Wert status;
Msg_test sollte normalerweise den Wert
OK haben. Wenn Sie einen anderen Status als
OK erhalten, sollten Sie die Tabelle mit
myisamchk --safe-recover zu reparieren
versuchen. (REPAIR TABLE implementiert noch
nicht alle Optionen von myisamchk. Wir
beabsichtigen aber, die Anweisung in Zukunft flexibler zu
gestalten.) Mit myisamchk --safe-recover
können Sie auch Optionen verwenden, die REPAIR
TABLE nicht unterstützt (z. B.
--max-record-length).
Wenn QUICK angegeben wird, versucht
REPAIR TABLE, nur den Indexbaum zu
reparieren. Dieser Reparaturtyp ähnelt dem von
myisamchk --recover --quick.
Wenn Sie EXTENDED verwenden, erstellt MySQL
den Index Datensatz für Datensatz, statt einen Index
gleichzeitig beim Sortieren zu erzeugen. Dieser Reparaturtyp
ähnelt dem von myisamchk --safe-recover.
Es gibt auch einen Modus USE_FRM für
REPAIR TABLE. Diesen verwenden Sie, wenn
die .MYI-Indexdatei fehlt oder ihr Header
beschädigt ist. In diesem Modus erstellt MySQL die
.MYI-Datei auf der Basis der Daten aus
der .frm-Datei neu. Diese Art der
Reparatur ist mit myisamchk nicht möglich.
Hinweis: Verwenden Sie diesen
Modus nur, wenn Sie die regulären
REPAIR-Modi nicht einsetzen können. Der
.MYI-Header enthält wichtige
Tabellenmetadaten (insbesondere etwa den
AUTO_INCREMENT-Wert und Delete
link), die bei REPAIR ... USE_FRM
verloren gehen. Verwenden Sie USE_FRM nicht
für eine komprimierte Tabelle, weil diese Informationen auch
in der .MYI-Datei gespeichert sind.
REPAIR TABLE-Anweisungen werden in das
Binärlog geschrieben, sofern das optionale Schlüsselwort
NO_WRITE_TO_BINLOG (oder sein Alias
LOCAL) nicht verwendet wird. Dies wird
gemacht, damit REPAIR TABLE-Anweisungen,
die auf einem MySQL Server verwendet werden, der als
Replikationsmaster agiert, standardmäßig auf den
Replikationsslave repliziert werden.
Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.
