root/traduc/trunk/postgresql/diskusage.xml

<?xml version="1.0" encoding="ISO-8859-15"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->
<!-- SAS : 20060511, PG824 -->

<chapter id="diskusage">
 <title>Surveiller l'utilisation des disques</title>

 <para>
  Ce chapitre explique comment surveiller l'utilisation que fait
  <productname>PostgreSQL</productname> des disques.
  
 </para>

 <sect1 id="disk-usage">
  <title>Déterminer l'utilisation des disques</title>

  <indexterm zone="disk-usage">
   <primary>utilisation des disques</primary>
  </indexterm>

  <para>
   Chaque table possède un fichier principal dans lequel la majorité
   des données sont stockées. Si la table contient des colonnes pouvant recevoir 
   des valeurs étendues, il existe aussi un fichier <acronym>TOAST</acronym> associé à la
   table. Ce fichier permet de stocker les valeurs trop larges pour tenir
   dans la table principale (voir la <xref linkend="storage-toast"/>).
   Si la table <acronym>TOAST</acronym> existe, un index lui est associé.
   Des index peuvent également être associés à la table de base.
   Chaque table ou index est stocké dans un fichier distinct &mdash;
   ou plusieurs si la taille du fichier dépasse 1&nbsp;Go.
   Les conventions de nommage de ces fichiers sont décrites dans la
   <xref linkend="storage-file-layout"/>.
  </para>

  <para>
   L'espace disque peut être surveillé de trois façons différentes&nbsp;:
   depuis <application>psql</application> en utilisant les informations retournées par
   <command>VACUUM</command>, depuis <application>psql</application> avec les outils de 
   <filename>contrib/dbsize</filename> et en ligne de commande avec les outils de
   <filename>contrib/oid2name</filename>.
   </para>
   <para>
   Les fonctions SQL sont les plus faciles à utiliser. Elles rapportent des
   informations concernant les tables, les tables avec index et stockage de
   valeurs étendues (TOAST), les bases de données et les
   <foreignphrase>tablespaces</foreignphrase>.
  </para>

  <para>
   L'utilisation de <application>psql</application> sur une base de données 
   récemment &laquo;&nbsp;nettoyée&nbsp;&raquo; (<command>VACUUM</command>) ou
   &laquo;&nbsp;analysée&nbsp;&raquo; (<command>ANALYZE</command>) permet de lancer des
   requêtes pour connaître l'occupation disque d'une table&nbsp;:
<programlisting>SELECT relfilenode, relpages FROM pg_class WHERE relname = 'customer';

 relfilenode | relpages 
-------------+----------
       16806 |       60
(1 ligne)</programlisting>
   Chaque page utilise typiquement 8&nbsp;Ko d'espace disque.
  </para>
  
  <para>
   <structfield>relpages</structfield> n'est mis à jour que par
   les commandes <command>VACUUM</command>, <command>ANALYZE</command> et
   par quelques commandes de définition de données (DDL, Data Definition
   Language), telles que <command>CREATE INDEX</command>. La valeur de
   <structfield>relfilenode</structfield> est intéressante pour l'examen direct du fichier
   de table.
  </para>

  <para>
   Pour connaître l'espace disque utilisé par les tables 
   <acronym>TOAST</acronym>, on utilise une requête similaire à la suivante&nbsp;:
<programlisting>SELECT relname, relpages
    FROM pg_class,
         (SELECT reltoastrelid FROM pg_class
          WHERE relname = 'customer') ss
    WHERE oid = ss.reltoastrelid
       OR oid = (SELECT reltoastidxid FROM pg_class
                 WHERE oid = ss.reltoastrelid)
    ORDER BY relname;

       relname        | relpages 
----------------------+----------
 pg_toast_16806       |        0
 pg_toast_16806_index |        1</programlisting>
  </para>

  <para>
   On peut aussi facilement afficher la taille des index&nbsp;:
<programlisting>SELECT c2.relname, c2.relpages
    FROM pg_class c, pg_class c2, pg_index i
    WHERE c.relname = 'customer'
        AND c.oid = i.indrelid
        AND c2.oid = i.indexrelid
        ORDER BY c2.relname;

       relname        | relpages 
----------------------+----------
 customer_id_indexdex |       26</programlisting>
  </para>

  <para>
   Les tables et les index les plus volumineux sont repérés à l'aide de la requête
   suivante&nbsp;:
<programlisting>SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;

       relname        | relpages 
----------------------+----------
 bigtable             |     3290
 customer             |     3144</programlisting>
  </para>

  <para>
   L'utilitaire <filename>contrib/oid2name</filename> permet également de connaître
   l'utilisation de l'espace disque. Des exemples d'utilisation sont repris dans 
   le fichier <filename>README.oid2name</filename> situé dans le répertoire
   de l'utilitaire. On y trouve notamment un script permettant de connaître l'utilisation
   de l'espace disque par base de données.
  </para>
 </sect1>

 <sect1 id="disk-full">
  <title>Panne pour disque saturé</title>

  <para>
   La tâche la plus importante d'un administrateur de base de données, 
   en ce qui concerne la surveillance des disques, est de s'assurer que les
   disques n'arrivent pas à saturation. Un disque de données plein ne corrompt pas
   les données mais peut empêcher toute activité. S'il s'agit
   du disque contenant les fichier WAL, une alerte
   PANIC et un arrêt du serveur peuvent survenir.
  </para>

  <para>
   S'il n'est pas possible de libérer de la place sur le disque, il faut
   envisager le déplacement de quelques fichiers vers d'autres systèmes de
   fichiers à l'aide des <foreignphrase>tablespaces</foreignphrase>. Voir la
   <xref linkend="manage-ag-tablespaces"/> pour plus d'informations.
  </para>

  <tip>
   <para>
   Certains systèmes de fichiers réagissent mal à proximité des limites de remplissage.
   Il est donc préférable de ne pas attendre ce moment pour réagir.
   </para>
  </tip>

  <para>
   Si le système supporte les quotas disque par utilisateur, la
   base de données est alors soumise au quota de
   l'utilisateur qui exécute le serveur de base de données. Dépasser ce
   quota a les mêmes conséquences néfastes qu'un disque plein.
  </para>
 </sect1>
</chapter>