Changeset 337

Show
Ignore:
Timestamp:
07/20/06 16:29:47 (2 years ago)
Author:
sas
Message:

Journalisation

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/branches/bv803/divers/annotated_postgresql_conf.xml

    r336 r337  
    16051605</thead> 
    16061606 
    1607 <!-- ICI --> 
    16081607<tbody> 
    16091608 <row> 
    …… 
    16201619  </entry> 
    16211620  <entry> 
    1622   Has no effect until your next ANALYZE.  Generally not recommended as a way of 
    1623   improving statistics overall except for unusual databases; for one thing, 
    1624   collecting increased statistics on wide columns (large text, for example) can 
    1625   be burdensome enough to be counter-productive.  For a database which is 
    1626   almost entirely numerical, modest increases (to 100, for example) may have 
    1627   overall benefit; otherwise, try increasing statistics on specific columns. 
     1621  N'a aucun effet jusqu'au prochain ANALYZE. Il est en général déconseillé 
     1622  d'utiliser cette option pour améliorer l'ensemble des statistiques, sauf dans 
     1623  des cas particuliers&nbsp;; la collecte de statistiques sur de grandes 
     1624  colonnes (large text, par exemple) peut devenir excessive et donc 
     1625  contre-productive. Pour une base quasiment entièrement numérique, une 
     1626  augmentation modeste (jusqu'à 100, par exemple) peut être globalement 
     1627  positive&nbsp;; dans les autres cas, l'augmentation des statistiques sur des 
     1628  colonnes spécifiques peut être envisagée. 
    16281629  </entry> 
    16291630 </row> 
    16301631 <row> 
    16311632  <entry>from_collapse_limit</entry> 
    1632   <entry>0 to Int Max</entry> 
     1633  <entry>0 à Int Max</entry> 
    16331634  <entry>8</entry> 
    1634   <entry>Runtime</entry> 
    1635   <entry></entry> 
    1636   <entry> 
    1637   The planner will merge sub-queries into upper queries if the resulting FROM 
    1638   list would have no more than this many items. Smaller values reduce planning 
    1639   time but may yield inferior query plans. The default is 8. It is usually 
    1640   wise to keep this less than GEQO_THRESHOLD. 
    1641   </entry> 
    1642   <entry> 
    1643   As with many other settings in this section, you want only to change this for 
    1644   specific unfixable queries at runtime.  Decreasing it should force 
    1645   materialization of some subqueries if that is desired.  Most DBAs won't want 
    1646   to change it at all. 
     1635  <entry>Exécution</entry> 
     1636  <entry></entry> 
     1637  <entry> 
     1638  Le planificateur fusionne les sous-requêtes dans la requête principale si la 
     1639  liste FROM résultante ne contient pas plus de ce nombre d'items. Une valeur 
     1640  inférieure réduit le temps de planification, mais peut conduire à des plans de 
     1641  moindre qualité. 8 est la valeur par défaut. Il est préférable de conserver 
     1642  une valeur inférieure à GEQO_THRESHOLD. 
     1643  </entry> 
     1644  <entry> 
     1645  Comme pour la plupart des autres paramètres de cette section, il est 
     1646  préférable de ne changer sa valeur à l'exécution que pour certaines requêtes 
     1647  insolubles. 
    16471648  </entry> 
    16481649 </row> 
    16491650 <row> 
    16501651  <entry>join_collapse_limit</entry> 
    1651   <entry>1 to Int Max</entry> 
     1652  <entry>1 à Int Max</entry> 
    16521653  <entry>8</entry> 
    1653   <entry>Runtime</entry> 
    1654   <entry></entry> 
    1655   <entry> 
    1656   The planner will flatten explicit inner JOIN constructs into lists of FROM 
    1657   items whenever a list of no more than this many items would result. Usually 
    1658   this is set the same as FROM_COLLAPSE_LIMIT. Setting it to 1 prevents any 
    1659   flattening of inner JOINs, allowing explicit JOIN syntax to be used to 
    1660   control the join order. Intermediate values might be useful to trade off 
    1661   planning time against quality of plan. 
    1662   </entry> 
    1663   <entry> 
    1664   This option is designed for those of us who like writing our queries using 
    1665   explicit JOIN syntax (e.g. &#8220;a join b using (1) join c using (2)&#8221;), 
    1666   but would still like the planner to select the join order for best execution. 
    1667   Particularly, people switching from MS SQL Server will want to enable this 
    1668   option with a moderately high value, as that database does JOIN collapsing 
    1669   automatically. As above, keep this setting below geqo_threshold. 
     1654  <entry>Exécution</entry> 
     1655  <entry></entry> 
     1656  <entry> 
     1657  Le planificateur résout les jointures internes (<foreignphrase>inner 
     1658  JOIN</foreignphrase>) explicites en listes d'items FROM si 
     1659  la liste résulte ne contient pas plus de ce nombre d'items. En général, ce 
     1660  paramètre a la même valeur que FROM_COLLAPSE_LIMIT. Le positionner à 1 empêche 
     1661  toute résolution des jointures internes, ce qui permet d'utiliser la syntaxe 
     1662  JOIN explicitement pour contrôler l'ordre de la jointure. Les valeurs 
     1663  intermédiaires permettent d'arbitrer entre le temps de planification et la 
     1664  qualité du plan. 
     1665  </entry> 
     1666  <entry> 
     1667  Cette option est conçue pour ceux qui préfèrent écrire leurs requêtes en 
     1668  utilisant la syntaxe des jointures explicites (e.g. &laquo;&nbsp;a join b 
     1669  using (1) join c using (2)&nbsp;&raquo;), mais apprécient néanmoins que le 
     1670  planificateur choisisse le meilleur ordre de jointure. En particulier, les 
     1671  gens migrant de MS SQL Server peuvent utiliser ce paramètre en le positionnant 
     1672  à une valeur modérément élevée, puisque ce genre de bases trie les jointures 
     1673  automatiquement. Comme vu plus haut, ce paramètre est maintenu à une valeur 
     1674  inférieure à geqo_threshold. 
    16701675  </entry> 
    16711676 </row> 
    …… 
    16791684 
    16801685<sect1> 
    1681 <title>Logging and Debugging Options</title> 
     1686<title>Options de journalisation et de débogage</title> 
    16821687 
    16831688<sect2> 
    1684 <title>Where To Log</title> 
     1689<title>Où journaliser ?</title> 
    16851690 
    16861691<table> 
    …… 
    16891694<thead> 
    16901695 <row> 
    1691   <entry>Setting</entry> 
    1692   <entry>Range</entry> 
    1693   <entry>Default</entry> 
    1694   <entry>SET at</entry> 
     1696  <entry>Paramètre</entry> 
     1697  <entry>&Eacute;chelle</entry> 
     1698  <entry>Valeur par défaut</entry> 
     1699  <entry>Positionné au</entry> 
    16951700  <entry>-o</entry> 
    1696   <entry>Documentation says</entry> 
    1697   <entry>Comments</entry> 
     1701  <entry>Ce que dit la documentation</entry> 
     1702  <entry>Commentaires</entry> 
    16981703 </row> 
    16991704</thead> 
    …… 
    17041709  <entry>stderr, syslog, eventlog</entry> 
    17051710  <entry>stderr</entry> 
    1706   <entry>Startup</entry> 
    1707   <entry></entry> 
    1708   <entry> 
    1709   PostgreSQL supports several methods for logging server messages, including 
    1710   stderr and syslog. On Windows, eventlog is also supported. Set this option 
    1711   to a list of desired log destinations separated by commas. 
    1712   </entry> 
    1713   <entry> 
    1714   This is analogous to the old â&#8364;&#339;syslogâ&#8364;&#157; setting, but 
    1715   with the cryptic codes removed. Also supports the Win32 â&#8364;&#339;eventlogâ&#8364;&#157;. 
    1716   When setting up your server, it's important to decide how you want to log 
    1717   PostgreSQL messages: either to syslog, which is easier for overall system 
    1718   administration, or to a private PostgreSQL log, which is better for debugging 
    1719   database problems. Of course, you can log to both, but that's probably an 
    1720   excess of output. 
     1711  <entry>Démarrage</entry> 
     1712  <entry></entry> 
     1713  <entry> 
     1714  PostgreSQL accepte différentes méthodes de journalisation des messages du 
     1715  serveur, y compris stderr et syslog. Sous Windows, eventlog est également 
     1716  accepté. Ce paramètre est composé d'une liste, séparée par des virgules, de 
     1717  destinations souhaitées. 
     1718  </entry> 
     1719  <entry> 
     1720  Ce paramètre est analogue à l'ancien &laquo;&nbsp;syslog&nbsp;&raquo;, mais en 
     1721  plus compréhensible. Il supporte également 
     1722  l'&laquo;&nbsp;eventlog&nbsp;&raquo; Win32. Il est important de décider de la 
     1723  journalisation au moment de l'installation&nbsp;: soit avec syslog, ce qui 
     1724  facilite la gestion globale du système, soit vers un fichier propre à 
     1725  PostgreSQL, ce qui facilite le débogage du serveur de bases de données. Il est 
     1726  évidemment possible d'utiliser les deux, mais la sortie est certainement 
     1727  excessive. 
    17211728  </entry> 
    17221729 </row> 
    …… 
    17281735  <entry></entry> 
    17291736  <entry> 
    1730   This option allows messages sent to stderr to be captured and redirected into 
    1731   log files. This option, in combination with logging to stderr, is often more 
    1732   useful than logging to syslog, since some types of messages may not appear in 
    1733   syslog output (a common example is dynamic-linker failure messages). 
    1734   </entry> 
    1735   <entry> 
    1736   This is the new â&#8364;&#339;log rotationâ&#8364;&#157; feature. It also 
    1737   replaces the -l command line switch for pg_ctl, and/or command-line redirect. 
    1738   It is only applicable if you chose â&#8364;&#339;stderrâ&#8364;&#157; above, 
    1739   and the following 5 options only take effect if you choose this one. You can 
    1740   use redirect_stderr and turn rotation off in order to have create the same 
    1741   effect as the old -l option. 
     1737  Cette option permet de capturer les messages envoyés sur stderr et de les 
     1738  rediger vers les fichiers de journalisation. En combinaison avec la 
     1739  journalisation vers stderr est souvent plus utile que la journalisation vers 
     1740  syslog, puisque certains types de messages peuvent ne pas apparaître dans la 
     1741  sortie de syslog (les messages de défaillance de l'éditeur de liens dynamiques 
     1742  en est un bon exemple). 
     1743  </entry> 
     1744  <entry> 
     1745  C'est la nouvelle fonctionnalité de &laquo;&nbsp;log rotation&nbsp;&raquo;. 
     1746  Elle remplace également l'option -l de la ligne de commande de pg_ctl, et/ou 
     1747  la redirection de ligne de commande. Elle ne s'applique que lorsque 
     1748  &laquo;&nbsp;stderr&nbsp;&raquo; est choisi plus haut. Les cinq options qui 
     1749  suivent ne s'appliquent que si cette option est positionnée. Le comportement 
     1750  de l'ancienne option -l peut être reproduit avec redirect_stderr et en 
     1751  annulant la rotation. 
    17421752  </entry> 
    17431753 </row> 
    17441754 <row> 
    17451755  <entry>log_directory</entry> 
    1746   <entry>directory</entry> 
     1756  <entry>répertoire</entry> 
    17471757  <entry>pg_log</entry> 
    1748   <entry>Startup</entry> 
    1749   <entry></entry> 
    1750   <entry> 
    1751   When redirect_stderr is enabled, this option determines the directory in 
    1752   which log files will be created. It may be specified as an absolute path, 
    1753   or relative to the cluster data directory. 
    1754   </entry> 
    1755   <entry> 
    1756   Defaults to a â&#8364;&#339;pg_logâ&#8364;&#157; directory in your PGDATA, 
    1757   which is probably not a wise choice if you have other disks/arrays available. 
    1758   /var/pg_log is popular. 
     1758  <entry>Démarrage</entry> 
     1759  <entry></entry> 
     1760  <entry> 
     1761  Lorsque redirect_stderr est activé, cette option précise le répertoire de 
     1762  création des journaux. Il peut être précisé comme un chemin absolu, ou relatif 
     1763  au répertoire de données du cluster. 
     1764  </entry> 
     1765  <entry> 
     1766  Par défaut, il s'agit du répertoire &laquo;&nbsp;pg_log&nbsp;&raquo; dans 
     1767  PGDATA, ce qui n'est probablement pas le meilleur choix lorsque d'autres 
     1768  disques/baies sont disponibles. /var/pg_log est fréquemment rencontré. 
    17591769  </entry> 
    17601770 </row> 
    …… 
    17631773  <entry>special</entry> 
    17641774  <entry>postgresql-%Y-%m-%d_%H%M%S.log</entry> 
    1765   <entry>Startup</entry> 
    1766   <entry></entry> 
    1767   <entry> 
    1768   When redirect_stderr is enabled, this option sets the file names of the 
    1769   created log files. The value is treated as a strftime pattern, so 
    1770   %-escapes can be used to specify time-varying file names. If no 
    1771   %-escapes are present, PostgreSQL will append the epoch of the new log file's 
    1772   open time. For example, if log_filename were server_log, then the chosen file 
     1775  <entry>Démarrage</entry> 
     1776  <entry></entry> 
     1777  <entry> 
     1778  Lorsque redirect_stderr est activé, cette option définit les noms des 
     1779  journaux créés. La valeur est traitée comme un motif strftime, ce qui permet 
     1780  d'utiliser les caractères d'échappement % pour préciser des noms dépendant du 
     1781  temps. En l'absence de caractères d'échappement, PostgreSQL ajoute l'époque 
     1782  d'ouverture du nouveau fichier. Ainsi, dans le cas où log_filename est 
     1783  server_log, le nom de fichier est server_log.1093827753 pour un journal 
     1784  démarrant à 19:02:33 le dimanche 29 août 2004 (MST). 
    17731785  name would be server_log.1093827753 for a log starting at Sun Aug 29 19:02:33 
    1774   2004 MST.</entry> 
    1775   <entry> 
    1776   File name for each rotational log segment, with escapes. The default should 
    1777   suit most DBAs.  If your logs never go over size, it can be simpler to 
    1778   include only the date.  Another possible variation is to have the log record 
    1779   only the hour, or only the day of the week, in order to prevent getting more 
    1780   than a certain number of logs.  See log_truncate below. 
     1786  </entry> 
     1787  <entry> 
     1788  Nom de fichier pour chaque segment de journal rotationnel, avec les caractères 
     1789  d'échappement. La valeur par défaut peut convenir à tout DBA. Si les journaux 
     1790  ne grandissent pas trop, il peut être plus simple de n'ajouter que la date. 
     1791  Une autre possibilité consiste à n'utiliser que l'heure ou le jour de la 
     1792  semaine pour restreindre le nombre de journaux. Voir log_truncate plus bas. 
    17811793  </entry> 
    17821794 </row> 
    17831795 <row> 
    17841796  <entry>log_rotation_age</entry> 
    1785   <entry>0 to Int Max</entry> 
     1797  <entry>0 à Int Max</entry> 
    17861798  <entry>1440</entry> 
    1787   <entry>Startup</entry> 
    1788   <entry></entry> 
    1789   <entry> 
    1790   When redirect_stderr is enabled, this option determines the maximum lifetime 
    1791   of an individual log file. After this many minutes have elapsed, a new log 
    1792   file will be created. Set to zero to disable time-based creation of new log 
     1799  <entry>Démarrage</entry> 
     1800  <entry></entry> 
     1801  <entry> 
     1802  lorsque redirect_stderr est activé, cette option précise la durée de vie 
     1803  maximale d'un journal individuel. Après ce temps (en minutes), un nouveau 
     1804  fichier est créé. La positionner à zéro désactive la création de nouveaux journaux en 
     1805  fonction du temps. 
    17931806  files. 
    17941807  </entry> 
    17951808  <entry> 
    1796   The default (24 hours) is suitable for most installations. 
     1809  La valeur par défaut (24 heure) convient pour la plupart des installations. 
    17971810  </entry> 
    17981811 </row> 
    17991812 <row> 
    18001813  <entry>log_rotation_size</entry> 
    1801   <entry>0 to Int Max</entry> 
     1814  <entry>0 à Int Max</entry> 
    18021815  <entry>10240</entry> 
    1803   <entry>Startup</entry> 
    1804   <entry></entry> 
    1805   <entry> 
    1806   When redirect_stderr is enabled, this option determines the maximum size of 
    1807   an individual log file. After this many kilobytes have been emitted into a 
    1808   log file, a new log file will be created. Set to zero to disable size-based 
    1809   creation of new log files. 
    1810   </entry> 
    1811   <entry> 
    1812   The default (10MB) is suitable for most installations. 
     1816  <entry>Démarrage</entry> 
     1817  <entry></entry> 
     1818  <entry> 
     1819  Lorsque redirect_stderr est activé, cette option précise la taille maximale 
     1820  d'un journal individuel. Lorsqu'il atteint cette taille (en kilooctets), un 
     1821  nouveau fichier est créé. La positionner à zéro désactive la création de 
     1822  fichiers en fonction de la taille. 
     1823  </entry> 
     1824  <entry> 
     1825  la valeur par dafaut (10 Mo) convient pour la plupart des installations. 
    18131826  </entry> 
    18141827 </row> 
    …… 
    18171830  <entry>True, False</entry> 
    18181831  <entry>False</entry> 
    1819   <entry>Startup</entry> 
    1820   <entry></entry> 
    1821   <entry> 
    1822   When redirect_stderr is enabled, this option will cause PostgreSQL to truncate 
    1823   (overwrite), rather than append to, any existing log file of the same name. 
    1824   However, truncation will occur only when a new file is being opened due to 
    1825   time-based rotation, not during server startup or size-based rotation. When 
    1826   false, pre-existing files will be appended to in all cases. For example, 
    1827   using this option in combination with a log_filename like postgresql-%H.log 
    1828   would result in generating twenty-four hourly log files and then cyclically 
    1829   overwriting them. 
    1830   </entry> 
    1831   <entry> 
    1832   This setting can be combined with log_filename, above, to create a 7-day or 
    1833   24-hour (or 60-minute, for that matter) continuous replacement of logs. 
     1832  <entry>Démarrage</entry> 
     1833  <entry></entry> 
     1834  <entry> 
     1835  Lorsque redirect_stderr est activé, cette option impose à PostgreSQL de 
     1836  tronquer (réécrire), plutôt qu'ajouter, tout journal du même nom. Néanmoins, 
     1837  la troncature n'intervient que lorsqu'un nouveau fichier est ouvert par 
     1838  rotation fondée sur le temps, pas au démarrage ou lors d'une rotation fondée 
     1839  sur la taille du fichier. Lorsqu'elle est positionnée à False, l'adjonction 
     1840  est faite au fichier existant, dans tous les cas. Ainsi, utiliser cette option 
     1841  en combinaison avec un log_filename tel que postgresql-%H.log consiste à 
     1842  engendrer des journaux de 24 heures et à les réécrire cycliquement. 
     1843  </entry> 
     1844  <entry> 
     1845  Ce paramètre peut être combiné à log_filename, plus haut, pour créer un 
     1846  remplacement continu de 7 jours, 24 heures (ou 60 minutes) des journaux. 
    18341847  </entry> 
    18351848 </row> 
    …… 
    18391852  <entry>LOCAL0</entry> 
    18401853  <entry></entry> 
    1841   <entry>Startup</entry> 
    1842   <entry> 
    1843   When logging to syslog is enabled, this option determines the syslog "facility" 
    1844   to be used. You may choose from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, 
    1845   LOCAL6, LOCAL7; the default is LOCAL0. See also the documentation of your 
    1846   system's syslog daemon. 
    1847   </entry> 
    1848   <entry> 
    1849   No recommendations. 
     1854  <entry>Démarrage</entry> 
     1855  <entry> 
     1856  Lorsque la journalisation utilise syslog, cette option précise la 
     1857  &laquo;&nbsp;fonction&nbsp;&raquo; de syslog à utiliser. LOCAL0, LOCAL1, 
     1858  LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6 et LOCAL7 sont possibles. La valeur par 
     1859  défaut est LOCAL0. Plus d'informations dans la documentation du daemon syslog 
     1860  du système. 
     1861  </entry> 
     1862  <entry> 
     1863  Pas de recommendation particulière. 
    18501864  </entry> 
    18511865 </row> 
    …… 
    18541868  <entry></entry> 
    18551869  <entry>postgres</entry> 
    1856   <entry>Startup</entry> 
    1857   <entry></entry> 
    1858   <entry> 
    1859   When logging to syslog is enabled, this option determines the program name 
    1860   used to identify PostgreSQL messages in syslog logs. The default is postgres. 
    1861   </entry> 
    1862   <entry> 
    1863   Those running multiple versions of PostgreSQL on the same machine will want 
    1864   to remember to change this string to indicate which server. 
     1870  <entry>Démarrage</entry> 
     1871  <entry></entry> 
     1872  <entry> 
     1873  Lorsque la journalisation utilise syslog, cette option précise le nom à 
     1874  utiliser pour identifier les messages de PostgreSQL dans le journal. Par 
     1875  défaut, il s'agit de <i>postgres</i>. 
     1876  </entry> 
     1877  <entry> 
     1878  Lorsque plusieurs instances de PostgreSQL tournent sur le même serveur, la 
     1879  personnalisation de cette chaîne permet d'identifier les serveurs. 
    18651880  </entry> 
    18661881 </row> 
    …… 
    18711886</sect2> 
    18721887 
     1888<!-- ICI --> 
    18731889<sect2> 
    18741890<title>When to Log</title>