Thomas: präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

SELF-Forum

präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

Thomas
– Informationen zu den Bewertungsregeln

Hallo zusammen,

In den vergangenen 3 Wochen hatte ich zweimal ein Problem mit MySQL.
Und zwar war eine Tabelle beschädigt, weshalb auf diese Tabelle kein Zugriff mehr möglich war.

Da es beide male meine Benutzer-Tabelle erwischt hatte, war leider kein Login auf meine Webseite mehr möglich!
Durch Reparieren der Tabelle konnte das Problem behoben werden.

Aber leider bin ich natürlich keine 24 Stunden am Tag online, und falls das Problem wieder auftritt, kann ich wahrscheinlich nicht schnell genug reagieren, so dass den Nutzern vermutlich wieder eine Zeitspanne von mehreren Stunden bevorsteht, in der sie sich nicht einloggen können.

Nun zu meiner Frage:

Generell könnte man doch am Anfang des Login-PHP-Skripts den folgenden SQL-Befehl ausführen:

$sql = "REPAIR TABLE tabBenutzer, tabTabelle2, tabTabelle3";
$result = mysql_query($sql);

Wie verhält sich MySQL, wenn ich den REPAIR-Befehl auf eine Tabelle mit dem Status OK ausführe?

Ist diese Vorgehensweise ratsam, oder kann es evtl. die Datenbanktabelle beschädigen oder zu sonstigen Problemen führen, wenn man etwa 100-200 mal pro Tag einen REPAIR-Befehl auf nicht beschädigte Tabellen durchführt?

Gibt es hier evtl. erfahrene MySQL-Benutzer, die mir sagen können, was sie von meiner präventiven Maßnahme halten oder ob es alternative Lösungen für mein Problem gibt?

Vielen Dank vorab für alle hilfreichen Beiträge,
Thomas

Beitrag melden
–
Informationen zu den Bewertungsregeln

  1. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

    globe Homepage des Autors
    – Informationen zu den Bewertungsregeln

    n'abend,

    Generell könnte man doch am Anfang des Login-PHP-Skripts den folgenden SQL-Befehl ausführen:

    $sql = "REPAIR TABLE tabBenutzer, tabTabelle2, tabTabelle3";
    $result = mysql_query($sql);

    Die Mysql Doku sagt, dass du besser mal den Grund für das andauernde Crashen der Tabellen finden solltest.

    Die sollte klar sein, dass REPAIR TABLE auch deine Indexe neu aufbaut [uvm.]. Bei größeren Tabellen mit dem einen oder anderen Index mehr im Boot, kann so ein REPAIR TABLE gut und gerne richtig Zeit in Anspruch nehmen.

    REPAIR TABLE ist ein administrativer Befehl und nichts für den Dauereinsatz in Programmen / Scripts.

    weiterhin schönen abend...

    --
    wer braucht schon großbuchstaben?
    sh:( fo:# ch:# rl:° br:> n4:& ie:{ mo:} va:) de:] zu:} fl:{ ss:? ls:[ js:|
    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

    1. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

      Thomas
      – Informationen zu den Bewertungsregeln

      Hallo globe,

      Vielen Dank für deine schnelle Antwort.

      Die [Mysql Doku](http://dev.mysql.com/doc/refman/4.1/en/repair-
      table.html) sagt, dass du besser mal den Grund
      für das andauernde Crashen der Tabellen finden solltest.

      Da gebe ich dir Recht.
      Ich habe bei meinem Provider auch schon nachgefragt, woran das liegen könnte und wie man das künftig verhindern kann.

      Nach Aussage des Providers könnte die Ursache Abbrüche der Datenbank sein, sodass die Datenbank Dateien auf dem Server nicht gespeichert werden konnten.

      Aber wie kann man das verhindern???

      Welche Ursachen kann ein derartiges Problem sonst noch haben?

      REPAIR TABLE ist ein administrativer Befehl und nichts für den Dauereinsatz in Programmen / Scripts.

      Mit geht es ja nur darum, meine Ausfallzeiten möglichst gering zu halten.
      Wäre es evtl. eine Alternative, zuerst über CHECK TABLE zu prüfen, ob die Datenbanktabellen noch OK sind, und nur im Problemfall zu Beginn des Login-Skripts den REPAIR-Befehl zu starten?

      kann so ein REPAIR TABLE gut und gerne richtig Zeit in Anspruch nehmen.

      Oder nimmt CHECK TABLE ebenso viel Zeit in Anspruch?

      Viele Grüße,
      Thomas

      Beitrag melden
      –
      Informationen zu den Bewertungsregeln

      1. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

        globe Homepage des Autors
        – Informationen zu den Bewertungsregeln

        n'abend,

        Nach Aussage des Providers könnte die Ursache Abbrüche der Datenbank sein, sodass die Datenbank Dateien auf dem Server nicht gespeichert werden konnten.
        Aber wie kann man das verhindern???
        Welche Ursachen kann ein derartiges Problem sonst noch haben?

        du könntest deine Datenbankzugriffe mit ignore_user_abort() ummanteln. Ob das allerdings des Rätsels Lösung ist, weiss ich auch nicht.

        Mit geht es ja nur darum, meine Ausfallzeiten möglichst gering zu halten.
        Wäre es evtl. eine Alternative, zuerst über CHECK TABLE zu prüfen, ob die Datenbanktabellen noch OK sind, und nur im Problemfall zu Beginn des Login-Skripts den REPAIR-Befehl zu starten?

        Du könntest die Fehlermeldungen deiner SQL-Queris auswerten. Du wirst sicher mehrere Tabellen haben, die evtl. zerschossen sein könnten. Darum baue eine Routine in deine Datenbank-Funktionen ein, die prüft ob die Query erfolgreich war. Wenn Sie fehl schlug, solltest du analysieren warum das passiert ist. Wenn es daran lag, dass eine Tabelle nicht ansprechbar ist, dann kannst du einen REPAIR TABLE initiieren.

        Aber wie gesagt.. das sind nur Workarounds..
        Das eigentliche Problem besteht weiterhin: warum verrecken deine Tabellen denn überhaupt?

        Oder nimmt CHECK TABLE ebenso viel Zeit in Anspruch?

        CHECK TABLE nimmt zwar bedeutend weniger Zeit in Anspruch, kostet aber auch Zeit (und einen Lock).

        Hast du die Möglichkeit Cronjobs zu setzen? Wenn ja, dann würde ich derartige Funktionen nicht in den normalen Code integrieren.

        weiterhin schönen abend...

        --
        wer braucht schon großbuchstaben?
        sh:( fo:# ch:# rl:° br:> n4:& ie:{ mo:} va:) de:] zu:} fl:{ ss:? ls:[ js:|
        Beitrag melden
        –
        Informationen zu den Bewertungsregeln

        1. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

          Thomas
          – Informationen zu den Bewertungsregeln

          Hallo,

          Mit geht es ja nur darum, meine Ausfallzeiten möglichst gering zu halten.
          Wäre es evtl. eine Alternative, zuerst über CHECK TABLE zu prüfen, ob die Datenbanktabellen noch OK sind, und nur im Problemfall zu Beginn des Login-Skripts den REPAIR-Befehl zu starten?

          Du könntest die Fehlermeldungen deiner SQL-Queris auswerten. Du wirst sicher mehrere Tabellen haben, die evtl. zerschossen sein könnten. Darum baue eine Routine in deine Datenbank-Funktionen ein, die prüft ob die Query erfolgreich war. Wenn Sie fehl schlug, solltest du analysieren warum das passiert ist. Wenn es daran lag, dass eine Tabelle nicht ansprechbar ist, dann kannst du einen REPAIR TABLE initiieren.

          Das ist ein guter Vorschlag - danke.
          Die einzige Frage ist, wie aufwändig es ist, das in all meine Skripte einzubauen ;-)

          Aber wie gesagt.. das sind nur Workarounds..
          Das eigentliche Problem besteht weiterhin: warum verrecken deine Tabellen denn überhaupt?

          Das ist eine sehr gute Frage, aber ehrlich gesagt hab ich keine Ahnung, wie ich das herausfinden kann...

          Hast du die Möglichkeit Cronjobs zu setzen? Wenn ja, dann würde ich derartige Funktionen nicht in den normalen Code integrieren.

          Ich hab auch schon überlegt, bei jedem Login eine Überprüfung der wichtigsten Datenbanktabellen durchzuführen:

          $sql = "SELECT count(username) FROM tabBenutzer";
          $result = mysql_query($sql);
          list(mysql_fetch_row( $Test );

          if(!$Test)
          {
            $sql = "REPAIR TABLE tabBenutzer, tabTabelle2, tabTabelle3";
            $result = mysql_query($sql);
          }

          Das könnte man nacheinander für alle wichtigen Tabellen des Spiels machen.
          Dadurch würde bei jedem User-Login geprüft werden, ob ein Zugriff auf die wichtigsten Tabellen möglich ist.
          Falls nicht, würde ich standardmäßig versuchen, die betroffenen Tabellen über REPAIR zu reparieren.

          Nun ist die Frage: was würde das für mein Login-Skript bedeuten?

          1. Bis die eigentliche Ursache gefunden ist, warum die Datenbanktabellen überhaupt verrecken, würde das Problem zumindest nicht mehr bestehen, dass alle 2 Wochen der komplette Login nicht mehr funktioniert.

          2. Die Performanvce beim Login würde sinken, da ich diesen Test (eine Testabfrage und anschließend die if-Anweisung, obs funktioniert hat oder nicht) etwa für 60 Datenbanktabellen durchführen müsste.
            Jetzt ist die Frage, wie stark sich diese 60 zusätzlichen Statements auf die Performance auswirken...

          Das ist aber im Moment auf jeden Fall die Vorgehensweise, die mir im Moment am meisten zusagt.

          Viele Grüße,
          Thomas

          Beitrag melden
          –
          Informationen zu den Bewertungsregeln

          1. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

            globe Homepage des Autors
            – Informationen zu den Bewertungsregeln

            n'abend,

            Das ist ein guter Vorschlag - danke.
            Die einzige Frage ist, wie aufwändig es ist, das in all meine Skripte einzubauen ;-)

            schau dir mal solche Dinge wie ADODB an. Du möchtest deine Datenbankzugriffe kapseln. Warum? damit wir - wie z.b. jetzt - spielnd einfach Funktionalitäten hinzufügen können, die alle Queries betreffen.

            Das ist aber im Moment auf jeden Fall die Vorgehensweise, die mir im Moment am meisten zusagt.

            Gut heissen will ich das nicht, davon abhalten werde ich dich - in Ermangelung an sinnvollen Alternativen - aber auch nicht.

            weiterhin schönen abend...

            --
            wer braucht schon großbuchstaben?
            sh:( fo:# ch:# rl:° br:> n4:& ie:{ mo:} va:) de:] zu:} fl:{ ss:? ls:[ js:|
            Beitrag melden
            –
            Informationen zu den Bewertungsregeln

          2. präventiver REPAIR-Befehl auf nicht beschädige Tabellen?

            wahsaga Homepage des Autors
            – Informationen zu den Bewertungsregeln

            hi,

            Die Performanvce beim Login würde sinken, da ich diesen Test (eine Testabfrage und anschließend die if-Anweisung, obs funktioniert hat oder nicht) etwa für 60 Datenbanktabellen durchführen müsste.
            Jetzt ist die Frage, wie stark sich diese 60 zusätzlichen Statements auf die Performance auswirken...

            Klingt auf jeden Fall grauslig ...

            Da würde ich doch schon eher das Testen und ggf. Reparieren per CronJob in regelmässigen Abständen anstossen - wenn der Login mal zwei Stunden lang nicht funktionieren sollte, würde ich das immer noch eher in Kauf nehmen, als jeden Nutzer bei funktionierender Anwendung auszubremsen.

            gruß,
            wahsaga

            --
            /voodoo.css:
            #GeorgeWBush { position:absolute; bottom:-6ft; }
            Beitrag melden
            –
            Informationen zu den Bewertungsregeln