[Erledigt] Nach Tabellenoptimierung kein Zugriff mehr möglich

Hallo, ich hab folgendes Problem:

ich wollte eine mysql-tabelle optimieren, um nicht mehr verwendete ID's zu entfernen.
Nun komm ich nicht mehr an meine Tabelle ran und krieg immer die Meldung

Can't open file: 'rechnungen.MYD'. (errno: 144)

Und in der Übersicht wird die Tabelle als "in Benutzung" geführt.

Neustart von mysql war ohne Erfolg.

Weiß jemand, wie man das wieder hinkriegt, ohne die Daten zu verlieren

Re: Nach Tabellenoptimierung kein Zugriff mehr möglich

mysql-tabelle optimieren, ... Nun komm ich nicht mehr an meine Tabelle ran und krieg immer die Meldung

Can't open file: 'rechnungen.MYD'. (errno: 144)

Neustart von mysql war ohne Erfolg.
Weiß jemand, wie man das wieder hinkriegt, ohne die Daten zu verlieren

Wie es aussieht, hast Du die Daten schon verloren, falls der Task mit OPTIMIZE schon beendet ist/sein sollte.

Backup vorrätig?

Backup hab ich nicht, weil es nur die Testversion war, um das Script zu testen, stand eh nur blabla drin.

Aber wenn das Script zum Einsatz kommt, dann stehen schon Daten drin, die wichtig sind, insofern wäre es gut zu wissen, wie man sowas ausbügeln kann (außer dem Backup, denn das ist ja auch nur die nicht-optimierte Tabelle).

Backup hab ich nicht, weil es nur die Testversion war, um das Script zu testen, stand eh nur blabla drin.

Wäre es zuviel verlangt, wenn man mal den SQL String sehen möchte?

Aber wenn das Script zum Einsatz kommt, dann stehen schon Daten drin, die wichtig sind, ...

Gute Idee, sowas mal als Trockentraining zu testen.

String her und auf lazydog (hoffentlich richtig geschrieben) u/o Guradia warten. SQL ist für mich noch Arbeit.

[Guradia]

Im moment kann ich nur sagen, dass mir sowas mit Regelmässigkeit bei einer Tabelle `usrOnline` geschieht, wenn ich den mysqld im Betrieb runterfahren muss.

Diese Tabelle lässt sich nach restart dann meist auch nicht mehr öffnen. Gag dabei ist, dass Optimize die Tabelle wieder flott macht. Obs mir dabei die Daten zerhaut, habe ich bislang keinen Gedanken dran verschwendet. Die Registratur für online befindliche User ist nach 5 Minuten ohnehin veraltet ^^

@meikel:

Was den SQL-string angeht, so weiß ich nicht recht, welchen du meinst:

der Befehl ist

$sql = "OPTIMIZE TABLE 'rechnungen' ";

alles andere macht phpmyadmin.

Die Fehlermeldungen hätte ich gern komplett gepostet, aber zur Zeit funktionierts mal wieder ohne Probleme, sodass ich nun auch kein System dahinter entdecken kann.

Da ich diese Datensätze manuell mit phpmyadmin lösche,
sollte ich im Normalfall auch korrekte Befehle und SQL Strings zur Verfügung haben.

Daran und an dem "Trockentraining" sieht man, dass ich in dieser Richtung noch "Nachholebedarf" habe: ich kann mich eben nicht darauf verlassen, dass das, was ich zusammenprogge, auch 100%-ig läuft. :wink:

Dringender Tip:
1. lock tables ... (mindestens Schreibschutz)
2. optimize table
3. unlock tables

MySQL müllt, wenn in der Struktur Spalten mit variabler Länge enthalten sind. Dann wird intern beim Update der Datensatz neu angelegt und die Quelle als gelöscht gekennzeichnet. Zusätzlich verwaltet MySQL die Tabellen im "page modus", dh. es werden nicht die paar "neuen" Bytes hinten ans File angehängt sondern sozusagen eine "neue Seite" angelegt, die langsam gefüllt wird.

Wenn MySQL so sagen wir mal 100 Pages angelegt hat, weil es in der Tabelle viele Veränderungen gab, isses möglich, daß 99% Müll sind. Wird eine solche Tabelle optimiert, ist es ratsam, die Tabelle zu sperren, damit mysql dabei nicht gestört wird. Optimize findet im Hintergrund statt.

Auf großen Kisten wird Optimize deshalb des nächtens per Crontab gestartet, nachdem die Applikation in einen "stand by" modus gefahren wurde.