Stromausfall führt zu Schäden bei Pokertracker HILFE!!

    • pokersellers
      pokersellers
      Black
      Dabei seit: 19.12.2005 Beiträge: 475
      Hallo Freunde,

      ich war eben munter am spielen, bis ein Stromausfall meinen Laptop (dummerweise war der Akku nicht drin) lahmlegte.
      Als ich wieder neu gestartet hatte und Pokertracker starten wollte, kommt die folgende Fehlermeldung:

      Unable to connect to the database

      210-SQLSTATE= 28000
      FATAL: the database system is starting up


      Wenn ich versuche, die ring game statistics zu öffnen, spinnt das Teil richtig rum und es öffnen sich zig pop-ups.

      Leider hab ich lange Zeit kein Backup mehr gemacht.... :(

      Hat jemand ne Idee, wie oder ob meine Datenbank noch zu retten ist?

      Vielen Dank,

      pokersellers
  • 3 Antworten
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Du kannst versuchen die Transaktionlogs zurücksetzen (Vorher "data" Verzeichnis backupen!!). Das Tool mit dem du das machen kannst nennt sich "pg_resetxlog". Es müsste in deinem PostgreSQL Installationsordner rumfliegen und kann aus einer Kommandozeile raus verwendet werden.

      Manpage pg_resetxlog:
      pg_resetxlog clears the write-ahead log (WAL) and optionally resets some other control information (stored in the pg_control file). This function is sometimes needed if these files have become corrupted. It should be used only as a last resort, when the server will not start due to such corruption.
      Gruss,
      Alex
    • pokersellers
      pokersellers
      Black
      Dabei seit: 19.12.2005 Beiträge: 475
      Ich hab jetzt die besagte exe-Datei ausgeführt.
      Es kam ganz kurz nen kleines Dos-Fenster.

      Die Fehlermeldung ist aber immer noch da!

      Gibt es evtl noch andere Möglichkeiten?
      Es wäre wirklich sehr sehr schade, wenn die ganzen Stats weg wären....
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von pokersellers
      Ich hab jetzt die besagte exe-Datei ausgeführt.
      Es kam ganz kurz nen kleines Dos-Fenster.
      So funktioniert das auch nicht. Da ist schon ein wenig mehr Handarbeit nötig. Einfach draufklicken ist nicht. Du musst eine DOS-Box öffnen und dort das Kommando mit den richtigen Parametern eingeben.

      Hier das "Handbuch" des Befehls:


      pg_resetxlog - reset the write-ahead log and other control information of a PostgreSQL database cluster

      SYNOPSIS
      pg_resetxlog [ -f ] [ -n ] [ -o oid ] [ -x xid ] [ -l timelineid,fileid,seg ] datadir

      DESCRIPTION
      pg_resetxlog clears the write-ahead log (WAL) and optionally resets some other control information (stored
      in the pg_control file). This function is sometimes needed if these files have become corrupted. It should
      be used only as a last resort, when the server will not start due to such corruption.

      After running this command, it should be possible to start the server, but bear in mind that the database
      may contain inconsistent data due to partially-committed transactions. You should immediately dump your
      data, run initdb, and reload. After reload, check for inconsistencies and repair as needed.

      This utility can only be run by the user who installed the server, because it requires read/write access to
      the data directory. For safety reasons, you must specify the data directory on the command line.
      pg_resetxlog does not use the environment variable PGDATA.

      If pg_resetxlog complains that it cannot determine valid data for pg_control, you can force it to proceed
      anyway by specifying the -f (force) switch. In this case plausible values will be substituted for the miss-
      ing data. Most of the fields can be expected to match, but manual assistance may be needed for the next
      OID, next transaction ID, WAL starting address, and database locale fields. The first three of these can
      be set using the switches discussed below. pg_resetxlog's own environment is the source for its guess at
      the locale fields; take care that LANG and so forth match the environment that initdb was run in. If you
      are not able to determine correct values for all these fields, -f can still be used, but the recovered
      database must be treated with even more suspicion than usual: an immediate dump and reload is imperative.
      Do not execute any data-modifying operations in the database before you dump; as any such action is likely
      to make the corruption worse.

      The -o, -x, and -l switches allow the next OID, next transaction ID, and WAL starting address values to be
      set manually. These are only needed when pg_resetxlog is unable to determine appropriate values by reading
      pg_control. A safe value for the next transaction ID may be determined by looking for the numerically
      largest file name in the directory pg_clog under the data directory, adding one, and then multiplying by
      1048576. Note that the file names are in hexadecimal. It is usually easiest to specify the switch value in
      hexadecimal too. For example, if 0011 is the largest entry in pg_clog, -x 0x1200000 will work (five trail-
      ing zeroes provide the proper multiplier). The WAL starting address should be larger than any file name
      currently existing in the directory pg_xlog under the data directory. These names are also in hexadecimal
      and have three parts. The first part is the ``timeline ID'' and should usually be kept the same. Do not
      choose a value larger than 255 (0xFF) for the third part; instead increment the second part and reset the
      third part to 0. For example, if 00000001000000320000004A is the largest entry in pg_xlog, -l
      0x1,0x32,0x4B will work; but if the largest entry is 000000010000003A000000FF, choose -l 0x1,0x3B,0x0 or
      more. There is no comparably easy way to determine a next OID that's beyond the largest one in the data-
      base, but fortunately it is not critical to get the next-OID setting right.

      The -n (no operation) switch instructs pg_resetxlog to print the values reconstructed from pg_control and
      then exit without modifying anything. This is mainly a debugging tool, but may be useful as a sanity check
      before allowing pg_resetxlog to proceed for real.

      NOTES
      This command must not be used when the server is running. pg_resetxlog will refuse to start up if it finds
      a server lock file in the data directory. If the server crashed then a lock file may have been left behind;
      in that case you can remove the lock file to allow pg_resetxlog to run. But before you do so, make doubly
      certain that there is no postmaster nor any backend server process still alive.
      Im Klartext heisst das also:

      1. Backup von c:\Programme\PostgreSQL\data machen
      2. In der DOS-Box eingeben: pg_resetxlog c:\Programme\PostgreSQL\data

      Der Pfad c:\Programme\PostgreSQL\data kann natürlich bei dir ein anderer sein.

      Gruss,
      Alex