636 MySQL - Technische Referenz f¨ur Version 5.0.1-alpha
• Benutzen Sie mysqld --log und versuchen Sie den Informationen im Log zu entnehmen,
ob eine bestimmte Anfrage den Server killt oder nicht. Etwa 95% aller Bugs beziehen
sich auf eine bestimmte Anfrage! Normalerweise ist das eine der letzten Anfragen in
der Log-Datei, direkt bevor MySQL neu startete. Siehe Abschnitt 5.9.2 [Query log],
Seite 302. Wenn Sie MySQL wiederholt mit einer der Anfragen killen, selbst wenn Sie
alle Tabellen direkt vor der Ausf¨uhrung der Anfrage ¨uberpr¨uft haben, haben Sie den
Bug eingegrenzt und sollten daf¨ur einen Bug-Bericht schreiben! Siehe Abschnitt 2.6.2.3
[Bug reports], Seite 30.
• Versuchen Sie, einen Testfall herzustellen, den wir zur Reproduzierung des Problems
verwenden k¨onnen. Siehe Abschnitt D.1.6 [Reproduceable test case], Seite 699.
• Versuchen Sie, die beigef¨ugten mysql-test test und MySQL-Benchmarks laufen zu
lassen. Siehe Abschnitt 10.3.2 [MySQL-Test-Suite], Seite 618. Sie k¨onnen MySQL recht
gut pr¨ufen. Sie k¨onnen den Benchmarks auch selbst Code hinzuf¨ugen, der Ihre App-
likation simuliert! Die Benchmarks finden sich im ‘bench’-Verzeichnis in der Quelld-
istribution oder bei einer Bin¨ardistribution im ‘sql-bench’-Verzeichnis unter Ihrem
MySQL-Installationsverzeichnis.
• Probieren Sie fork_test.pl und fork2_test.pl.
• Wenn Sie MySQL zum Debuggen konfigurieren, ist es wesentlich einfacher, Informa-
tionen ¨uber m¨ogliche Fehler zu erhalten, wenn etwas schief geht. Konfigurieren Sie
MySQL mit der --with-debug-Option oder mit der --with-debug=full-Option f¨ur
configure neu und kompilieren Sie neu. Siehe Abschnitt D.1 [Debugging server],
Seite 694.
• Wenn MySQL zum Debuggen konfiguriert wird, wird ein sicherer Speicher-Zuweiser
(Memory Allocator) hinzugef¨ugt, der einige Fehler finden kann. Ausserdem erfolgen
etliche Ausgaben ¨uber das, was gerade geschieht.
• Haben Sie die neuesten Patches f¨ur Ihr Betriebssystem installiert?
• Benutzen Sie die --skip-locking-Option f¨ur mysqld. Auf manchen Systemen arbeitet
der lockd-Sperrmanager nicht korrekt. Die --skip-locking-Option weist mysqld an,
keine externen Sperren zu benutzen. (Das heißt, dass Sie nicht zwei mysqld-Server
auf denselben Daten laufen lassen k¨onnen und dass Sie vorsichtig sein m¨ussen, wenn
Sie myisamchk benutzen, aber es kann aufschlussreich sein, die Option testweise zu
benutzen.)
• Haben Sie mysqladmin -u root processlist ausprobiert, wenn mysqld zu laufen
scheint, aber nicht antwortet? Manchmal ist mysqld nicht komat¨os, obwohl es so
aussieht. Das Problem kann darin bestehen, dass alle Verbindungen in Benutzung
sind, oder es kann ein internes Sperrproblem vorliegen. mysqladmin processlist ist
¨ublicherweise in der Lage, in solchen F¨allen eine Verbindung aufzubauen und kann
n¨utzliche Informationen ¨uber die momentane Anzahl von Verbindungen und ihren
Status liefern.
• Lassen Sie den Befehl mysqladmin -i 5 status oder mysqladmin -i 5 -r status in
einem separaten Fenster laufen, um statistische Informationen auszugeben, w¨ahrend
Sie Ihre anderen Anfragen laufen lassen.
• Versuchen Sie folgendes:
1. Starten Sie mysqld von gdb aus (oder in einem anderen Debugger). Siehe Ab-
schnitt D.1.3 [Using gdb on mysqld], Seite 696.
Comentários a estes Manuais