[Trad] [svn:pgfr] r1200 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Sam 29 Nov 20:08:44 CET 2008
Author: gleu
Date: 2008-11-29 20:08:43 +0100 (Sat, 29 Nov 2008)
New Revision: 1200
Modified:
traduc/trunk/postgresql/mvcc.xml
Log:
Correction d'une erreur signal?\195?\169e par Florence Cousin et quelques corrections
suite ?\195?\160 la relecture du chapitre complet.
Modified: traduc/trunk/postgresql/mvcc.xml
===================================================================
--- traduc/trunk/postgresql/mvcc.xml 2008-11-22 09:42:12 UTC (rev 1199)
+++ traduc/trunk/postgresql/mvcc.xml 2008-11-29 19:08:43 UTC (rev 1200)
@@ -12,13 +12,13 @@
</indexterm>
<para>
- Ce chapitre décrit le comportement du système de bases de données
- <productname>PostgreSQL</productname> lorsque deux sessions, ou plus,
- essaient d'accéder aux mêmes données au même moment. Le but dans cette
- situation est de permettre un accès efficace pour toutes les sessions tout
- en maintenant une intégrité stricte des données. Chaque développeur
- d'applications utilisant des bases de données devrait être familier avec les
- thèmes couverts dans ce chapitre.
+ Ce chapitre décrit le comportement de <productname>PostgreSQL</productname>
+ lorsque deux sessions, ou plus, essaient d'accéder aux mêmes données au
+ même moment. Le but dans cette situation est de permettre un accès
+ efficace pour toutes les sessions tout en maintenant une intégrité stricte
+ des données. Chaque développeur d'applications utilisant des bases de
+ données doit avoir une bonne compréhension des thèmes couverts dans ce
+ chapitre.
</para>
<sect1 id="mvcc-intro">
@@ -29,21 +29,21 @@
</indexterm>
<para>
- <productname>PostgreSQL</productname> fournit un ensemble riche d'outils
- pour les développeurs qui gèrent des accès parallèles aux données.
- En interne, la cohérence des données est atteinte avec l'utilisation d'un
+ <productname>PostgreSQL</productname> fournit un ensemble d'outils
+ pour les développeurs qui souhaitent gérer des accès simulatnés aux données.
+ En interne, la cohérence des données est obtenue avec l'utilisation d'un
modèle multiversion (Multiversion Concurrency Control, <acronym>MVCC</acronym>).
- Ceci signifie que, lors d'une requête à la
+ Ceci signifie que, lors de l'envoi d'une requête à la
base de données, chaque transaction voit une image des données (une
<firstterm>version de la base de données</firstterm>) telle qu'elles
- étaient quelque temps auparavant, quelque soit l'état actuel des données
- sous-jacentes. Ceci protège la transaction des données incohérentes,
- causées par les mises à jour effectuées par une (autre) transaction
- concurrente sur les mêmes lignes de données, fournissant ainsi une
+ étaient quelque temps auparavant, quel que soit l'état actuel des données
+ sous-jacentes. Ceci protège la transaction de données incohérentes,
+ causées par des mises à jour effectuées par une (autre) transaction
+ simultanée sur les mêmes lignes de données, fournissant ainsi une
<firstterm>isolation des transactions</firstterm> pour chaque session de la
- base de données. <acronym>MVCC</acronym>, en évitant les méthodes de verrous
+ base de données. <acronym>MVCC</acronym>, en évitant les méthodes des verrous
explicites des systèmes de bases de données traditionnels, minimise la
- conservation des verrous pour permettre des performances raisonnables dans
+ durée des verrous pour permettre des performances raisonnables dans
des environnements multiutilisateurs.
</para>
@@ -57,7 +57,7 @@
</para>
<para>
- Les capacités de verrouillage des tables ou des lignes sont aussi disponibles
+ Des possibilités de verrouillage des tables ou des lignes sont aussi disponibles
dans <productname>PostgreSQL</productname> pour les applications ne pouvant
pas s'adapter facilement au comportement de <acronym>MVCC</acronym>. Néanmoins,
un bon usage de <acronym>MVCC</acronym> fournira généralement de
@@ -77,7 +77,7 @@
<para>
Le standard <acronym>SQL</acronym> définit quatre niveaux d'isolation de
transaction pour empêcher trois phénomènes de se produire lors de
- transactions concurrentes. Ces phénomènes indésirables sont :
+ transactions simultanées. Ces phénomènes indésirables sont :
<variablelist>
<varlistentry>
@@ -244,7 +244,7 @@
</para>
<sect2 id="xact-read-committed">
- <title>Niveau d'isolation Read committed (lecture des seules données validées)</title>
+ <title>Niveau d'isolation Read committed (lecture uniquement des données validées)</title>
<indexterm>
<primary>niveau d'isolation de transaction</primary>
@@ -285,7 +285,7 @@
trouvées. Si la première mise à jour est validée, la deuxième mise à jour
ignorera la ligne si la première mise à jour l'a supprimée, sinon elle
essaiera d'appliquer son opération à la version mise à jour de la ligne. La
- condition de recherche de la commande (la clause <literal>WHERE</literal>) est
+ condition de la recherche de la commande (la clause <literal>WHERE</literal>) est
ré-évaluée pour savoir si la version mise à jour de la ligne correspond
toujours à la condition de recherche. Dans ce cas, la deuxième mise à jour
continue son opération en commençant par la version mise à jour de la
@@ -301,7 +301,8 @@
celles qu'elle essaie de mettre à jour mais elle ne voit pas les effets de
ces commandes sur les autres lignes de la base de données. Ce comportement
rend le mode de lecture validée non convenable pour les commandes qui
- impliquent des conditions de recherche complexes. Néanmoins, il est correct pour
+ impliquent des conditions de recherche complexes. Néanmoins, il est
+ intéressant pour
les cas simples. Par exemple, considérons la mise à jour de balances de
banque avec des transactions comme
@@ -365,7 +366,7 @@
voit une image du début de la transaction et non pas du début de la requête
en cours à l'intérieur de la transaction. Du coup, les commandes
<command>SELECT</command> successives à l'intérieur d'une même transaction
- voit toujours les mêmes données.
+ voient toujours les mêmes données.
</para>
<para>
@@ -381,7 +382,7 @@
mise à jour soit validée ou annulée (si celle-ci est toujours en
cours). Si la première mise à jour est annulée, les effets sont inversés et
la transaction sérialisable peut continuer avec la mise à jour de la ligne
- trouvée à l'origine. Mais si le processus de mise à jour est validé (et que
+ trouvée à l'origine. Mais si la mise à jour est validée (et que
la ligne est mise à jour ou supprimée, pas simplement verrouillée),
alors la transaction sérialisable sera annulée avec le message
@@ -412,7 +413,7 @@
accède à une vue totalement cohérente de la base de données. Néanmoins,
l'application doit être prête à tenter de nouvelles transactions lorsque des
mises à jour concurrentes rendent impossibles de soutenir l'illusion d'une
- exécution en série. Comme le coût de re-lancement de transactions complexes
+ exécution en série. Comme le coût de la ré-exécution de transactions complexes
pourrait être significatif, ce mode est seulement recommandé lors de mise à
jour contenant une logique suffisamment complexe pour donner de
mauvaises réponses dans le mode de lecture validée. Plus communément, le
@@ -422,7 +423,7 @@
</para>
<sect3 id="mvcc-serializability">
- <title>Isolation sérialisable contre vraie sérialisation</title>
+ <title>Isolation sérialisable et vraie sérialisation</title>
<indexterm>
<primary>sérialisation</primary>
@@ -435,7 +436,7 @@
<para>
La signification intuitive (et la définition mathématique) de l'exécution
<quote>sérialisable</quote> est que toute paire de transactions
- concurrentes validées avec succès apparaîtra comme ayant été exécutée
+ concurrentes validée avec succès apparaîtra comme ayant été exécutée
en série, l'une après l'autre — bien que celle survenant en premier
n'est pas prévisible. Il est important de réaliser qu'interdire les
comportements indésirables listés dans le <xref
@@ -443,7 +444,7 @@
vraie exécution en série et, en fait, le mode sérialisable de
<productname>PostgreSQL</productname> <emphasis>ne garantit pas
une exécution en série dans ce sens</emphasis>. Comme exemple, considérez
- une table <structname>ma_table</structname>, contenant initialement
+ la table <structname>ma_table</structname>, contenant initialement
<screen> classe | valeur
--------+-------
1 | 10
@@ -453,7 +454,7 @@
Supposons que la transaction sérialisable A traite
<screen>SELECT SUM(valeur) FROM ma_table WHERE classe = 1;</screen>
puis insère le résultat (30) comme <structfield>valeur</structfield> dans une
- nouvelle ligne avec <structfield>classe</structfield> = 2. En concurrence, la
+ nouvelle ligne avec <structfield>classe</structfield> = 2. Simultanément, la
transaction serialisable B traite
<screen>SELECT SUM(valeur) FROM ma_table WHERE classe = 2;</screen>
et obtient le résultat 300, qu'il insère dans une nouvelle ligne avec
@@ -488,7 +489,7 @@
concurrente. Et cette grande dépense est pratiquement complètement perdue
car, en pratique, la plupart des applications ne posent pas ce genre de
problèmes (l'exemple ci-dessus est assez petit et a peu de chance de
- représenter de vrais logiciels). Pour ces raisons,
+ se présenter avec de vrais logiciels). Pour ces raisons,
<productname>PostgreSQL</productname> n'implémente pas le verrouillage
de prédicat.
</para>
@@ -496,8 +497,8 @@
<para>
Dans ces cas où la possibilité d'une exécution non sérialisable est un
vrai hasard, les problèmes peuvent être prévenus par l'utilisation
- appropriée d'un verrou explicite. Les sections suivantes comprennent plus
- de discussion sur ce sujet.
+ appropriée d'un verrou explicite. Les sections suivantes contiennent plus
+ d'informations sur ce sujet.
</para>
</sect3>
</sect2>
@@ -512,7 +513,7 @@
<para>
<productname>PostgreSQL</productname> fournit de nombreux modes de verrous
- pour contrôler les accès concurrents aux données des tables. Ces modes
+ pour contrôler les accès simultanés aux données des tables. Ces modes
peuvent être utilisés pour contrôler le verrouillage par l'application dans
des situations où <acronym>MVCC</acronym> n'a pas le comportement désiré. De
plus, la plupart des commandes <productname>PostgreSQL</productname>
@@ -525,8 +526,7 @@
</para>
<para>
- Pour examiner une liste des verrous actuels dans un serveur de base de
- données, utilisez la vue système <link
+ Pour examiner une liste des verrous en cours, utilisez la vue système <link
linkend="view-pg-locks"><structname>pg_locks</structname></link>. Pour plus
d'informations sur la surveillance du statut du sous-système de gestion des
verrous, référez-vous au <xref linkend="monitoring"/>.
@@ -557,7 +557,7 @@
elle-même. Par exemple, elle pourrait acquérir un verrou <literal>ACCESS
EXCLUSIVE</literal> et acquérir plus tard un verrou <literal>ACCESS
SHARE</literal> sur la même table). Des modes de verrou sans conflit
- pourraient être détenus en même temps par plusieurs transactions. Notez, en
+ peuvent être détenus en même temps par plusieurs transactions. Notez, en
particulier, que certains modes de verrous sont en conflit avec eux-même (par
exemple, un verrou <literal>ACCESS EXCLUSIVE</literal> ne peut pas être
détenu par plus d'une transaction à la fois) alors que d'autres n'entrent
@@ -577,9 +577,9 @@
</para>
<para>
- Les commandes <command>SELECT</command> acquièrent un verrou sur ce
+ Les commandes <command>SELECT</command> acquièrent un verrou de ce
mode avec les tables référencées. En général, tout requête lisant
- seulement une table et ne la modifiant pas obtiendra ce mode de verrou.
+ seulement une table et ne la modifiant pas obtient ce mode de verrou.
</para>
</listitem>
</varlistentry>
@@ -611,7 +611,7 @@
<listitem>
<para>
En conflit avec les modes de verrous <literal>SHARE</literal>,
- <literal>SHARE ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>,
+ <literal>SHARE ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>
et <literal>ACCESS EXCLUSIVE</literal>.
</para>
@@ -636,7 +636,7 @@
EXCLUSIVE</literal>, <literal>SHARE</literal>, <literal>SHARE ROW
EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
<literal>ACCESS EXCLUSIVE</literal>. Ce mode protège une table contre
- les modifications concurrentes de schéma et l'exécution d'un
+ les modifications simultanées de schéma et l'exécution d'un
<command>VACUUM</command>.
</para>
@@ -657,7 +657,7 @@
<literal>SHARE UPDATE EXCLUSIVE</literal>, <literal>SHARE ROW
EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal> et
<literal>ACCESS EXCLUSIVE</literal>. Ce mode protège une table contre
- les modifications de données concurrentes.
+ les modifications simultanées des données.
</para>
<para>
@@ -680,7 +680,7 @@
</para>
<para>
- Ce mode de verrouillage n'est automatiquement acquis par aucune
+ Ce mode de verrouillage n'est automatiquement acquis par aucune
commande <productname>PostgreSQL</productname>.
</para>
</listitem>
@@ -703,9 +703,9 @@
</para>
<para>
- Ce mode de verrouillage n'est pas automatiquement acquis sur les tables
+ Ce mode de verrouillage n'est pas automatiquement acquis sur les tables
utilisateur par une commande <productname>PostgreSQL</productname>.
- Néanmoins, c'est acquis sur certains catalogues systèmes pour certaines
+ Néanmoins, il est utilisé sur certains catalogues systèmes pour certaines
opérations.
</para>
</listitem>
@@ -749,14 +749,13 @@
Une fois acquis, un verrou est normalement détenu jusqu'à la fin de la
transaction. Mais si un verrou est acquis après l'établissement d'un point
de sauvegarde, le verrou est relâché immédiatement si le point de sauvegarde
- est annulé. Ceci est cohérent avec le principe que <command>ROLLBACK</command>
- annule tous les effets des commandes depuis le dernier point de sauvegarde.
+ est annulé. Ceci est cohérent avec le principe du <command>ROLLBACK</command>
+ annulant tous les effets des commandes depuis le dernier point de sauvegarde.
Il se passe la même chose pour les verrous acquis à l'intérieur d'un bloc
d'exception <application>PL/pgSQL</application> : un échappement
d'erreur à partir du bloc lâche les verrous acquis dans le bloc.
</para>
-<!-- -->
<table tocentry="1" id="table-lock-compatibility">
<title>Modes de verrou conflictuels</title>
<tgroup cols="9">
@@ -870,7 +869,7 @@
</row>
</tbody>
</tgroup>
- </table> <!-- -->
+ </table>
</sect2>
<sect2 id="locking-rows">
@@ -902,7 +901,7 @@
partagé. Néanmoins, aucune transaction n'est autorisée à mettre à jour,
supprimer ou verrouiller exclusivement une ligne dont une autre
transaction a obtenu un verrou partagé. Toute tentative de le faire
- bloquera tant que les verrous partagés n'auront pas été enlevés.
+ bloque tant que les verrous partagés n'ont pas été enlevés.
</para>
<para>
@@ -910,16 +909,16 @@
sur les lignes modifiées, il n'y a donc aucune limite sur le
nombre de lignes verrouillées à un moment donné. Néanmoins, verrouiller une
ligne peut causer une écriture disque ; ainsi, par exemple,
- <command>SELECT FOR UPDATE</command> modifiera les lignes sélectionnées
- pour les marquer verrouillées et cela résultera en des écritures disques.
+ <command>SELECT FOR UPDATE</command> modifie les lignes sélectionnées
+ pour les marquer verrouillées et cela aboutit à des écritures disques.
</para>
<para>
En plus des verrous tables et lignes, les verrous partagés/exclusifs sur
les pages sont utilisés pour contrôler la lecture et l'écriture des pages
- de table dans l'ensemble de tampons partagées. Ces verrous sont
+ de table dans l'ensemble des tampons partagées. Ces verrous sont
immédiatement relâchés une fois la ligne récupérée ou mise à jour. Les
- développeurs d'application ne sont normalement pas concernés par les
+ développeurs d'applications ne sont normalement pas concernés par les
verrous au niveau page mais nous les mentionnons dans un souci d'exhaustivité.
</para>
@@ -952,9 +951,9 @@
</para>
<para>
- Notez que les verrous morts peuvent aussi se produire en résultat à des verrous
- de niveau ligne (et du coup, ils peuvent se produire même si le
- verrouillage explicite n'est pas utilisé). Considérons le cas où il
+ Notez que les verrous morts peuvent aussi se produire en conséquence à
+ des verrous de niveau ligne (et du coup, ils peuvent se produire même si
+ le verrouillage explicite n'est pas utilisé). Considérons le cas où il
existe deux transactions concurrentes modifiant une table. La première
transaction exécute :
@@ -991,17 +990,17 @@
données acquièrent des verrous sur des objets multiples dans un ordre
cohérent. Dans l'exemple ci-dessus, si les deux transactions avaient mis
à jour les lignes dans le
- même ordre, aucun blocage n'aurait eu lieu. Vous devriez vous assurer que
+ même ordre, aucun blocage n'aurait eu lieu. Vous devez vous assurer que
le premier verrou acquis sur un objet dans une transaction est dans
- le plus haut mode qui sera nécessaire pour cet objet. S'il n'est pas possible de
- vérifier ceci à l'avance, alors les blocages devront être gérés à
+ le plus haut mode nécessaire pour cet objet. S'il n'est pas possible de
+ vérifier ceci à l'avance, alors les blocages doivent être gérés à
l'exécution en ré-essayant les transactions annulées à cause de blocage.
</para>
<para>
Tant qu'aucune situation de blocage n'est détectée, une transaction
cherchant soit un verrou de niveau table soit un verrou de niveau ligne
- attendra indéfiniment que les verrous en conflit soient relâchés. Ceci
+ attend indéfiniment que les verrous en conflit soient relâchés. Ceci
signifie que maintenir des transactions ouvertes sur une longue période
de temps (par exemple en attendant une saisie de l'utilisateur) est
parfois une mauvaise idée.
@@ -1032,13 +1031,13 @@
soit relâché ou que la session se termine. Contrairement aux verrous
standards, les verrous informatifs n'honorent pas de sémantiques de
transactions : un verrou informatif acquis lors d'une
- transaction qui sera par la suite annulée sera toujours détenu après
- l'annulation, et de la même façon un déverrouillage sera toujours vrai
+ transaction qui est par la suite annulée est toujours détenu après
+ l'annulation, et de la même façon un déverrouillage est toujours vrai
même si la transaction appelante échoue. Le même verrou peut être acquis
plusieurs fois par le processus qui le détient : à chaque demande de
verrou doit correspondre une demande de déverrouillage avant que le verrou
ne soit réellement supprimé. (Si une session détient déjà un verrou donné,
- les demandes suivantes réussiront même si d'autres sessions attendent le
+ les demandes suivantes réussissent même si d'autres sessions attendent le
verrou.) Comme tous les verrous de <productname>PostgreSQL</productname>,
une liste complète des verrous informatifs détenus actuellement par une
session est visible dans la vue système <structname>pg_locks</structname>.
@@ -1049,7 +1048,7 @@
partagée dont la taille est définie par les variables de configuration
<xref linkend="guc-max-locks-per-transaction"/> et
<xref linkend="guc-max-connections"/>. Attention à ne pas vider cette
- mémoire, sinon le serveur ne sera plus capable d'accorder des verrous.
+ mémoire, le serveur ne serait plus capable d'accorder des verrous.
Ceci impose une limite supérieure au nombre de verrous informatifs que le
serveur peut accorder, typiquement entre des dizaines et des centaines de
milliers suivant la façon dont le serveur est configuré.
@@ -1058,9 +1057,9 @@
<para>
Une utilisation commune des verrous informatifs est d'émuler des stratégies
de verrou pessimiste, typiques des systèmes de gestion de données sur
- <quote>fichier plat</quote>. Alors qu'une option stocké dans une table
+ <quote>fichier plat</quote>. Alors qu'une option stockée dans une table
pourrait être utilisée dans le même but, les verrous informatifs sont plus
- rapides, éviter le grossissement de MVCC et sont automatiquement nettoyés
+ rapides, évite le grossissement de MVCC et sont automatiquement nettoyés
par le serveur à la fin d'une session. Dans certains cas qui utilisent
cette méthode, tout spécialement les requêtes impliquant un tri explicite
et des clauses <literal>LIMIT</literal>, une grande attention doit être
More information about the Trad
mailing list