lang laufende Transaktionen

Hi,

wie kann man einem Kunden erklären, daß es keine sonderlich gute Idee
ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und da
massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...

Argh!


Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

1. Das heisst, die datenbank waechst, weil die alten versionen von
records nicht entfernen kann. A.Das ist schlecht fuer die leistung B.
und kostet platz auf der platte. (aber, wenn man das oefters macht und
kein vacuum full dazwischen (und wohl vacuum analyze), haelt es sich
eigentlich in grenzen).
2. Man kann nicht ueber die updates verfuegen ausserhalb dieser session
3. wenn die transaction irgendwann fehlschlaegt, ist alles weg

Gibt es noch andere effekte?
Locking wahrscheinich?

WBL

On Thu, Jul 14, 2011 at 7:54 PM, Andreas Kretschmer
wrote:
> Hi,
>
> wie kann man einem Kunden erklären, daß es keine sonderlich gute Idee
> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und da
> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...
>
> Argh!
>
>
> Andreas
> --
> Really, I'm not out to destroy Microsoft. That will just be a completely
> unintentional side effect. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0(Linus Torvalds)
> "If I was god, I would recompile penguin with --enable-fly." =A0 (unknown)
> Kaufbach, Saxony, Germany, Europe. =A0 =A0 =A0 =A0 =A0 =A0 =A0N 51.05082=
°, E 13.56889°
>
> --
> Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-de-allgemein
>



--=20
"Patriotism is the conviction that your country is superior to all
others because you were born in it." -- George Bernard Shaw

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

Hi,

na versuchs doch mit Datenverlust. Wenn die Verbindung Anwendung-DB=20
abbrichts oder Serverausfall oder ... dann gibts nen Rollback und alle=20
Daten sind weg.

Gruss
Thomas


Am 14.07.2011 19:54, schrieb Andreas Kretschmer:
> Hi,
>
> wie kann man einem Kunden erklären, daß es keine sonderlich gute Id=
ee
> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und d=
a
> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...
>
> Argh!
>
>
> Andreas


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

> wie kann man einem Kunden erklären, daß es keine sonderlich gute Idee
> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und da
> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...

Die richtige Frage wäre: Wieso will der Kunde das?
Was ist sein eigentliches Problem, das er hofft, mit dieser Schnapsidee
in den Griff kriegen zu können?

Die offensichtlichen technischen Probleme (VACUUM kann nicht laufen,
bei Client- oder Netzwerkproblemen ist alles weg) wurden schon erwähnt.

Offensichtlich kann auf die betreffenden Daten niemand außer die
Dauertransaktion schreibend zugreifen, also muß es sich um ein
"einer (und immer der gleiche) schreibt, viele lesen"-Szenario handeln.

Und offenbar dauert es Wochen, bis die geschriebenen Daten (wieder)
konsistent sind.

Wenn das wirklich so ist (und ein anderes Szenario kann ich mir nicht
vorstellen), warum nicht so:

Am Anfang des wochenlangen Update-Prozesses:

CREATE TABLE data_copy AS (SELECT * FROM data);
-- notwendige Indizes und Constraints anlegen

oder

CREATE TABLE data_copy (LIKE data INCLUDING ALL);
INSERT INTO data_copy SELECT * FROM data;

Dann soll der Schreiber von mir aus monatelang auf der Tabelle herumfummeln.
Wenn er fertig ist:

START TRANSACTION;
DROP TABLE data;
ALTER TABLE data_copy RENAME TO data;
COMMIT;

Voil=E0. Dasselbe erreicht, ohne lange Transaktion.

Man muß vielleicht noch ein bißchen Kopfarbeit hineinstecken (z.B. mü=
ßten
auch Fremdschlüssel, die auf "data" zeigen, beachtet werden), aber so sol=
lte
es im Wesentlichen gehen.

Liebe Grüße,
Laurenz

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

* Andreas Kretschmer:

> wie kann man einem Kunden erklären, daß es keine sonderlich gute Idee
> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und da
> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...

Die Anzahl der Anweisungen pro Transaktion ist begrenzt, auf 2*31 oder
2**32. Dann wird die Transaktion zwangsweise abgebrochen.

Große Transaktionen machen auf anderen DBMS noch mehr Probleme, d.h. die
Anwendung ist auf diese Weise nicht portabel, sollte das einmal
notwendig werden.

--=20
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

Am 20.07.2011 15:45, schrieb Florian Weimer:
> * Andreas Kretschmer:
>=20
>> wie kann man einem Kunden erklären, daß es keine sonderlich gute I=
dee
>> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und =
da
>> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...
>=20
> Die Anzahl der Anweisungen pro Transaktion ist begrenzt, auf 2*31 oder
> 2**32. Dann wird die Transaktion zwangsweise abgebrochen.
>=20
> Große Transaktionen machen auf anderen DBMS noch mehr Probleme, d.h. =
die
> Anwendung ist auf diese Weise nicht portabel, sollte das einmal
> notwendig werden.
>=20


Ja, also erst mal Danke an alle. Kunde hat es inzwischen eingesehen.
Momentan überlegen wir noch, wie wir eine Tabelle, die eigentlich nur
knapp 2000 Zeilen enthält, aber wegens massig UPDATES und den besagten
offenen Transaktionen nun ca. 2 GByte groß ist, einem VACUUM FULL
unterziehen, ohne den kontinuierlichen Betrieb zu stören. Aber das wird
wohl nur über ein Wartungsfenster gehen...

--=20
Andreas Kretschmer
http://internet24.de

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: lang laufende Transaktionen

On 20.07.2011 15:54, Andreas Kretschmer wrote:
> Am 20.07.2011 15:45, schrieb Florian Weimer:
>> * Andreas Kretschmer:
>>
>>> wie kann man einem Kunden erklären, daß es keine sonderlich gute =
Idee
>>> ist, Transaktionen über Wochen oder gar Monate laufen zu lassen und=
da
>>> massiv (zumindest dutzende pro Sekunde) Updates zu machen? ...
>>
>> Die Anzahl der Anweisungen pro Transaktion ist begrenzt, auf 2*31 oder
>> 2**32. Dann wird die Transaktion zwangsweise abgebrochen.
>>
>> Große Transaktionen machen auf anderen DBMS noch mehr Probleme, d.h.=
die
>> Anwendung ist auf diese Weise nicht portabel, sollte das einmal
>> notwendig werden.
>>
>
>
> Ja, also erst mal Danke an alle. Kunde hat es inzwischen eingesehen.
> Momentan überlegen wir noch, wie wir eine Tabelle, die eigentlich nur
> knapp 2000 Zeilen enthält, aber wegens massig UPDATES und den besagte=
n
> offenen Transaktionen nun ca. 2 GByte groß ist, einem VACUUM FULL
> unterziehen, ohne den kontinuierlichen Betrieb zu stören. Aber das wi=
rd
> wohl nur über ein Wartungsfenster gehen...

Vielleicht ein Fall für pg_reorg? :-)

http://www.depesz.com/index.php/2011/07/06/bloat-happens/

Gruß,
Patryk

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein