Announcement

Collapse
No announcement yet.

Kaputte datenbank die 2te.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kaputte datenbank die 2te.

    ich hab jetzt eine kaputte datenbank, die ich nicht mehr reparieren kann. zum reparieren führe ich folgendes durch.<P>

    gfix -mend -full -ignore -user sysdba -password masterkey db.gdb<br>
    <br>
    Summary of validation errors<br>
    <br>
    Number of record level errors : 3<br>
    Number of index page errors : 1<br>
    Number of database page errors : 1<br>
    <br>
    gbak -b -g -z -v -i -user sysdba -password masterkey db.gdb db.bak<br>
    <br>...
    gbak: writing parameter O_GELIEFERT for stored procedure<br>
    gbak: ERROR: internal gds software consistency check (can't continue after bugcheck)<br>
    gbak: Exiting before completion due to errors<Br>
    gbak: ERROR: internal gds software consistency check (can't continue after bugcheck)<br>
    <br>
    bis jetzt habe ich noch jede datenbank so reparieren können. hat jemand ne idee?

  • #2
    jetzt bin ich sprachlos. ich hab's mal mit der "nicht aufgeben"-taktik probiert und hab das gbak immer wieder gestartet. dabei ist mir aufgefallen, daß der abbruch an verschiedenen stellen passiert. ich hab also den gleichen befehl immer wieder ausgeführt und auf einen schlag ist das backup druchgegangen. und ab dem zeitpunkt hat das backup immer geklappt. ich hab dann den pc neu gestartet und es nochmal versucht, da ging das backup nicht mehr. ich hab's dann wieder ca 10 min. versucht und dann auf einen schlag, ging's wieder. ich bin ja froh, daß ich sie reparieren konnte, aber verstehen kann ich's nicht

    Comment


    • #3
      Hallo,

      wenn es sich nicht um die InterBase-Version 5.6 handeln würde, sieht das nach dem Sweep-Bug der 5.5 aus. Bei einem Backup sichert der InterBase nur die letzte gültige Datensatzversion - d.h. beim Backup wird die Tabelle durchscannt und Satz für Satz gelesen. Dabei "räumt" der InterBase alle unnötigen Backversions der Datensätze ab. Daher ist es plausibel, das nach jedem Backup-Durchlauf der Fehler später kommt. Allerdings ist jede Fehlermeldung beim Backup ein Alarmzeichen - auf diese Datenbank würde ich mich nicht mehr verlassen.

      Steht eventuell zum Test eine andere Festplatte/Partition für die GDB zur Verfügung

      Comment


      • #4
        es handelt sich aber um die 5.6 version... könnte das legen auf eine andere partition etwas helfen

        Comment


        • #5
          <i>gbak -b -g -z -v -i -user sysdba -password masterkey db.gdb db.bak</i>

          Will jetzt nicht die Parameter überpüfen. Was garbage collection <b>deaktiviert</b>. Das hilft meistens bei Problem datenbanken

          Comment


          • #6
            Hallo Volkmar,

            die andere Partition soll nur Festplattenprobleme als Ursache ausschliessen.

            P.S: Das dauerhafte deaktivieren von Garbage Collection erzeugt in näherer Zukunft vermutlich ein noch grösseres Problem ;-

            Comment


            • #7
              Hallo Andreas,

              da hast Du mich falsch verstanden. Nur bei einer Datensicherung, die eine kaputte DB retten soll, auf die Garbage Collection verzichten. Dann wird *alles* gesichert.

              Die Rücksicherung sorgt dann quasi für die Reperatur. Funktioniert bei uns in *Notfällen* hervorragend.

              Andrea

              Comment


              • #8
                Hallo Andreas,

                ja - in diesem Punkt stimme ich Dir vollständig zu

                Comment


                • #9
                  ich hab mittlerweile rausgefunden, daß wenn ich das<p>
                  gfix -shut -force 0 -user sysdba -password masterkey Datenbank<P>
                  aufrufe, dann funktioniert das reparieren auf anhieb

                  Comment

                  Working...
                  X