Re: SQL, transactions et isolation

Marc Cousin a écrit :
> Le Wednesday 10 December 2008 22:24:18 Dimitri Fontaine, vous avez écrit :
>> Bonsoir,
>>
>> Le 10 déc. 08 à 18:21, Marc Cousin a écrit :
>>> * Oracle ne fait pas le MVCC via ses redo logs mais ses segments
>>> d'undo (ou de
>>> rollback jusqu'à la 8i), qui stockent les images avant modification
>>> des
>>> blocks
>> Ah merci de la précision. Il me semblait avoir retenu que ça mettait à
>> part les anciennes versions de tuples, mais je confondais les redo
>> logs (== WALs?) et les rollback segment. C'est là qu'on voit que je
>> n'ai jamais joué avec Oracle j'imagine ;)
>
> redo logs = wals, c'est exactement pareil
>
> le système d'undo stocke les anciennes versions des enregistrements, pour
> pouvoir faire les rollback et ce qu'oracle appelle la lecture consistante,
> c'est à dire ce qu'on a appelé les snapshots à l'instant.
>

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.

> 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 :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com