SQL, transactions et isolation

Je vais me permettre de poser une question qui ne concerne pas
réellement PostgreSQL. Car, avec PostgreSQL, tout marche bien mais je
voulais savoir ce qu'il en était d'autres SGBD.

La doc' de PostgreSQL prétend
<http://www.postgresql.org/docs/current/interactive/mvcc.html> et
l'expérience semble confirmer, que chaque transaction voit un
"snapshot" des données et que "reading never blocks writing and
writing never blocks reading".

Avec le niveau d'isolation par défaut, READ COMMITTED, une transaction
"de lecture" voit les commits des autres transactions (et ne peut donc
pas compter sur une vision cohérente des données).

Avec le niveau d'isolation SERIALIZABLE, par contre, une transaction
"de lecture" ne voit absolument pas les commits des autres
transactions (que ce soit pour des INSERT, des DELETE et des
UPDATE). Elle n'est pas bloquée pour autant, elle peut faire des
SELECT tant qu'elle veut et ils se terminent, rendant les données qui
existaient au début de la transaction (ce qui est bien le but des
transactions sérialisables). C'est parfait, c'est juste ce que je
voulais.

Mais ma question est :

Ce comportement de "snapshot" de PostgreSQL est-il imposé par la norme
SQL ? Pas sûr, on peut sans doute être compatible avec la norme en
mettant des simples verrous qui bloquent la transaction de lecture
tant que des écritures sont en cours. Si ce n'est pas standard, quel
SGBD a les mêmes capacités que PostgreSQL ? Tous ? Aucun ?

Bonsoir,

Je n'ai quasiment aucune expérience directe des autres SGBD (uniquement pour
la durée d'une migration, et c'est tant mieux), mais j'ai eu l'occasion de
parler un peu du sujet et voilà ce que j'en ai retenu:

Le mercredi 10 décembre 2008, Stephane Bortzmeyer a écrit :
> <http://www.postgresql.org/docs/current/interactive/mvcc.html> et
[...]
> Ce comportement de "snapshot" de PostgreSQL est-il imposé par la norme
> SQL ? Pas sûr, on peut sans doute être compatible avec la norme en
> mettant des simples verrous qui bloquent la transaction de lecture
> tant que des écritures sont en cours. Si ce n'est pas standard, quel
> SGBD a les mêmes capacités que PostgreSQL ? Tous ? Aucun ?

Le standard impose quatre modes de transactions, et PG n'en supporte que deux,
comme indiqué dans la Table 13-1. SQL Transaction Isolation Levels.

Le fait de ne pas vérouiller est du à MVCC, fait pour résoudre le soucis. Les
concurrents ont tous plus ou moins MVCC, mais avec des implémentation
différentes.

Pour PostgreSQL chaque ligne enregistrée dans la base est "visible" entre son
xmin et son xmax, et chaque ordre SQL doit s'assurer de voir la bonne version
(les transactions aussi ont une notion de xmin et xmax).
Les avantage c'est qu'on peut avoir beaucoup de transaction en parallèle avec
chacune son snapshot, que pg_dump garanti à chaud une vision cohérente de
l'ensemble de la base, les COMMIT et ROLLBACK sont très rapides, etc.
Les inconvénients c'est VACUUM, le bloat, l'absence de covering indexes, etc.
Notons que la version 8.4 va bien améliorer la situation avec la Visibility
Map, et que par la suite (pas en 8.4) on devrait voir les covering indexes
arriver dans PG ;)

http://www.postgresql.org/docs/8.3/interactive/ddl-system-columns.html
http://www.postgresql.org/docs/8.3/interactive/functions-info.html#FUNCTIONS-TXID-SNAPSHOT

C'est là que je vais sûrement raconter n'importe quoi (déjà que pour ce qui
est dit avant c'est mieux de vérifier...) :

MySQL fait du MVCC à base de verrous sur la table en MyISAM, et en InnoDB je
ne sais pas trop. Oracle fait du MVCC à base de redo logs, il ne souffre pas
des soucis vacuum mais le rollback rempli les logs, et il me semble que les
anciennes versions de lignes sont à aller chercher dans les redo logs aussi.
Je sais pas trop.
Le MVCC dans DB2 ressemble à celui de PostgreSQL au niveau des idées, il me
semble avoir compris, quant à Informix et Sybase et MS SQL, je n'en sais
rien. Et Firebird et Ingres, aucune idée non plus.

Bref, pour faire de l'isolation de transactions (requis par ACID, c'est le I)
de manière efficace, il faut implémenter MVCC. D'une manière ou d'une
autre ;)

En espérant que ça aide plus que ça ne rend tout flou,
--
Dimitri Fontaine, DBA PostgreSQL, Architecte

On Wed, 10 Dec 2008 17:36:33 +0100, Dimitri Fontaine
<dfontaine(at)hi-media(dot)com> wrote:
>

Bonjour,

> C'est là que je vais sûrement raconter n'importe quoi (déjà que pour
> ce qui
> est dit avant c'est mieux de vérifier...) :
>
> MySQL fait du MVCC à base de verrous sur la table en MyISAM, et en
InnoDB
> je
> ne sais pas trop.

Nan ! MySQL (paix à son ame !) ne fait rien, ce sont les moteurs de
stockages qui bossent (!!). MyISAM ne fait qu'un seul niveau d'isolation :
dirty read ou read uncommitted, c'est à dire pas d'isolation. Il y a un
mécanisme de verrous, c'est tout. InnoDB (paix à son ame, aussi,
décidement) à un mécanisme MVCC équivalent à PostgreSQL.

> Oracle fait du MVCC à base de redo logs, il ne souffre
> pas
> des soucis vacuum mais le rollback rempli les logs, et il me semble que
> les
> anciennes versions de lignes sont à aller chercher dans les redo logs
> aussi.
> Je sais pas trop.
> Le MVCC dans DB2 ressemble à celui de PostgreSQL au niveau des idées,
il
> me
> semble avoir compris, quant à Informix et Sybase et MS SQL, je n'en sais

> rien. Et Firebird et Ingres, aucune idée non plus.
>

Firebird (Interbase en fait) est le serveur qui a implémenter en premier
MVCC, sauf erreur de ma part.

En gros, les niveaux d'isolations sont décrits dans la norme, mais
l'implémentation reste à la discrétion de l'implémentation, et le fait
est que le concept MVCC est celui qui est le plus utilisé aujourd'hui.

Cordialement,

--
Sébastien Lardière

Le Wednesday 10 December 2008 17:08:26 Stephane Bortzmeyer, vous avez écrit :
> Je vais me permettre de poser une question qui ne concerne pas
> réellement PostgreSQL. Car, avec PostgreSQL, tout marche bien mais je
> voulais savoir ce qu'il en était d'autres SGBD.
>
> La doc' de PostgreSQL prétend
> <http://www.postgresql.org/docs/current/interactive/mvcc.html> et
> l'expérience semble confirmer, que chaque transaction voit un
> "snapshot" des données et que "reading never blocks writing and
> writing never blocks reading".
>
> Avec le niveau d'isolation par défaut, READ COMMITTED, une transaction
> "de lecture" voit les commits des autres transactions (et ne peut donc
> pas compter sur une vision cohérente des données).
>
> Avec le niveau d'isolation SERIALIZABLE, par contre, une transaction
> "de lecture" ne voit absolument pas les commits des autres
> transactions (que ce soit pour des INSERT, des DELETE et des
> UPDATE). Elle n'est pas bloquée pour autant, elle peut faire des
> SELECT tant qu'elle veut et ils se terminent, rendant les données qui
> existaient au début de la transaction (ce qui est bien le but des
> transactions sérialisables). C'est parfait, c'est juste ce que je
> voulais.
>
> Mais ma question est :
>
> Ce comportement de "snapshot" de PostgreSQL est-il imposé par la norme
> SQL ? Pas sûr, on peut sans doute être compatible avec la norme en
> mettant des simples verrous qui bloquent la transaction de lecture
> tant que des écritures sont en cours. Si ce n'est pas standard, quel
> SGBD a les mêmes capacités que PostgreSQL ? Tous ? Aucun ?

En tant que personne ayant souffert avec un certain nombre de moteurs, je peux
répondre à qq questions sur le sujet :)

Déjà pour commencer, une liste assez à jour des moteurs MVCC :
http://en.wikipedia.org/wiki/Multiversion_concurrency_control

(Non, DB2 n'est pas MVCC, comme je l'ai vu dans une des réponses)

* Pour ce qui est des ordres d'implémentation du MVCC entre les moteurs, je ne
sais pas qui a dégainé le premier.

* 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

* SQL Server peut faire du MVCC, mais ce n'est pas par défaut. Il faut
l'activer par base, et c'est plus ou moins déconseillé pour des raisons de
perfs apparemment (j'ai pas d'info précise là dessus)

* InnoDB, BerkeleyDB et le (futur ?) moteur falcon sont MVCC aussi, chacun
avec son implémentation

* Pour ce qui est des moteurs non MVCC (SQL Server par défaut, et toutes les
versions antérieures à 2005), DB2, Progress (je crois), Sybase et quelques
autres, il y a 2 entrées de blogs de msdn qui expliquent assez bien comment
ça marche avec SQL Server. C'est à très peu de choses pareil sur les autres
moteurs non MVCC (au moins DB2 et Sybase...)
http://blogs.msdn.com/craigfr/archive/2007/04/25/read-committed-isolation-level.aspx
et si vous voulez avoir encore plus mal :
http://blogs.msdn.com/craigfr/archive/2007/05/02/query-plans-and-read-committed-isolation-level.aspx
(de l'influence du plan d'exécution sur le résultat d'une requête...)

* Les moteurs MVCC ne sont pas vraiment majoritaires dans les gros SGBD (à
part Oracle et un peu SQL Server maintenant). C'est un des gros points forts
d'Oracle sur la concurrence, et un sujet d'amusement de leurs experts
d'ailleurs quand ils parlent de la concurrence.

* Les snapshots ne sont pas imposés par la norme (comme expliqué dans les
entrées de blog au dessus). Par contre, honnêtement, une appli
transactionnelle est très pénible à développer sans. Dans beaucoup de
développements que j'ai vu sur le sujet, ça se termine soit par l'utilisation
de read uncommitted (ni implémenté par postgresql ni par oracle, et pour
cause, il n'y en a pas besoin), soit par un énorme travail pour éviter que
les écrivains ne bloquent les lecteurs. C'est aussi beaucoup plus facile
d'avoir des deadlocks dans l'appli, vu que les verrous sont plus nombreux...
Le read uncommitted est vraiment beaucoup plus fréquent qu'on ne se l'imagine
chez les utilisateurs moins fortunés de moteurs non MVCC

* Dans les moteurs non MVCC il y a aussi des promotions de verrous et autres
mécanismes pour éviter que les verrous mémoire ne deviennent ingérables : un
update géant sur une table, qui va verrouiller 10 millions d'enregistrements
aurait 10 millions de verrous mémoire sinon. Donc on se retrouve à remplacer
des verrous d'enregistrement par des verrous de blocs a partir d'une certaine
limite, voire carrément des verrous de table ...

Bref, MVCC, c'est une des choses que je mets systématiquement en avant pour
justifier l'utilisation de PostgreSQL ou Oracle pour une appli
transactionnelle... ça coûte un peu en performances, mais ça évite beaucoup
d'ennuis.
Pour un infocentre, c'est moins important par contre.

En espérant avoir à peu près fait le tour de la question ...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> En espérant avoir à peu près fait le tour de la question ...

Merci beaucoup de tes lumières !

- --
Dimitri Fontaine
PostgreSQL DBA, Architecte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAklAM4MACgkQlBXRlnbh1bkBigCgxeS7OWxZosJ4GTKliUVMMih6
wk0AoKRkQ3+Qu2HsmtrT/fqv+9Ycph4V
=sV6j
-----END PGP SIGNATURE-----

Dimitri Fontaine a écrit :
> [...]
> Pour PostgreSQL chaque ligne enregistrée dans la base est "visible" entre son
> xmin et son xmax, et chaque ordre SQL doit s'assurer de voir la bonne version
> (les transactions aussi ont une notion de xmin et xmax).
> Les avantage c'est qu'on peut avoir beaucoup de transaction en parallèle avec
> chacune son snapshot, que pg_dump garanti à chaud une vision cohérente de
> l'ensemble de la base, les COMMIT et ROLLBACK sont très rapides, etc.
> Les inconvénients c'est VACUUM, le bloat, l'absence de covering indexes, etc.

D'accord avec le reste, mais l'absence des covering indexes n'est pas dû
à MVCC, mais plutôt à l'absence des infos xmin/xmax directement dans
l'index.

> Notons que la version 8.4 va bien améliorer la situation avec la Visibility
> Map, et que par la suite (pas en 8.4) on devrait voir les covering indexes
> arriver dans PG ;)
>

Voilà. Mais je tiens à dire qu'on les voit arriver tout en conservant le
système MVCC.

> http://www.postgresql.org/docs/8.3/interactive/ddl-system-columns.html
> http://www.postgresql.org/docs/8.3/interactive/functions-info.html#FUNCTIONS-TXID-SNAPSHOT
>
> C'est là que je vais sûrement raconter n'importe quoi (déjà que pour ce qui
> est dit avant c'est mieux de vérifier...) :
>

Pour ce qui est dit avant, c'est du tout bon. Pour le reste, je ne suis
pas non plus capable de juger, connaissant très peu, voire pas du tout,
le reste du monde des bases de données.

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

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

Le mercredi 10 décembre 2008, Guillaume Lelarge a écrit :
> D'accord avec le reste, mais l'absence des covering indexes n'est pas dû
> à MVCC, mais plutôt à l'absence des infos xmin/xmax directement dans
> l'index.

J'avais compris, jusque là, quecette absence est un choix d'implémentation de
MVCC dans PostgreSQL. Il serait trop lourd d'avoir à maintenir la visibilité
dans les index de la même manière que cela est fait dans les tables. Du coup
pas de covering indexes. C'est pas ça ?

> Voilà. Mais je tiens à dire qu'on les voit arriver tout en conservant le
> système MVCC.

Une fois de plus, merci PostgreSQL. :)
--
Dimitri Fontaine, DBA PostgreSQL, Architecte

Dimitri Fontaine a écrit :
> Le mercredi 10 décembre 2008, Guillaume Lelarge a écrit :
>> D'accord avec le reste, mais l'absence des covering indexes n'est pas dû
>> à MVCC, mais plutôt à l'absence des infos xmin/xmax directement dans
>> l'index.
>
> J'avais compris, jusque là, quecette absence est un choix d'implémentation de
> MVCC dans PostgreSQL.

Exactement la formule que je cherchais hier sans réussir à mettre la
main dessus. C'est exactement ça : un choix d'implémentation.

> Il serait trop lourd d'avoir à maintenir la visibilité
> dans les index de la même manière que cela est fait dans les tables. Du coup
> pas de covering indexes. C'est pas ça ?
>

Yep. Ça pourrait doubler la taille des index (notamment pour les clés
primaires sur des int4 car on devrait stocker deux entiers de plus, xmin
et xmax). Sans compter qu'il faut ensuite les mettre à jour ce qui
mettrait à mal l'index et son côté balancé.

Le visibility map d'Heikki est une manière rusée de contourner le
problème :)

>> Voilà. Mais je tiens à dire qu'on les voit arriver tout en conservant le
>> système MVCC.
>
> Une fois de plus, merci PostgreSQL. :)

Yep, +1.

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

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

> 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.

Le 11/12/2008 08:32, Marc Cousin a écrit :
> 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é).
>
D'où la non moins fameuse option d'exp, j'ai nommé CONSISTENT=Y :o)

(Bon, je l'ai su, mais il a fallu me le souffler, ça fait depuis
tellement longtemps que j'ai vu la lumière :)

Le Thursday 11 December 2008 13:50:37 REISS Thomas DSIC BIP, vous avez écrit :
> Le 11/12/2008 08:32, Marc Cousin a écrit :
> > 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é).
>
> D'où la non moins fameuse option d'exp, j'ai nommé CONSISTENT=Y :o)
>
> (Bon, je l'ai su, mais il a fallu me le souffler, ça fait depuis
> tellement longtemps que j'ai vu la lumière :)

Exact... Elle a juste quelques défauts :
- Elle n'est pas par défaut (je trouve ça incroyable... par défaut, ton export
risque de ne pas pouvoir être importé)
- Elle est plus lente que CONSISTENT=N
- On diminue fortement ses chances d'arriver à la fin de l'export (ou il faut
des undo plus gros pour augmenter statistiquement ses chances), parce qu'on
augment ses chances de 'snapshot too old'.