MySQL Datenbank wurde gecrasht

Thomas_Jung

Erfahrenes Mitglied
Hallo, ich habe vor 3 Monaten folgende Meldung erhalten:
[ERROR] mysqld.exe: Table 'sonstiges' is marked as crashed and should be repaired

Ich habe in phpMyAdmin den Befehl
<option value="repair_tbl">Repariere Tabelle</option>
und
<option value="check_tbl">Überprüfe Tabelle</option>
ausgeführt.
Anschliesend kan die Status Meldung "repair status OK"
und check status OK

Nun fällt mir auf, dass Datensätze aus der Tabelle "sonstiges" verschwinden (sind nicht mehr in der Tabelle vorhanden, warum auch immer).

Code:
CREATE TABLE `sonstiges` (
  `id` int(11) NOT NULL,
  `text1` varchar(255) NOT NULL,
  `text2` varchar(255) NOT NULL,
  `text3` varchar(255) NOT NULL,
  `text4` varchar(255) NOT NULL,
  `text5` varchar(255) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

ALTER TABLE `sonstiges`
  ADD UNIQUE KEY `id` (`id`);
COMMIT;

Die Tabelle enthält über 1.5 Millionen Datensätze. (Deshalb vielleicht nicht so einfach?)

Wie kann ich täglich überprüfen, welche Datensätze nicht mehr vorhanden sind.

Ich weiß momentan nicht wie oder wo ich anfangen kann ein Script zu schreiben, das mir dieses überprüft.

Beispiel:
Die Tabelle 'sonstiges' jeden Tag kopieren und dann mit der Originalen Tabelle die id´s abfragen, ob vorhanden?

Hat jemand Vorschläge?
 
Nun fällt mir auf, dass Datensätze aus der Tabelle "sonstiges" verschwinden (sind nicht mehr in der Tabelle vorhanden, warum auch immer).
Bist du sicher, dass sie weg sind?
Hatte auch schon öfters Daten gelöscht und neue erstellt , und nach den reparieren dachte ich sie sind weg , weil da auch einmal weniger standen. In Wirklichkeit waren sie aber noch da. Falls du weißt, welche Datei genau fehlen soll, dann such mal bei phpadmin direkt danach.

Bei deinen anderen Problemen.
Vielleicht hilft das?
How to find missing data rows using SQL?
 
Wenn du nur wissen willst, welche Sätze im Vergleich zum Vortag "verschwunden" sind:
ungetestet
SQL:
SELECT alt.ID, neu.ID FROM backup As Alt
LEFT JOIN aktuell As neu
ON Alt.ID=Neu.ID
WHERE IsNull(Neu.ID)
Was mich eher überrascht: Wieso hast du MyISAM als engine?
MyISAM – Wikipedia
Vielleicht liegt es daran, dass Sätze "verschwinden"
 
Danke für eure Antworten.

@wAs mich eher überrascht: Wieso hast du MyISAM als engine
Die Tabelle sonstiges ist noch von 2005 :(

@Zvoni
Dein Query funktioniert auch. Danke
Habe es mal so probiert.

Die hinzugekommen, gelöschte Sätze zeige ich mir so an.

SQL:
SELECT id
FROM (
SELECT id FROM sonstiges
UNION ALL
SELECT id FROM sonstiges_copy
)newTable
GROUP BY id
HAVING count(*) = 1
ORDER BY id;

Jetzt möchte ich nur die gelöschten angezeigt bekommen.

HAVING count(*) != 1 oder isNull funktioniert nicht.
 
Wenn schon, dann Having Count(*)>1

btw: Dass die Tabelle aus 2005 ist, hat nix mit der verwendeten Engine zu tun.
Was ist die Version des MySQL-Servers heute?
Sie baut, um einige Erweiterungen ergänzt, auf dem älteren ISAM-System auf und war bis MySQL 5.1 Standard-Storage-Engine. Ab Version 5.5 wurde sie durch InnoDB als Standard-Storage-Engine abgelöst.


EDIT: ähhh..... Quatsch
COUNT(*)=1 sind die "verschwundenen".
Ein IsNull funktioniert natürlich nicht auf ein SELECT mit nur einem Feld (und dann noch ein UNION)
Denk mal nach: Du hast ne ID aus sonstige_copy (=alt) aber nicht in sonstige (=neu) --> "verschwunden"
Ein IsNull=Wahr würde bedeuten, du suchst im SELECT nach den ID's welche nicht existieren.
Das funtioniert nicht in einem UNION (und schon zweimal nicht in einem SELECT auf nur ein Feld)
Ein IsNull funktioniert erst, wenn du min. ein zweites Feld hast, wobei es egal ist, ob die aus der gleichen Tabelle kommen (das/die Feld(er) dürfen natürlich nicht als NOT NULL definiert sein) oder aus einem LEFT JOIN (nicht INNER JOIN!!)

Ein LEFT JOIN liefert immer eine NULL für (zweit-) Felder, die keinen korrespondierenden Eintrag in der Master-Tabelle findet
 
Zuletzt bearbeitet:
Ich habe doch geschrieben das dein Query funktioniert :rolleyes:
Vielen Dank dafür.
Ich hatte nur schon etwas geschrieben.

Es ist so weit alles OK


Zum Server
Es läuft noch ein alter Xampp Server. (XAMPP Version: 5.6.15)
PHP Version 5.6.15
Client API version: mysqlnd 5.0.11-dev - 20120503

Ich habe nur ein Export mit mysqldump gemacht.
Muss alles noch auf den neusten Stand bringen.
 
Die XAMPP-Version ist eigentlich uninteressant (und 5.6.15 ist von 2016).
ich glaube das "5.6.15" bezieht sich auf die PHP-Version
Welche Version hat der MySQL-Server da drin (bzw. besser gesagt der MariaDB-Server)?

EDIT: Ah...sehs gerade.....der dump... ok, klar, wenn du ne 5.0-Version des Dump-Tools benutzt ist klar, dass dann MyISAM drin steht
 
Hallo,
ich möchte die Tabelle sonstiges auf einen neuen Server umziehen.
Meine Vorgehensweise wäre.

Ich habe mit die neuste Version von Xampp mit PHP 8.0 heruntergeladen.

Ich erstelle eine neue Datenbank
Code:
CREATE DATABASE IF NOT EXISTS `informationen` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Ich erstelle eine neue Tabelle
Code:
CREATE TABLE `sonstiges` (
  `id` int(11) NOT NULL,
  `text1` varchar(255) NOT NULL,
  `text2` varchar(255) NOT NULL,
  `text3` varchar(255) NOT NULL,
  `text4` varchar(255) NOT NULL,
  `text5` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

ALTER TABLE `sonstiges`
  ADD UNIQUE KEY `id` (`id`);
COMMIT;

Meine Frage ist:
Kann ich die Daten von einer MyISAM Engine in eine InnoDB Engine einspielen oder muss sich erst die Engine von MyISAM in InnoDB umwandeln.

Also wie ihr seht, bin ich der "absolute Fachmann" auf diesem Gebiet :)
 
Ja, kannst du. Die Engine wird nur beim Lesen bzw. schreiben selbst gebraucht (bzw. die Engine legt fest, wie die Daten in der Tabelle selbst organisiert sind.

btw: Wieso machst du zwei Statements? Das hier reicht vollkommen aus.
PRIMARY KEY ist eine Kombination aus NOT NULL und UNIQUE
SQL:
CREATE TABLE `sonstiges` (
  `id` int(11) PRIMARY KEY AUTO_INCREMENT,
  `text1` varchar(255) NOT NULL,
  `text2` varchar(255) NOT NULL,
  `text3` varchar(255) NOT NULL,
  `text4` varchar(255) NOT NULL,
  `text5` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Was den "Umzug" der Daten betrifft: Da es sich bis auf ID alles um Text handelt, würde ich in der "alten" Tabelle einen Export nach CSV machen (an "Quote Text-Data" oder wie das heisst denken), aber definitiv NICHT Komma als Trennzeichen.
Würde eher Semikolon oder Pipe-Symbol nehmen.
Dann einfach in die neue Tabelle importieren. Fertig ist der Lack
 
Hi Zvoni,
vielen Dank für deine Informationen. (y)

Da sich in der Tabelle `sonstiges` viele ÄÖÜ und Sonderzeichen befinden ist da "CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;" für die Datenbank und Tabellen gut geeignet oder sollte ich etwas anderes nehmen.
 
Zurück