Update von Datensätzen werden rückgängig gemacht

MySQL, PostgreSQL, SQLite
guidokamm
Posts: 5
Joined: 2009-06-11 23:26

Update von Datensätzen werden rückgängig gemacht

Post by guidokamm » 2009-06-11 23:34

Habe seit Kurzem ein merkwürdiges Phänomen (MySQL 5.026 auf Rootserver mit Plesk 9.2):

1) Datensatz wird via PHP-Script eingefügt -> Datensatz ist in MySql-Tabelle vorhanden
2) Datensatz wird später via PHP geändert -> Datensatz ist auch in der MySQL-Tabelle geändert

und nun nach einer kurzen Zeit:

Die Änderung aus Schritt 2 ist plötzlich weg und der Datensatz wieder im Status nach dem Neuanlegen. Der Fehler passiert immer wieder. Bei einer Fülle von Änderungen bleiben jedoch auch manche Änderungen so wie gewollt.

Am Ende also Chaos und Schiefstände in der Datenbank ....

Dachte es läge an den mx_connections. Aber die Ursache kann ich einfach nicht finden. Hat jemand eine Idee, was das sein könnte?

Danke für Eure Ideen
Guido

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: Update von Datensätzen werden rückgängig gemacht

Post by Roger Wilco » 2009-06-11 23:39

Öffnest du in deinem PHP-Skript vielleicht eine Transaktion, die im ersten Fall erfolgreich abgeschlossen wird (COMMIT) und im zweiten Fall nach einem Timeout zurückgerollt (ROLLBACK) wird?

guidokamm
Posts: 5
Joined: 2009-06-11 23:26

Re: Update von Datensätzen werden rückgängig gemacht

Post by guidokamm » 2009-06-12 09:54

Es handelt sich um InnoDB Tabellen. Wie kann ich den Rollback abschalten oder beim Update-Befehl vielleicht Parameter mitgeben, damit der Rollback nicht durchgeführt wird?

User avatar
isotopp
Posts: 471
Joined: 2003-08-21 10:21
Location: Berlin

Re: Update von Datensätzen werden rückgängig gemacht

Post by isotopp » 2009-06-17 07:41

guidokamm wrote:Die Änderung aus Schritt 2 ist plötzlich weg und der Datensatz wieder im Status nach dem Neuanlegen. Der Fehler passiert immer wieder. Bei einer Fülle von Änderungen bleiben jedoch auch manche Änderungen so wie gewollt.


http://dev.mysql.com/doc/refman/5.0/en/commit.html

Wenn Du autocommit einschaltest (das ist es per Default), dann wird jede Änderung sofort in die Datenbank und auf die Platte geschrieben. Das ist sehr langsam.

Wenn Du stattdessen Deine Transaktionen mit einem COMMIT Kommando abschließt, werden Deine Änderungen zu Gruppen zusammengefaßt und beim COMMIT gesammelt auf die Platte geschrieben. Das ist schneller, weil weniger häufig auf die Platte zugegriffen werden muß.

Normalerweise beläßt man sein System im Defaultzustand autocommit und arbeitet mit ausdrücklich definierten Transaktionsblöcken:

Code: Select all

BEGIN;
INSERT INTO ...
UPDATE ...
DELETE FROM ...
COMMIT;


Mehr Informationen zu InnoDB findest Du zum Beispiel hier:
http://blog.koehntopp.de/archives/1985- ... ngine.html
http://blog.koehntopp.de/archives/1997- ... ation.html
http://blog.koehntopp.de/archives/2176- ... ngine.html

Bei konkurrenten Zugriffen auf eine Tabelle ist InnoDB trotz der Mehrarbeit, die MVCC mit sich bringt dennoch schneller als MyISAM. In jedem Fall ist die Datensicherheit und Recovery bei InnoDB weitaus besser als bei MyISAM.

guidokamm
Posts: 5
Joined: 2009-06-11 23:26

Re: Update von Datensätzen werden rückgängig gemacht

Post by guidokamm » 2009-06-22 23:16

Ich nutze einen Rootie mit Plesk-Admin 9.2 und den Default-MySQL-Einstellungen. Bis dato hatte ich mit der Maschine seit mehr als 400 Tagen keinerlei Probs.
Um das Thema "InnoDb" etc. habe ich mir bis dato keinen Kopf gemacht.

Wie kann ich mich von InnoDb verabschieden?

Danke schon vorab und sorry für die späte Antwort (war mal kurz im Urlaub)
Guido

guidokamm
Posts: 5
Joined: 2009-06-11 23:26

Re: Update von Datensätzen werden rückgängig gemacht

Post by guidokamm » 2009-06-22 23:35

Stop: Die Tabellen sind alle vom Typ "MyISAM".

Hier MySQL-Laufzeitinfos nach 10 Tagen (nur überhöhte=rote Werte):

49 Mio db-Abfragen, davon 78% Updates

Innodb_buffer_pool_reads 5.651
Anzahl an Lesevorgängen die InnoDB nicht aus dem Zwischenspeicher bedienen konnte und deshalb einen Einzel-Seiten-Lesevorgang starten musste.

Created_tmp_disk_tables 22 k
Anzahl der (implizit) auf der Platte erzeugten temporären Tabellen bei der Ausführung von Statements. Wenn Created_tmp_disk_tables hoch ist, sollten Sie eventuell die Variable tmp_table_size herauf setzen, damit temporäre Tabellen im Speicher erzeugt werden statt auf der Festplatte.

Table_locks_waited 10 M
Wie oft eine Tabellensperre nicht sofort erlangt werden konnte und gewartet werden musste. Wenn dieser Wert hoch ist und Sie Performance-Probleme haben, sollten Sie zunächst Ihre Anfragen optimieren und dann entweder Ihre Tabelle(n) zerteilen oder Replikation benutzen.

Handler_read_rnd 13 M
Anzahl der Anfragen, eine Zeile basierend auf einer festen Position zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Anfragen ausführen, die erfordern, dass das Ergebnis sortiert wird. Wenn Handler_read_rnd hoch ist, haben Sie wahrscheinlich viele Anfragen, die MySQL zwingen, ganze Tabellen zu scannen, oder Sie haben Joins, die Schlüssel nicht richtig benutzen.

Opened_tables 78 k
Anzahl der Tabellen, die geöffnet wurden. Wenn Opened_tables hoch ist, ist Ihre table_cache-Variable wahrscheinlich zu niedrig.