Sollte sich MySQL mit einem Fehler wie

Table '<Tabellenname>' is marked as crashed and should be repaired

zu Wort melden, so hilft in der Regel ein

mysql> check table <Tabellenname>;

mysql> repair table <Tabellenname>;

damit die Welt wieder in Ordnung ist:

+----------------+-------+----------+----------+
| Table          | Op    | Msg_type | Msg_text |
+----------------+-------+----------+----------+
| <Tabellenname> | check | status   | OK       |
+----------------+-------+----------+----------+
1 row in set (0.01 sec)

Manchmal sind es die einfachen Dinge, die man immer wieder nachschlagen muß …

Eine Liste der Datenbanken eines MySQL-Servers spuckt der Befehl

SHOW DATABASES;

aus, währen die vorhandenen Tabellen einer Datenbank mit dem Befehl

SHOW TABLES IN <datenbankname>;

ermittelt werden können. Wahlweise kann an letzteren auch noch eine LIKE-Bedingung angehängt werden.

Alternativ zu den oben genannten Befehlen kann auch die Datenbank “information_schema” befragt werden. So liefert ein

SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA;

ebenfalls eine Liste der Datenbanken, während man die Tabellen einer Datenbank mittels

SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='<datenbankname>';

ermitteln kann.

Ab und an kann es passieren, daß sich MySQL beim AUTOINCREMENT verschluckt und versucht, einen Wert anzulegen, der bereits existiert.

Zur Fehlerbehebung gilt es, den aktuellen AUTOINCREMENT-Wert zu ermitteln, der nach dem Ausführen von

mysql> SHOW TABLE STATUS FROM <datenbank> WHERE Name = '<tabelle>';

in der Spalte ‘Auto_increment’ zu finden ist. Anschließend kann mittels

mysql> ALTER TABLE <tabelle> AUTO_INCREMENT = <wert>;

ein neuer Startwert gesetzt werden.

Nachdem monatelang Apache 2.0.63, PHP 5.2.6 und MySQL 5.0.51 in trauter Einigkeit gewerkelt haben, wurde - never change a running System - zeitgleich mit einem Hardware-Upgrade auch eine Betriebssystem-Neuinstallation sowie ein Update der installierten Software auf die jeweils aktuellen Versionen vorgenommen.

Der Apache blieb bei der alten Version, PHP auf 5.2.9 modernisiert und auch MySQL auf die Version 5.1.35 angehoben. Die Installation lief problemlos und auch der obligatorische Aufruf eines phpinfo(); zeigte im Browser das erwartete Ergebnis.

Weniger erwartet war aber, daß sich beim Aufruf fast jeder lokalen PHP-Seite der Webserver mit einem “Application Error” verabschiedete und Windows gerne einen Bericht an Microsoft schicken wollte. Die einzige Gemeinsamkeit an den nicht funktionierenden Seiten waren Zugriffe auf die Datenbank, immerhin eine Spur.

Nachdem ein testweises Downgrade von PHP keine Änderung (= Linderung) des Problems brachte, hat der Rückschritt auf den 5.0’er MySQL die Symptome wie von Geisterhand kuriert

Die Ursache? Wahrscheinlich irgendwo im Zusammenhang mit “MySQLs PHP-API”, aber nachdem es weder in den Windows-Protokollen (daß Apache abgeschmiert ist, weiß ich selbst) noch in den Apache-Logs (die “error.log” ist eben kein Crash-Log) einen brauchbaren Anhaltspunkt zur Fehlersuche gibt, wird die Lösung erstmal vertagt.

Manchmal können komplizierte Dinge so einfach sein - mit dem richtigen Parameter klappt der Import von Unicode-Dateien problemlos über die MySQL-Kommandozeile:

mysql --default_character_set utf8 datenbank < sql-file