Skip to content

Commit

Permalink
Relecture en cours
Browse files Browse the repository at this point in the history
  • Loading branch information
@saspg
saspg committed Nov 9, 2010
1 parent 468b3a4 commit e4b8f90
Showing 1 changed file with 48 additions and 48 deletions.
96 changes: 48 additions & 48 deletions postgresql/maintenance.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,9 +18,9 @@
<para>
<productname>PostgreSQL</productname>, comme tout SGBD, requiert que certains
tâches soient réalisées de façon régulière pour atteindre les performances
optimales. Ces tâches, discutées maintenant, sont <emphasis>requises</emphasis>
optimales. Ces tâches sont <emphasis>requises</emphasis>,
mais elles sont répétitives par nature et peuvent être facilement automatisées
en utilisant des outils standards comme les scripts
en utilisant des outils standard comme les scripts
<application>cron</application> ou le <application>Task Scheduler</application>
de Windows. La responsabilité de la mise en place de ces
scripts et du contrôle de leur bon fonctionnement relève de l'administrateur
Expand All @@ -29,18 +29,18 @@

<para>
Une opération de maintenance évidente est la sauvegarde régulière des
données. Sans une sauvegarde récente il est impossible de restaurer après
données. Sans une sauvegarde récente, il est impossible de restaurer après
un dommage grave (perte d'un disque, incendie, table supprimée par erreur,
etc.). Les mécanismes de sauvegarde et restauration disponibles dans
<productname>PostgreSQL</productname> sont détaillés dans le <xref
linkend="backup"/>.
</para>

<para>
L'autre tâche primordiale est de réaliser périodiquement un <quote>vacuum</quote>,
L'autre tâche primordiale est la réalisation périodique d'un <quote>vacuum</quote>,
c'est à dire <quote>faire le vide</quote> dans la base de données.
Cette opération est détaillée dans la <xref linkend="routine-vacuuming"/>.
La mise à jour des statistiques qui seront utilisées par le planificateur de
La mise à jour des statistiques utilisées par le planificateur de
requêtes sera discutée dans <xref linkend="vacuum-for-statistics"/>.
</para>

Expand All @@ -54,7 +54,7 @@
url="http://bucardo.org/wiki/Check_postgres"><application>check_postgres</application></ulink>
est disponible pour surveiller la santé des bases de données et pour
rapporter des conditions inhabituelles. <application>check_postgres</application>
s'intègre bien avec Nagios et MRTG, mais il peut aussi fonctionner en autonome.
s'intègre bien avec Nagios et MRTG, mais il peut aussi fonctionner de façon autonome.
</para>

<para>
Expand All @@ -72,11 +72,11 @@

<para>
Le SGBD <productname>PostgreSQL</productname> nécessite des opérations de
maintenance périodique connues sous le nom de <firstterm>VACUUM</firstterm>.
maintenance périodiques, connues sous le nom de <firstterm>VACUUM</firstterm>.
Pour de nombreuses installations, il est suffisant de laisser travailler le
<firstterm>démon autovacuum</firstterm>, qui est décrit dans <xref
linkend="autovacuum"/>. Vous pourriez avoir besoin d'ajuster les paramètres
de cet outil décrit ici pour obtenir de meilleurs résultats dans votre cas.
linkend="autovacuum"/>. En fonction des cas, les paramètres
de cet outil peuvent être optimisés pour obtenir de meilleurs résultats.
Certains administrateurs de bases de données voudront suppléer ou remplacer
les activités du démon avec une gestion manuelle des commandes
<command>VACUUM</command>, qui seront typiquement exécutées suivant un
Expand Down Expand Up @@ -126,19 +126,18 @@
<command>VACUUM</command> peut s'exécuter en parallèle avec les opérations
de production des bases. Des commandes comme <command>SELECT</command>,
<command>INSERT</command>, <command>UPDATE</command> et
<command>DELETE</command> continueront de fonctionner de façon normale,
bien que vous ne pourrez plus modifier la définition d'une table avec des
commandes telles que <command>ALTER TABLE</command> pendant qu'elle sera en
cours de <command>VACUUM</command>.
<command>DELETE</command> continuent de fonctionner de façon normale,
mais la définition d'une table ne peut être modifiée avec des
commandes telles que <command>ALTER TABLE</command> pendant le <command>VACUUM</command>.
<command>VACUUM FULL</command> nécessite un verrou exclusif sur la table sur
laquelle il travaille, et ne peut donc pas être exécuté en parallèle avec une
autre activité sur la table. En règle générale,
par conséquent, les administrateurs devraient s'efforcer d'utiliser la commande
par conséquent, les administrateurs doivent s'efforcer d'utiliser la commande
standard <command>VACUUM</command> et éviter <command>VACUUM FULL</command>.
</para>

<para>
<command>VACUUM</command> génère un nombre important d'entrées/sorties,
<command>VACUUM</command> produit un nombre important d'entrées/sorties,
ce qui peut entraîner de mauvaises performances pour les autres sessions
actives. Des paramètres de configuration peuvent être ajustés pour réduire
l'impact d'une opération VACUUM en arrière plan sur les
Expand All @@ -164,17 +163,17 @@
autre transaction. Mais finalement, une ligne qui est plus vieille que
toutes les transactions en cours n'est plus utile du tout. La place qu'elle
utilise doit être rendue pour être réutilisée par d'autres lignes afin
d'éviter un accroissement constant, sans limite du volume occupé sur le disque. Cela est
d'éviter un accroissement constant, sans limite, du volume occupé sur le disque. Cela est
réalisé en exécutant <command>VACUUM</command>.
</para>

<para>
La forme standard de <command>VACUUM</command> élimine les versions
d'enregistrements morts dans les tables et les index et marque l'espace
comme réutilisable. Néanmoins, il ne rendra pas cet espace au système
d'enregistrements morts dans les tables et les index, et marque l'espace
comme réutilisable. Néanmoins, il ne rend pas cet espace au système
d'exploitation, sauf dans le cas spécial où des pages à la fin d'une table
deviennent totalement vides et on peut facilement obtenir un verrou exclusif
sur la table. Par opposition, <command>VACUUM FULL</command> compacte
deviennent totalement vides et qu'un verrou exclusif
sur la table peut être obtenu aisément. Par opposition, <command>VACUUM FULL</command> compacte
activement les tables en écrivant une nouvelle version complète du fichier
de la table, sans espace vide. Ceci réduit la taille de la table mais peut
prendre beaucoup de temps. Cela requiert aussi un espace disque
Expand All @@ -184,9 +183,9 @@

<para>
Le but habituel d'un vacuum régulier est de lancer des <command>VACUUM</command>
standards suffisamment souvent pour éviter d'avoir recours à
standard suffisamment souvent pour éviter d'avoir recours à
<command>VACUUM FULL</command>. Le démon autovacuum essaie de fonctionner de
cette façon, et n'exécutera jamais de <command>VACUUM FULL</command>. Avec
cette façon, et n'exécute jamais de <command>VACUUM FULL</command>. Avec
cette approche, l'idée directrice n'est pas de maintenir les tables à leur
taille minimale, mais de maintenir l'utilisation de l'espace disque à un niveau
constant&nbsp;: chaque table occupe l'espace équivalent à sa taille minimum plus
Expand All @@ -204,14 +203,14 @@
Certains administrateurs préfèrent planifier le passage de <command>VACUUM</command>
eux-mêmes, par exemple faire le travail de nuit, quand la charge est faible.
La difficulté avec cette stratégie est que si une table a un pic d'activité
de mise à jour inattendu, elle pourrait grossir au point qu'un
de mise à jour inattendu, elle peut grossir au point qu'un
<command>VACUUM FULL</command> soit vraiment nécessaire pour récupérer
l'espace. L'utilisation du démon d'autovacuum mitige ce problème, puisque
l'espace. L'utilisation du démon d'autovacuum minore ce problème, puisque
le démon planifie les vacuum de façon dynamique, en réponse à l'activité
de mise à jour. Il est peu raisonnable de désactiver totalement le démon,
sauf si votre base a une activité extrêmement prévisible. Un compromis possible
sauf si l'activité de la base est extrêmement prévisible. Un compromis possible
est de régler les paramètres du démon afin qu'il ne réagisse qu'à une activité
exceptionnellement lourde de mise à jour, afin d'éviter seulement de perdre
exceptionnellement lourde de mise à jour, de sorte à éviter seulement de perdre
totalement le contrôle de la volumétrie, tout en laissant les
<command>VACUUM</command> planifiés faire le gros du travail quand la charge
est normale.
Expand All @@ -224,40 +223,40 @@
opérations de <command>VACUUM</command> plus fréquentes pour les tables
très impactées par des mises à jour, de la façon adéquate.
(Certaines installations avec énormément de mises à jour peuvent exécuter
des VACUUM toutes les quelques minutes.) Si vous avez plusieurs bases dans
un cluster, n'oubliez pas d'exécuter un <command>VACUUM</command> sur
des VACUUM toutes les quelques minutes.) Lorsqu'il y a plusieurs bases dans
un cluster, il faut penser à exécuter un <command>VACUUM</command> sur
chacune d'elles&nbsp;; le programme <xref
linkend="app-vacuumdb"/> pourrait être utile.
linkend="app-vacuumdb"/> peut être utile.
</para>

<tip>
<para>
Le <command>VACUUM</command> simple pourrait ne pas être satisfaisante
Le <command>VACUUM</command> simple peut ne pas suffire
quand une table contient un grand nombre d'enregistrements morts comme
conséquence d'une mise à jour ou suppression massive. Si vous avez une
table de ce genre, et que vous avez besoin de récupérer l'espace disque
gaspillé, vous aurez besoin d'utiliser <command>VACUUM FULL</command>,
conséquence d'une mise à jour ou suppression massive. Dans ce cas, s'il est
nécessaire de récupérer l'espace disque
gaspillé, <command>VACUUM FULL</command> peut être utilisé,
<xref linkend="sql-cluster"/> ou une des variantes de <xref
linkend="sql-altertable"/>.
Ces commandes écrivent une nouvelle copie de la table et créent de nouveaux
index pour elle. Toutes ces options nécessitent un verrou exclusif. Notez
qu'ils utilisent aussi temporairement un espace disque supplémentaire
approximativement égal à la taille de la table car les anciennes copies de
Ces commandes écrivent une nouvelle copie de la table et lui adjoignent de nouveaux
index. Toutes ces options nécessitent un verrou exclusif.
Elles utilisent aussi temporairement un espace disque supplémentaire,
approximativement égal à la taille de la table, car les anciennes copies de
la table et des index ne peuvent pas être supprimées avant la fin de
l'opération.
</para>
</tip>

<tip>
<para>
Si vous avez une table dont le contenu entier est supprimé sur une base périodique,
considérez de le faire avec <xref linkend="sql-truncate"/> plutôt qu'avec
<command>DELETE</command> suivi par un <command>VACUUM</command>.
Si le contenu d'une table est supprimé périodiquement, il est préférable
d'envisager l'utilisation de <xref linkend="sql-truncate"/>, plutôt que
<command>DELETE</command> suivi de <command>VACUUM</command>.
<command>TRUNCATE</command> supprime le contenu entier de la table
immédiatement sans nécessiter un <command>VACUUM</command> ou
immédiatement sans nécessiter de <command>VACUUM</command> ou
<command>VACUUM FULL</command> pour réclamer l'espace disque maintenant
inutilisé.
Le désavantage est que les sémantiques MCC stricts sont violées.
L'inconvient est la violation des sémantiques MCC strictes.
</para>
</tip>
</sect2>
Expand All @@ -277,25 +276,26 @@
<para>
L'optimiseur de requêtes de <productname>PostgreSQL</productname> s'appuie
sur des informations statistiques sur le contenu des tables dans l'optique
de générer des plans d'exécutions efficaces pour les requêtes. Ces
de produire des plans d'exécutions efficaces pour les requêtes. Ces
statistiques sont collectées par la commande <xref linkend="sql-analyze"/>, qui peut
être invoquée seule ou comme une option de <command>VACUUM</command>. Il est
important d'avoir des statistiques relativement à jour sans quoi des mauvais
choix dans les plans d'exécution pourraient pénaliser les performances de la
être invoquée seule ou comme option de <command>VACUUM</command>. Il est
important d'avoir des statistiques relativement à jour, ce qui permet d'éviter les
choix de mauvais plans d'exécution, pénalisant les performances de la
base.
</para>

<para>
Le démon d'autovacuum, si activé, va automatiquement exécuter des commandes
<command>ANALYZE</command> à chaque fois que le contenu d'une table aura
changé suffisamment. Toutefois, des administrateurs peuvent préférer se fier
changé suffisamment. Toutefois, un administrateur peut préférer se fier
à des opérations <command>ANALYZE</command> planifiées manuellement,
en particulier s'il est connu que l'activité de mise à jour de la table
n'aura pas d'impact sur les statistiques des colonnes <quote>intéressantes</quote>.
n'a pas d'impact sur les statistiques des colonnes <quote>intéressantes</quote>.
Le démon planifie des <command>ANALYZE</command> uniquement en fonction
du nombre d'enregistrements insérés, mis à jour ou supprimés&nbsp;
</para>

<!-- SAS:ICI -->
<para>
À l'instar du nettoyage pour récupérer l'espace, les statistiques doivent
être plus souvent collectées pour les tables intensément modifiées que pour
Expand Down

0 comments on commit e4b8f90

Please sign in to comment.