[MYSQL] Query-Size ... killed in Action?!

[SteelWheel]

Hallo JS-Welt'ler,

auf die Gefahr hin, dass ich wieder 'nen Schlag ins Wasser produziere, ich muss dennoch fragen: Mir sind umfangreiche INSERTS verloren gegangen - und ich suche derzeit nach einem Grund.

Der längste Query hat 6.480 Zeichen (gemessen via strlen() in PHP). Gem. SHOW VARIABLES LIKE 'max_allowed_packet'; dürfte er das anstandslos gemacht haben - und eigentlich hat er das auch; zumindest für zirka 90 % der Datensätze (rund 3.000). Dass dies ein "Mutant" ist, ist mir bewusst - aber es ließ sich nicht anders handhaben.

Ich habe nirgends eine Meldung hierzu, kein Log o. ä. - hat sich alles totgeschwiegen und der Befehl für diesen "Umzug" lief lokal problemlos und online gab es gar keine Rückmeldung (trotz Config dazu).

Wie wahrscheinlich ist es, dass er mir hier Datensätze ins Nirvana geschickt hat? Ich hätte da mind. einen Log-Eintrag erwartet ... *Axt, verdammte*

Habt Dank!

 

[SteelWheel]

Tjoar, ich hab es mittlerweile als "X-Akte" deklariert - weitere Merkwürdigkeiten sind aufgetreten bei der Aktion rund um ein Datenfeld des Typs "bigint()" (beliebig modifiziert worden; nein, hat kein zerofill-Attribut). Der Korrekturlauf für "bigint" (UPDATE; 32.400 DS per LIMIT 1) ging binnen Sekunden störfrei (da auch deutlich kürzer).

Meine Silvesterparty ist gecancelt - Projekt hat Priorität. Kommt gut rein ... bis nächstes Jahr.

 

[mikdoe]

Armer Steel. Leider hab ich davon 0 Ahnung, sonst würde ich - wenn ich denn könnte - deine Party retten!

Komm auch gut rein!

 

[rico2009]

Mich würde jetzt als erstes mal folgendes interessieren: Warum hast du so viele Insert-Statements und kannst du diese eventuell in kleinere Teile aufteilen? Ich meine, vielleicht bringt es was, wenn man anstatt 3000 DS, immer nur 500 einspielt, kurz wartet und dann die nächsten einspielt. Dann ist auch die Gefahr von Datenverlust kleiner.

Ich würde dich nochmal um eine genauere Fehlerbeschreibung bitten. So ganz blick ich durch dein Problem noch nicht durch.


P.S.: Ich hoffe du konntest wenigstens um 0:00 Uhr bisschen feiern.

 

[SteelWheel]

Nein, er hat nicht gefeiert - er stand zirka 15 Minuten auf dem Balkon zwecks Betrachtung buchstäblich in die Luft gejagter Gelder, danach ging es weiter. Dennoch: Frohes Neues!

Die Datenpumpe von Tbl A nach Tbl B stellt kein Problem mehr dar. Die Aktion ist ja gelaufen, wird so nie wieder benötigt und noch weniger so passieren. Nur habe ich jetzt "Folgeerscheinungen". Mein neuer (und letzter) Liebling: bigint() ... denn was ich oben zu diesem Datentyp erzählte, trat jetzt nach Korrektur (!) genau so wieder (!) auf. Der Clou: Meinerseits läuft ein "Optimize" in der Nacht und ausnahmslos SELECTs auf das Feld - nur an einer einzigen Stelle wird aktualisiert; das ist limitiert auf Datenbank, Primärkey und Sekundärkey.

Ich habe mir gestern nochmals alle Stellen (Scripte) geben/zeigen lassen, die diese Spalte anfassen - ein einziger Update'r, der Rest Selects! Warum wird ein Feld vom Datentyp bigint() mit einem Eintrag von - bspw. - 23500000 zu 978342? Da ist auch kein Muster erkennbar - der daraus sich ergebende Faktor ist je Row anders: 2.7, 2.3, 2.32, 1.8, ... nun, ich kenne das Verhalten schon von float() - da gab es "plötzlich" Schwankungen (woran das liegt, ist bekannt) und deshalb nehme ich das nicht mehr.

Hack? Weniger ... liegt es an "Optimize"? Ich habe 1x am Tag über meine Datenbank diesen Mini-Job laufen ... ich werde das noch testen, aber genervt bin ich davon durchaus.

Mein Plan für heute sieht vor, dass ich erneut eine Korrektur laufen lassen (ein Hoch auf alte Datenbestände) und dann das Datenfeld auf INT() ändere (hatte gestern Abend auf SO was gefunden, der etwas Ähnliches beschrieb - aber in Verbindung mit einer speziellen Installation im Linux - war irgendwas mit Sub...). Mehr fällt mir nämlich wirklich nicht mehr ein ... und das ist dann auch noch lästig.

Danke euch.

 

[rico2009]

Dennoch: Frohes Neues!

Danke, dir auch Frohes Neues!


Ich glaub nicht, dass es am Optimize liegt. Ich sehe das als ganz merkwürdiges Problem an und wollte dir gestern schon mal Stack Overflow empfehlen. Da bist du ja schon selbst drauf gekommen

Ich hatte aber mal sowas ähnliches. Ich hatte vor ein paar Tagen zum ersten Mal in vielen Jahren PHP Entwicklung einen PHP Speicherfehler. Dieser trat auf, weil ein DB-Feld longtext war und in der php.ini die maximale Speicherauslastung (memory_size) nur auf 20 MB stand. Longtext benötigt aber 4GB, allein das finde ich schon sehr krass, aber egal. Ich habe das DB-Feld auf mediumtext geändert und das Speicherlimit ein wenig erhöht. Dann hat alles geklappt. Könnte es vielleicht sein, dass du auch sowas in der Art mit dem Datentyp bigint hast?

- - - Aktualisiert - - -

Das hast du vermutlich schon gemacht aber, hast du mal in die Logs geschaut (PHP, MySQL, Apache)?

 

[SteelWheel]

Grüße Dich erneut,

meine Queries mochten das gesetzte memory_limit auch nicht - nöhlte gleich beim 1. Query rum (es fehlten 54 byte - lach!); mit ini_set ließ er sich temporär bändigen. Späße mit floats (Typ; nicht Funktion) sprach ich an - geht aber auch mit unicode im Typ "Text" (und wie ätzend Double-Quotes im Serialized werden). Aber, alles gelöst ... und auch dieser Fall!

Du hast es treffend in der Signatur stehen: "Der PC rechnet mit allem, nur nicht mit seinem Besitzer!" ... Auslöser ist hier der Depp an der Tastatur - denn der hat bei seinen vielfachen Modultests an einer Stelle - für einen Test - was geändert; und das nicht zurückgesetzt. Die Folge: Berechnungen erwähnter Natur. Um es mal aufzuzeigen: Ein = statt einem <> ... es ist die echte Pest! Darum steht auch in Logfiles nix (an die von PHP etc. komme ich nicht ran, da "managed", weshalb meine Automationen und meine Scripte eigene Logfiles schicken bzw. schreiben), denn der Query läuft ja ... nimmt nur die ganz falschen Daten und modifiziert diese zum Erstaunen des Betreibers.

Ja ja ... wie ich immer sage: Der Computer löst Probleme, die ich vorher nicht hatte!

Es ist also nicht bigint - es ist Script in der Folge gewesen. Und dass die Datenbank deutlich überfrachtet war, konnte ich nachrechnen ... ^^

Fazit: Wird so nicht mehr passieren - und so nicht mehr benutzt.

Ich danke Dir dennoch.

 

[rico2009]

Naja, Hauptsache nun klappt es. Oftmals hilft es halt schon über das Problem zu sprechen.