Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

repair table Anzahl der betroffenen Sätze

5 views
Skip to first unread message

Christian Schröder

unread,
Feb 10, 2009, 8:34:22 AM2/10/09
to
Hallo!

Eine mysql Tabelle war beschädigt.
Ich habe zuert den check gemacht, dann einen "repair table" angestoßen
und danach war die Tabelle soweit repariert.

Repair gab drei Infos aus und eine Warning.
Sehe ich das richtig:
Drei Probleme wurden behoben aber es wurden 123 Sätze gelöscht?
Wobei "changed" und "deleted" doch was unterschiedliches sein sollten?

mysql> check table credits;
| crds | check | error | Wrong bytesec: 0-0-0 at linkstart: 119022752
|
| crds | check | error | Corrupt

2 rows in set (16.19 sec)

mysql> repair table credits;
| crds | repair | info | Wrong bytesec: 0- 0- 0 at 119022752;
Skipped |

| crds | repair | info | Wrong bytesec: 52-104-203 at 119022812;
Skipped |

| crds | repair | info | Wrong bytesec: 116-105-111 at 119070268;
Skipped |

| crds | repair | warning | Number of rows changed from 367585 to
367462 |
| crds | repair | status | OK

5 rows in set (3.48 sec)


mysql> check table credits;

| crds | check | status | OK |

1 row in set (0.96 sec)

Dominik Echterbruch

unread,
Feb 10, 2009, 8:53:17 AM2/10/09
to
Christian Schröder wrote:
>
> Repair gab drei Infos aus und eine Warning.
> Sehe ich das richtig:
> Drei Probleme wurden behoben aber es wurden 123 Sätze gelöscht?
> Wobei "changed" und "deleted" doch was unterschiedliches sein sollten?
[SNIP]

> | crds | repair | warning | Number of rows changed from 367585 to
> 367462 |

Du wirfst hier zwei Dinge durcheinander. Nicht die Anzahl der Datensätze
wurde verändert, sondern der Zähler, der intern immer mitläuft (bzw.
mitlaufen sollte) wurde korrigiert. Irgendwann mal wurden Datensätze
gelöscht, aber der Zähler wurde dabei nicht dekrementiert. Oder der
Zähler ist durch irgendetwas anderes mal kaputt gegangen. Beim Check ist
aufgefallen, dass der Zähler nicht mehr die Realität abbildet und genau
das wurde korrigiert.

Hättest du vor dem REPAIR ein SELECT COUNT(*) FROM credits; ausgeführt,
hättest du als Ergebnis 367585 erhalten (was nicht der Realität
entspricht). Nach dem REPAIR hätte die selbe Abfrage 367462 ergeben (was
der korrekte Wert ist).

Der interne Zähler wird verwendet, um Abfragen, wie die obige zu
beschleunigen. Es muss nichts selektiert und gezählt werden, sondern es
wird einfach der Zähler ausgegeben.

Grüße,
Dominik
--
Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
gingen?
(Autor unbekannt)

Christian Schröder

unread,
Feb 10, 2009, 9:00:22 AM2/10/09
to
Dominik Echterbruch schrieb:

> Christian Schröder wrote:
> >
> > Repair gab drei Infos aus und eine Warning.
> > Sehe ich das richtig:
> > Drei Probleme wurden behoben aber es wurden 123 Sätze gelöscht?
> > Wobei "changed" und "deleted" doch was unterschiedliches sein sollten?
> [SNIP]
> > | crds | repair | warning | Number of rows changed from 367585 to
> > 367462 |
>
> Du wirfst hier zwei Dinge durcheinander. Nicht die Anzahl der Datensätze
> wurde verändert, sondern der Zähler, der intern immer mitläuft (bzw.
> mitlaufen sollte) wurde korrigiert. Irgendwann mal wurden Datensätze
> gelöscht, aber der Zähler wurde dabei nicht dekrementiert. Oder der
> Zähler ist durch irgendetwas anderes mal kaputt gegangen. Beim Check ist
> aufgefallen, dass der Zähler nicht mehr die Realität abbildet und genau
> das wurde korrigiert.

Gut, in diese Richtung hatte ich gehofft, denn wenn 123 Sätze gelöscht
worden wären, hätte ich einigen Aufwand in einen Abgleich stecken
müssen.

Die mysql DB läuft ansonsten schön Stabil, aber nachdem ein User seine
Daten angeblich nicht mehr gefunden hat, bin ich nervös geworden.

> Hättest du vor dem REPAIR ein SELECT COUNT(*) FROM credits; ausgeführt,
> hättest du als Ergebnis 367585 erhalten (was nicht der Realität
> entspricht). Nach dem REPAIR hätte die selbe Abfrage 367462 ergeben (was
> der korrekte Wert ist).
>
> Der interne Zähler wird verwendet, um Abfragen, wie die obige zu
> beschleunigen. Es muss nichts selektiert und gezählt werden, sondern es
> wird einfach der Zähler ausgegeben.

Wunderbar, soweit, sogut!

Vielen DANK!
:)

Hätte ich Meldungen bekommen wenn Datensätze gelöscht worden währen?

Dominik Echterbruch

unread,
Feb 10, 2009, 10:34:20 AM2/10/09
to
Christian Schröder wrote:
>
> Hätte ich Meldungen bekommen wenn Datensätze gelöscht worden währen?

Nein. REPAIR löscht keine Datensätze. Allerdings bist du natürlich nciht
dagegen gefeit, dass bei einem Tabellencrash auch Daten verloren gehen.
Ein regelmäßiges Backup ist ja aber ohnehin Pflicht.

Wenn du ganz sicher gehen willst, vergleiche die Inhalte auf
Vollständigkeit (z.B. anhand des eindeutigen Identifiers). Sind nach dem
REPAIR alle Datensätze vorhanden, die zuvor auch da waren? Beispiel für
einen schnellen Test:

SELECT a.id FROM credits_vor_repair a
LEFT JOIN credits_nach_repair b ON b.id = a.id
WHERE b.id IS NULL;

Den umgekehrten Test kannst du dir vermutlich sparen. Es werden durch
den REPAIR wohl kaum Daten zusätzlich entstanden sein ;)

Christian Schröder

unread,
Feb 10, 2009, 11:49:20 AM2/10/09
to
Dominik Echterbruch schrieb:

> Christian Schröder wrote:
> >
> > Hätte ich Meldungen bekommen wenn Datensätze gelöscht worden währen?
>
> Nein. REPAIR löscht keine Datensätze. Allerdings bist du natürlich nciht
> dagegen gefeit, dass bei einem Tabellencrash auch Daten verloren gehen.
> Ein regelmäßiges Backup ist ja aber ohnehin Pflicht.

Wie jetzt?
Nix gelöscht aber Daten verloren?
OK, dann war die Frage falsch.
Daten können verloren gegangen sein?
--> Ja.



> Wenn du ganz sicher gehen willst, vergleiche die Inhalte auf
> Vollständigkeit (z.B. anhand des eindeutigen Identifiers). Sind nach dem
> REPAIR alle Datensätze vorhanden, die zuvor auch da waren? Beispiel für
> einen schnellen Test:
>
> SELECT a.id FROM credits_vor_repair a
> LEFT JOIN credits_nach_repair b ON b.id = a.id
> WHERE b.id IS NULL;


Habe so gefragt:

SELECT a.id FROM credits_vor_repair a

WHERE a.id NOT IN (SELECT b.id FROM credits_nach_repair b)

Zumindest wird die gleiche Anzahl Sätze gefunden.
;)

Also unter Oracle hätte ich Archive-logs recovern können, hier habe ich
halt leider einen Versatz zwischen den Backups.

Hmmm.

> Den umgekehrten Test kannst du dir vermutlich sparen. Es werden durch
> den REPAIR wohl kaum Daten zusätzlich entstanden sein ;)


höhö..
;)

0 new messages