Re: SQL, transactions et isolation

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.

L'avantage du mécanisme d'oracle, c'est qu'il n'y a pas de vacuum.

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