Re: SQL, transactions et isolation

From: Marc Cousin <mcousin(at)sigma(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: SQL, transactions et isolation
Date: 2008-12-11 10:17:53
Message-ID: 200812111117.53226.mcousin@sigma.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale


> Hmmm, donc c'est pas utilisé exactement pareil. PostgreSQL ne lit jamais
> les journaux de transactions en temps normal. En cas de crash machine ou
> de restauration (log shipping), il les lira. C'est le seul moment où il
> le fait.

Attention, undo, pas redo ... l'undo, c'est l'endroit ou le moteur stocke
l'image avant modification de l'enregistrement. la redo, c'est l'endroit ou
il stock la nouvelle valeur.

Les redo logs d'oracle ne sont lus qu'en cas de reprise après crash. Ou
d'archivage des redo ... bref, comme postgres :)

D'ailleurs, l'undo est aussi journalisé par les redo, les concepts sont
orthogonaux (l'un assure l'atomicité et une partie de l'isolation, l'autre la
durabilité d'acid)

>
> > L'avantage du mécanisme d'oracle, c'est qu'il n'y a pas de vacuum.
>
> Un gros avantage :)
>
> > Le défaut, c'est qu'il est beaucoup plus lourd à mettre en place, que
> > dans certains cas on peut avoir contention sur l'undo (plusieurs
> > processus doivent pouvoir faire des transactions en même temps, donc il y
> > a plusieurs undo en même temps dans le même tablespace, ce qui fait que
> > chacun a une taille limitée, etc ...). Les conséquences c'est
> > - que l'undo peut ne pas être assez gros, ce qui fait que le moteur va
> > dire : vous avez fait trop de modifs, l'undo est plein, je rollback tout,
> > merci d'avoir joué,
> > - que l'undo ne reste en place de façon garantie que pour la durée d'une
> > transaction. Si une seconde transaction plus longue a lieu en cours, les
> > consistent gets ne sont pas garantis. Il est alors tout à fait possible
> > de vouloir lire un enregistrement qui a été modifié par une transaction
> > depuis le début de la notre (on fait un select géant, ou bien on a une
> > transaction en serializable) qui aura été modifié, et donc l'ancienne
> > version n'est plus dans l'undo, le morceau le contenant ayant été
> > recyclé. On a alors la 'fameuse' erreur 'snapshot too old'. C'est aussi
> > la raison pour laquelle les exports Oracle ne sont par défaut pas
> > 'consistent' (c'est à dire que chaque select sur chaque table de l'export
> > n'est pas fait avec le même snapshot), ce que pas mal de DBA Oracle
> > ignorent (ça peut alors être la fête sur certaines restaurations, en
> > raison des contraintes d'intégrité).
> >
> > A la place de tous ces ennuis, on a les vacuum sous postgresql. Je
> > choisis sans hésiter :)
>
> Euh... je suis sans voix. J'ignorais tout ça. Je choisis moi-aussi sans
> hésiter et je pense ne pas me tromper en disant qu'on a choisi le même
> moteur :)

Ouais, vive Oracle. Euh, non finalement :)

Enfin bon, il faut mitiger aussi : Oracle est quand même très bon. Très cher,
mais il fonctionne vraiment bien une fois bien réglé. Pas de quoi se
complexer quand on utilise PostgreSQL, mais des moteurs proprios, c'est de
loin ce qui se fait de mieux à mon avis.

Les quelques défauts que j'ai mentionné au dessus (j'en ai omis, c'était les
plus gros) peuvent, comme les problèmes de vacuum de postgresql, être mitigés
par une bonne administration. Il faut juste comprendre que les choix
d'implémentation sont différents, pour atteindre le même objectif, ce qui
fait qu'on ne paye pas les pénalités au même endroit. Le gros point fort, à
mon avis, de la méthode postgresql, est justement que la pénalité n'est pas
payée par le backend qui fait la transaction, mais par vacuum, de façon
asynchrone.

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message REISS Thomas DSIC BIP 2008-12-11 12:50:37 Re: SQL, transactions et isolation
Previous Message Guillaume Lelarge 2008-12-11 09:28:23 Re: SQL, transactions et isolation