[Trad] [svn:pgfr] r1426 - traduc/trunk/postgresql

admin at listes.postgresql.fr admin at listes.postgresql.fr
Mar 24 Nov 10:47:10 CET 2009


Author: sas
Date: 2009-11-24 10:47:09 +0100 (Tue, 24 Nov 2009)
New Revision: 1426

Modified:
   traduc/trunk/postgresql/backup.xml
   traduc/trunk/postgresql/bki.xml
   traduc/trunk/postgresql/btree-gin.xml
   traduc/trunk/postgresql/btree-gist.xml
Log:
Relecture vs 8.4


Modified: traduc/trunk/postgresql/backup.xml
===================================================================
--- traduc/trunk/postgresql/backup.xml	2009-11-23 13:33:25 UTC (rev 1425)
+++ traduc/trunk/postgresql/backup.xml	2009-11-24 09:47:09 UTC (rev 1426)
@@ -40,7 +40,7 @@
    <xref linkend="app-pgdump"/>. L'usage basique est&nbsp;:
 <synopsis>pg_dump <replaceable class="parameter">base_de_donnees</replaceable> &gt; <replaceable class="parameter">fichier_de_sortie</replaceable></synopsis>
    <application>pg_dump</application> écrit son résultat sur la
-   sortie standard. Son utilité est expliqué plus loin.
+   sortie standard. Son utilité est expliquée plus loin.
   </para>
 
   <para>
@@ -169,7 +169,7 @@
      par <application>pg_dump</application>. En conséquence, si une base
      <literal>template1</literal> modifiée est utilisée lors de la
      restauration, il faut créer la base vide à partir de
-     <literal>template0</literal>, comme dans l'exemple précédent.
+     <literal>template0</literal>, comme dans l'exemple plus haut.
     </para>
    </important>
 
@@ -219,7 +219,8 @@
 
    <para>
     <application>pg_dumpall</application> fonctionne en émettant des
-    commandes pour re-créer des rôles, des tablespaces et des bases vides, puis
+    commandes pour recréer les rôles, les
+    <foreignphrase>tablespaces</foreignphrase> et les bases vides, puis
     en invoquant <application>pg_dump</application> pour chaque base de
     données. Cela signifie que, bien que chaque base de données est
     cohérente en interne, les images des différentes bases de données peuvent
@@ -380,8 +381,7 @@
    <quote>image gelée</quote> (<foreignphrase>frozen snapshot</foreignphrase>) 
    du volume contenant la base de données et
    ensuite de copier entièrement le répertoire de données (pas seulement
-   quelques parties,
-   voir ci-dessus) de l'image sur un périphérique de sauvegarde, puis de
+   quelques parties, voir plus haut) de l'image sur un périphérique de sauvegarde, puis de
    libérer l'image gelée. Ceci fonctionne même si le serveur de la base de
    données est en cours d'exécution. Néanmoins, une telle sauvegarde
    copie les fichiers de la base de données dans un état où le
@@ -402,14 +402,15 @@
    sauvegarde par images n'est probablement pas utilisable parce que ces
    dernières <emphasis>doivent</emphasis> être simultanées.
    La documentation du système de fichiers doit être étudiée avec attention
-   avant de faire confiance à la technique d'images
-   cohérentes dans de telles situations. L'approche la plus sûre est d'arrêter
+   avant de faire confiance à la technique d'images cohérentes dans de telles situations.
+   <!-- Disparu de la version 8.4.1
+   L'approche la plus sûre est d'arrêter
    le serveur de bases de données assez longtemps pour créer toutes les images
-   gelées.
+   gelées.-->
   </para>
 
   <para>
-   S'il n'est pas possible d'obtenir des images gelées simultanées, il est
+   S'il n'est pas possible d'obtenir des images simultanées, il est
    toujours possible d'éteindre le serveur de bases de données suffisamment
    longtemps pour établir toutes les images gelées. Une autre possibilité est
    de faire une sauvegarde de la base en archivage continu (<xref
@@ -446,7 +447,7 @@
   <title>Archivage continu et récupération d'un instantané (PITR)</title>
 
   <indexterm zone="backup">
-   <primary>archivage en continue</primary>
+   <primary>archivage en continu</primary>
   </indexterm>
 
   <indexterm zone="backup">
@@ -559,7 +560,7 @@
 
    <para>
     Lors de l'archivage des données WAL, le contenu de
-    chaque fichier de segment doit être capturé dès qu'il est rempli pour
+    chaque fichier segment doit être capturé dès qu'il est rempli pour
     sauvegarder les données ailleurs avant son recyclage.
     En fonction de l'application et du matériel disponible, 
     <quote>sauvegarder les données ailleurs</quote> peut se faire de plusieurs
@@ -571,7 +572,7 @@
     base de données, <productname>PostgreSQL</productname> essaie de ne faire aucune
     supposition sur la façon dont l'archivage est réalisé. À la place,
     <productname>PostgreSQL</productname> permet de préciser la commande
-    shell à exécuter pour copier le fichier de segment complet à l'endroit
+    shell à exécuter pour copier le fichier segment complet à l'endroit
     désiré. La commande peut être aussi simple qu'un
     <literal>cp</literal> ou impliquer un shell complexe &mdash;
     c'est l'utilisateur qui décide.
@@ -624,13 +625,13 @@
    </para>
 
    <para>
-    La commande d'archivage doit en général être conçue pour refuser
+    La commande d'archivage doit, en général, être conçue pour refuser
     d'écraser tout fichier archive qui existe déjà. C'est une fonctionnalité
     de sécurité importante pour préserver l'intégrité de l'archive dans le
     cas d'une erreur de l'administrateur (comme l'envoi de la sortie de deux
     serveurs différents dans le même répertoire d'archivage). Il est
     conseillé de tester la commande d'archivage proposée pour
-    s'assurer qu'en effet elle n'écrase pas un fichier existant <emphasis>et
+    s'assurer, qu'en effet, elle n'écrase pas un fichier existant, <emphasis>et
     qu'elle retourne un statut différent de zéro dans ce cas</emphasis>.
     Il a été découvert
     que <literal>cp -i</literal> travaille correctement sur certaines plateformes,
@@ -643,9 +644,8 @@
 
    <para>
     Lors de la conception de la configuration d'archivage, il faut
-    considérer ce qui arrive si la commande d'archivage échoue de façon
-    répétée, parce
-    que certains aspects demandent une intervention de l'opérateur ou
+    considérer ce qui peut se produire si la commande d'archivage échoue de façon
+    répétée, que ce soit parce qu'une intervention de l'opérateur s'avère nécessaire ou
     par manque d'espace dans le répertoire d'archivage. 
     Ceci peut arriver, par exemple, lors de l'écriture sur une cartouche sans changeur 
     automatique&nbsp;; quand la cartouche est pleine, rien ne peut être
@@ -657,12 +657,12 @@
     (Si le système de fichiers contenant <filename>pg_xlog/</filename> se
     remplit, <productname>PostgreSQL</productname> s'arrête en mode PANIC.
     Aucune transaction antérieure n'est perdue mais la base de données est
-    indisponible le temps pour l'utilisateur de retrouver de l'espace.)
+    indisponible tant que de l'espace n'a pas été libéré.)
    </para>
 
    <para>
     La vitesse de la commande d'archivage n'est pas importante, tant qu'elle
-    suit le rythme que la génération de données WAL du serveur. Les
+    suit le rythme de génération des données WAL du serveur. Les
     opérations normales continuent même si le processus d'archivage est un peu
     plus lent. Si l'archivage est significativement plus lent, alors la
     quantité de données qui peut être perdue croît. Cela signifie
@@ -684,8 +684,7 @@
 
    <para>
     Bien que l'archivage WAL autorise à restaurer toute
-    modification réalisée sur les données de la base 
-    <productname>PostgreSQL</productname>, il ne restaure pas les modifications
+    modification réalisée sur les données de la base, il ne restaure pas les modifications
     effectuées sur les fichiers de configuration (c'est-à-dire
     <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename> et
     <filename>pg_ident.conf</filename>) car ceux-ci sont édités manuellement
@@ -699,7 +698,7 @@
    <para>
     La commande d'archivage n'est appelée que sur les segments WAL complets.
     Du coup, si le serveur engendre peu de trafic WAL (ou qu'il y a des périodes
-    de calme où le trafic WAL est léger), il peut y avoir une longue période
+    de calme où le trafic WAL est léger), il peut y avoir un long délai
     entre la fin d'une transaction et son enregistrement sûr dans le stockage
     d'archive. Pour placer une limite sur l'ancienneté des données archivées,
     on configure <xref linkend="guc-archive-timeout"/> qui force le
@@ -725,11 +724,11 @@
     éviter la journalisation des transactions, de la façon décrite dans
     <xref linkend="populate-pitr"/>. Si l'archivage est activé lors de
     l'exécution d'une de ces instructions, les journaux de transaction ne
-    contiennent pas d'informations suffisantes pour une récupération via les
-    archives mais la récupération après un arrêt brutal n'est pas affectée.
+    contiennent pas suffisamment d'informations pour une récupération via les
+    archives. (La récupération après un arrêt brutal n'est pas affectée.)
     Pour cette raison, <varname>archive_mode</varname> ne peut être
     modifié qu'au lancement du serveur. Néanmoins,
-    <varname>archive_command</varname> peut être modifié avec un
+    <varname>archive_command</varname> peut être modifié par
     rechargement du fichier de configuration. Pour arrêter
     temporairement l'archivage, on peut placer une
     chaîne vide (<literal>''</literal>) pour
@@ -775,18 +774,19 @@
     <para>
      Par défaut, <function>pg_start_backup</function> peut prendre beaucoup de temps
      pour arriver à son terme. Ceci est dû au fait qu'il réalise un
-     point de retournement, et que les entrées/sorties pour l'établissement
-     de ce point de retournement seront réparties sur une grande période
-     de temps, par défaut la moitié de l'intervalle d'un point de
-     retournement (voir le paramètre de configuration
+     point de vérification (<foreignphrase>chackpoint</foreignphrase>),
+     et que les entrées/sorties pour l'établissement
+     de ce point de vérification seront réparties sur une grande durée, 
+     par défaut la moitié de l'intervalle entre deux points de
+     vérification (voir le paramètre de configuration
      <xref linkend="guc-checkpoint-completion-target"/>). Habituellement,
-     ce comportement est appréciable car il minimise l'impact du traitement
+     ce comportement est appréciable, car il minimise l'impact du traitement
      des requêtes. Pour commencer la sauvegarde aussi rapidement
-     que possible, utilisez&nbsp;:
+     que possible, utiliser&nbsp;:
 <programlisting>
 SELECT pg_start_backup('label', true);
 </programlisting>
-     Cela force l'exécution du point de retournement aussi rapidement que possible.
+     Cela force l'exécution du point de vérification aussi rapidement que possible.
     </para>
    </listitem>
    <listitem>
@@ -803,8 +803,8 @@
      Se connecter à nouveau à la base de données en tant que
      superutilisateur et lancer la commande&nbsp;:
 <programlisting>SELECT pg_stop_backup();</programlisting>
-     Cela met fin au processus de sauvegarde et réalise un basculement
-     automatique vers le prochain segment WAL. Ce basculement est nécessaire
+     Cela met fin au processus de sauvegarde et réalise une bascule
+     automatique vers le prochain segment WAL. Cette bascule est nécessaire
      pour permettre au dernier fichier de segment WAL écrit pendant la
      sauvegarde d'être immédiatement archivable.
     </para>
@@ -817,13 +817,14 @@
      un jeu complet de fichiers de backup.
      <function>pg_stop_backup</function> ne rend pas la main avant que le dernier segment
      n'ait été archivé. L'archivage de ces fichiers est automatique puisque
-     vous avez déjà configuré <varname>archive_command</varname>. Dans la plupart des
-     cas, c'est rapide, mais il est conseillé de surveiller votre système d'archivage pour
-     vous assurer qu'il n'y a pas de retard. Si le processus d'archivage a pris du retard 
+     <varname>archive_command</varname> est configuré. Dans la plupart des
+     cas, c'est rapide, mais il est conseillé de surveiller le système d'archivage pour
+     s'assurer qu'il n'y a pas de retard. Si le processus d'archivage a pris du retard 
      en raison d'échecs de la commande d'archivage, il continuera d'essayer jusqu'à ce que
-     l'archive réussisse et que le backup soit complet. Si vous souhaitez
-     positionner une limite au temps d'exéuction de <function>pg_stop_backup</function>,
-     mettez en place une valeur appropriée de <varname>statement_timeout</varname>.
+     l'archive réussisse et que le backup soit complet. Pour
+     positionner une limite au temps d'exécution de <function>pg_stop_backup</function>,
+     il faut positionner <varname>statement_timeout</varname> à une valeur
+     appropriée.
     </para>
    </listitem>
   </orderedlist>
@@ -831,10 +832,10 @@
 
    <para>
     Certains outils de sauvegarde émettent des
-    messages d'avertissements ou d'erreurs si les fichiers qu'ils essaient de
+    messages d'avertissement ou d'erreur si les fichiers qu'ils essaient de
     copier sont modifiés au cours de la copie. Cette situation, normale lors
     de la sauvegarde d'une base active, ne doit pas être considérée comme 
-    une erreur&nbsp;; il suffit de s'assurer que ces messages peuvent être
+    une erreur&nbsp;; il suffit de s'assurer que ces messages puissent être
     distingués des autres messages. Certaines versions de
     <application>rsync</application>, par exemple, renvoient un code de sortie
     distinct en cas de <quote>disparition de fichiers source</quote>. Il est
@@ -870,11 +871,11 @@
     La sauvegarde doit inclure tous les fichiers du répertoire
     du groupe de bases de données
     (<filename>/usr/local/pgsql/data</filename>, par exemple). Si des
-    <foreignphrase>tablespace</foreignphrase> 
+    <foreignphrase>tablespaces</foreignphrase> 
     qui ne se trouvent pas dans ce répertoire sont utilisés, il ne faut pas
     oublier de les inclure (et s'assurer également que la sauvegarde archive les liens
     symboliques comme des liens, sans quoi la restauration des
-    <foreignphrase>tablespace</foreignphrase> sera problématique).
+    <foreignphrase>tablespaces</foreignphrase> sera problématique).
    </para>
 
    <para>
@@ -887,6 +888,7 @@
     ce qui est toutefois une configuration courante, pour des raisons de performance.
    </para>
 
+   <!--SAS::ICI -->
    <para>
     La sauvegarde n'est utilisable que si les fichiers de segment WAL
     engendrés pendant ou après cette sauvegarde sont préservés.

Modified: traduc/trunk/postgresql/bki.xml
===================================================================
--- traduc/trunk/postgresql/bki.xml	2009-11-23 13:33:25 UTC (rev 1425)
+++ traduc/trunk/postgresql/bki.xml	2009-11-24 09:47:09 UTC (rev 1426)
@@ -183,7 +183,7 @@
      <para>
       La valeur NULL peut être indiquée en utilisant le mot clé spécial
       <literal>_null_</literal>. Les valeurs contenant des espaces doivent être
-      placées entre des guillemets doubles.
+      placées entre guillemets doubles.
      </para>
     </listitem>
    </varlistentry>
@@ -296,7 +296,7 @@
     </listitem>
     <listitem>
      <para>
-      Répéter pour les autres tables critiques.
+      À répéter pour les autres tables critiques.
      </para>
     </listitem>
     <listitem>
@@ -321,7 +321,7 @@
     </listitem>
     <listitem>
      <para>
-      Répéter pour les autres tables non critiques.
+      À répéter pour les autres tables non critiques.
      </para>
     </listitem>
     <listitem>

Modified: traduc/trunk/postgresql/btree-gin.xml
===================================================================
--- traduc/trunk/postgresql/btree-gin.xml	2009-11-23 13:33:25 UTC (rev 1425)
+++ traduc/trunk/postgresql/btree-gin.xml	2009-11-24 09:47:09 UTC (rev 1426)
@@ -13,7 +13,7 @@
 
  <para>
   <filename>btree_gin</filename> fournit des échantillons de classes d'opérateurs
-  GIN qui implémentent un comportement équivalent à un B-Tree pour les types
+  GIN qui codent un comportement équivalent à un B-Tree pour les types
   <type>int2</type>, <type>int4</type>, <type>int8</type>, <type>float4</type>,
   <type>float8</type>, <type>timestamp with time zone</type>,
   <type>timestamp without time zone</type>, <type>time with time zone</type>,
@@ -25,8 +25,8 @@
  </para>
 
  <para>
-  En général, ces classes d'opérateurs ne seront pas plus rapides que
-  les méthodes standards d'indexation btree équivalentes, et il leur manquera
+  En général, ces classes d'opérateurs ne sont pas plus rapides que
+  les méthodes standard d'indexation btree équivalentes, et il leur manque
   une fonctionnalité majeure du code btree standard&nbsp;: la capacité à forcer
   l'unicité. Toutefois, elles sont utiles pour tester GIN et comme base pour
   développer d'autres classes d'opérateurs GIN. Par ailleurs, pour des requêtes

Modified: traduc/trunk/postgresql/btree-gist.xml
===================================================================
--- traduc/trunk/postgresql/btree-gist.xml	2009-11-23 13:33:25 UTC (rev 1425)
+++ traduc/trunk/postgresql/btree-gist.xml	2009-11-24 09:47:09 UTC (rev 1426)
@@ -13,7 +13,7 @@
 
  <para>
   <filename>btree_gist</filename> fournit des exemples de classes d'opérateur
-  GiST qui implantent un comportement équivalent à celui du B-Tree pour les
+  GiST qui codent un comportement équivalent à celui du B-Tree pour les
   types de données
   <type>int2</type>, <type>int4</type>, <type>int8</type>, <type>float4</type>,
   <type>float8</type>, <type>numeric</type>, <type>timestamp with time



Plus d'informations sur la liste de diffusion Trad