Wie kann ich auslesen wieviel speicher eine Zeile belegt?

[onemorenerd]

Dieses Zitat liefert zwar eine Erklärung für deine Beobachtung, aber keine Lösung.
Jetzt wissen wir, dass die NDBCluster-Engine die Daten ab dem 257. Byte in eine versteckte Tabelle kippt. Aber sie muss beim Zugriff auf die Haupttabelle die Daten wieder zusammensetzen. Das macht sie bei dir scheinbar nicht und mir fällt noch nichts ein, wie man diesem Fehler beikommen kann.

Du hast offenbar ein Ticket dazu erstellt. Warten wir einfach ab, was die Profis dazu sagen.

[AmicaNoctis]

Hilft es, wenn man vor dem ALTER TABLE einen Daten-Dump zieht und den nachher wieder drüberspielt? Meine Vermutung geht dahin, dass beim ALTER TABLE die Beziehung zwischen der Haupt- und der Zusatztabelle verloren geht und daher die Daten abgeschnitten werden.

[Lennynero]

Hilft es, wenn man vor dem ALTER TABLE einen Daten-Dump zieht und den nachher wieder drüberspielt? Meine Vermutung geht dahin, dass beim ALTER TABLE die Beziehung zwischen der Haupt- und der Zusatztabelle verloren geht und daher die Daten abgeschnitten werden.

Ja, zumindest würde es das verhalten erklären... zumindest zum Teil. Das nicht alle Zeilen betroffen sind.... hinterlässt halt irgendwie eine Erklärungslücke (ich hatte auch die Daten schon verglichen, in der Hoffnung das es vielleicht auch etwas mit dem Änderungsdatum zu tun haben könnte, aber auch da ist die Mischung "betroffener" "nicht betroffener" Zeilen kunterbunt.

Wenn ich die Daten vor dem ALTER dumpe und danach in eine (korrupte) Tabelle zurückspiele, stimmen die Werte übrigens.

Von da aus wird wohl wirklich "einfach" ein Teil der Zuordnung zwischen der versteckten und der eigentlichen Tabelle zerstört. Kann es sein das ggf. sogar mehrere versteckte Tabellen angelegt werden?

[onemorenerd]

Schon mal ein SHOW TABLES gemacht? Tauchen da Tabellen mit dem Präfix #sql oder #.sql auf?

[Lennynero]

Nein, keine #sql oder #.sql oder vergleichebare Sachen.

Auch in den Information Schemata finde ich keine Hinweise.

[Lennynero]

Hallo Miteinander,

hier ein kurzes Update: nach einem kurezn hin- und her mit dem Support von Navicat (denn nach einer Weile testen stellte sich heraus, dass der Fehler nur dort auftrat) und dem einschalten des Logging war mir aufgefallen, das Navicat (wenn man das Queryfenster nutzt) mit jeder Query auch ein "SET PROFILING=1" abfeuerte (nutzt man die Konsole oder den Tabelleneditor ist das nicht der Fall!).

Eine Kombinierte Abfrage auf der Shell ("SET PROFILING=1; ALTER .....") führte dann auch zum gleichen Ergebnis: die Daten wurden zerrissen.

Die Bugmeldung bei MySQL hat mittlerweile auch den Status "verified".

Für uns hier ist die Lösung erstmal das deaktivieren des "SHOW PROFILING" innerhalb von Navicat, in der Hoffnung, dass der Bug auch irgendwann behoben werden kann.


Danke nochmal für die Tipps!

Gruss,
Lenny