IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Maîtriser l'interface ADR sous Oracle 11g

Date de publication : 09/11/2009 , Date de mise à jour : 09/11/2009

Par Laurent Léturgez (http://laurent-leturgez.developpez.com/)
 Laurent Léturgez (Page Personnelle de Laurent)
 


               Version PDF (Miroir)

I. Evolution des diagnostics
II. Architecture de l'ADR
III. L'interpréteur de commandes ADR : ADRCI
III-A. Présentation
III-B. Principales commandes :
III-B-1. Configuration
III-B-1-a. SET CONTROL
III-B-1-b. SET EDITOR
III-B-1-c. SET ECHO
III-B-1-d. SET HOME(S)
III-B-1-e. SET HOMEPATH
III-B-1-f. SET BASE
III-B-1-g. Configuration du listener dans ADR
III-B-2. Analyse et monitoring
III-B-2-a. SHOW ALERT
III-B-2-b. SHOW TRACEFILE
III-B-2-c. SHOW TRACE
III-B-3. Packaging d'incidents pour le support
III-B-3-a. IPS CREATE PACKAGE
III-B-3-b. IPS ADD FILE
III-B-3-c. IPS ADD INCIDENT
III-B-3-d. IPS SHOW FILES
III-B-3-e. IPS GENERATE
III-B-4. Maintenance
IV. Conclusion
V. Liens


I. Evolution des diagnostics

Jusqu'en Oracle 10g, les diagnostics étaient principalement réalisés par le DBA à partir de fichiers de logs (alert.log, logs des backgroung process), de trace utilisateurs, de core dumps etc.

Ces fichiers de logs étaient générés dans un répertoire pointé par les paramètres suivants :
other

- BACKGROUND_DUMP_DEST
- USER_DUMP_DEST
- CORE_DUMP_DEST
...
A cela, il fallait ajouter les fichiers de log et de trace du listener. Le cas échéant, les logs de l'instance ASM, du clusterWare CRS etc.

En plus de cela, les architectures étaient plus ou moins normalisées ... en fonction de nombreux paramètres (Architecte technique, DBA, client, plate forme, volonté des uns et des autres, etc.)

Évidemment, tout cela ne simplifiait pas la tâche du support Oracle lors de la résolution d'incidents en allongeant leurs durées, notamment lors des premiers échanges entre le client et le support.

Avec Oracle 11g, la nouvelle version intègre un changement majeur dans l'organisation des diagnostics. Désormais, les diagnostics sont centralisés par serveur, ils sont normalisés, et organisés de manière uniforme. Cette nouvelle organisation se présente donc sous le nom d'ADR : Automatic Diagnostic Repository dans laquelle nous retrouverons : les fichiers de logs, de trace, les alert.log, les rapports d'incidents etc.

De plus, il est à noter le changement d'organisation majeur des fichiers de log (alert.log, listener.log etc.). Ceux ci sont désormais au format XML qui leur permettra d'être lus plus facilement par des outils fourni dans ADRCI (voir plus bas).


II. Architecture de l'ADR

ADR est basé sur une architecture de répertoires normalisés. Comme pour la norme OFA, il dispose d'une base : ADR_BASE. Cette base sera le point d'entrée de tous les diagnostics émis par les produits d'un serveur. On y retrouvera les diagnostics des instances de bases de données, de l'instance ASM, du CRS (avant 11gR2), du listener (selon la configuration du listener) etc.

Au sein de cette Base ADR, on va retrouver des "ADR Homes" qui vont contenir les diagnostics d'un composant spécifique hébergé sur le serveur : une instance de base de données, une instance ASM ou le listener par exemple.

Pour une base de données (ou d'une instance ASM), on peut obtenir les informations de diagnostics avec la requête suivante :
other

SQL> select * from gv$diag_info;
  INST_ID NAME                           VALUE
---------- ------------------------------ -------------------------------------------------------------------------------
        1 Diag Enabled                   TRUE
        1 ADR Base                       /u01/app/oracle-product/11.1.0/db_1
        1 ADR Home                       /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM
        1 Diag Trace                     /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/trace
        1 Diag Alert                     /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/alert
        1 Diag Incident                  /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/incident
        1 Diag Cdump                     /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/cdump
        1 Health Monitor                 /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/hm
        1 Default Trace File             /u01/app/oracle-product/11.1.0/db_1/diag/asm/+asm/+ASM/trace/+ASM_ora_31579.trc
        1 Active Problem Count           0
        1 Active Incident Count          0
En schématisant, l'architecture ADR peut-être représentée comme suit :
other

<ADR_BASE>
|
|
\_ diag
    \_ rdbms
    |    \_ <DB_NAME>
    |          \_ SID (<ADR_HOME>)
    |                 \_ alert
    |                 \_ cdump
    |                 \_ hm
    |                 \_ incident
    |                 \_ incpkg
    |                 \_ trace
    |
    \_ asm
    |    \_ +asm
    |         \_ SID (<ADR_HOME> 
    |             \_ ./.
    \_ crs 
         \_ ./. 
./. 
Pour configurer une instance, il existe un nouveau paramètre "DIAGNOSTIC_DEST" qui paramètre la base ADR. A partir de cela, comme c'est normalisé, oracle saura se débrouiller pour déposer ses logs et traces


III. L'interpréteur de commandes ADR : ADRCI


III-A. Présentation

ADR a été implémenté dans le but de simplifier et de normaliser la gestion des diagnostics. En 10g, nombre de DBA avait leur "méthode" pour gérer ces fichiers de diagnostics, leur purge, leur rotation, et la création de "package" pour le support, étaient dépendantes de celui qui générait ces packages.

C'est pour ces raisons qu'oracle a implémenté une interface permettant de réaliser tout cela, de manière normalisée.

Cette interface se nomme ADRCI (ADR Command Interface). Elle se pilote via un binaire situé dans $ORACLE_HOME/bin/adrci.

Cette interface peut être utilisée, comme lsnrctl, de manière interactive ou en mode batch :

 Exemple d'utilisation d'ADRCI en mode interactif :
other

$ adrci
ADRCI: Release 11.1.0.6.0 - Beta on Mon Jan 12 16:39:38 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/rdbms/dbtest/dbtest
adrci> exit
Exemple d'utilisation d'ADRCI en mode batch :
other

$ adrci exec="SHOW HOMES"
ADR Homes:
diag/asm/+asm/+ASM
diag/rdbms/dbtest/dbtest

III-B. Principales commandes :

Dans cette partie, nous allons voir les principales commandes de l'interface ADRCI. Par souci de lisibilité, elles ne seront pas toutes expliquées. Pour plus d'informations sur ces commandes, celles ci sont déclinées dans le "book" Utilities de la documentation Oracle.

Avant de commencer, il existe une commande HELP qui permet d'obtenir de l'aide sur chacune des commandes. Les commandes suivantes donnent la liste des commandes disponibles :

  • HELP : donne la liste des commandes standards
  • HELP EXTENTED : donne la liste des commandes étendues
  • HELP IPS : donne la liste des commandes de génération des packages pour le support.

III-B-1. Configuration

Les commandes permettant de configurer ADR sont généralement des commandes SET complétées d'un paramètre.


III-B-1-a. SET CONTROL

La commande SET CONTROL permet de définir les politiques standard de purge. Il existe deux politiques :

  • une politique courte durée dénommée SHORTP_POLICY. Cette politique est appliquée aux fichiers et aux dumps des incidents.
  • une politique longue durée dénommée LONGP_POLICY. Cette politique est appliquée aux métadonnées des incidents.
La commande SET CONTROL permet de définir le nombre d'heures de conservation associé à ces politiques.

Exemple :
other

adrci> set control (SHORTP_POLICY=1);
adrci> set control (SHORTP_POLICY=2, LONGP_POLICY=100);
Le contrôle de la prise en compte de ces paramètres se fait avec la commande SHOW CONTROL. Cette commande, en plus des politiques donne différentes informations de configuration d'ADR.

NB : On doit spécifier une home ADR pour lancer cette commande


III-B-1-b. SET EDITOR

Cette commande définit l'éditeur utilisé :
other

adrci> set editor vi

III-B-1-c. SET ECHO

Cette commande définit l'affichage ou non des sorties de commandes lors de spool ou d'exécution de script.
other

adrci> set echo off

III-B-1-d. SET HOME(S)

Cette commande permet de sélectionner une ou plusieurs home ADR de travail.
other

adrci> SET HOME diag/rdbms/dbtest/dbtest
adrci> SET HOMES diag/asm/+asm/+ASM, diag/rdbms/dbtest/dbtest
Les commandes SHOW HOME et SHOW HOMES permettent de visualiser la ou les home(s) ADR de travail actuelle(s).


III-B-1-e. SET HOMEPATH

Cette commande va définir un chemin comme une home ADR :
other

adrci> SET HOMEPATH diag/rdbms/dbtest/dbtest

III-B-1-f. SET BASE

Permet de configurer une base qui ne serait pas celle par défaut. Cette commande permet de scanner les homes disponibles dans cette base.
other

adrci> SET BASE /u01/app/oracle

III-B-1-g. Configuration du listener dans ADR

Par défaut, un listener en logging ou en trace va générer ses fichiers dans DIAG.

Le logging dans DIAG est conditionné par le paramètre du listener DIAG_ADR_ENABLED_. Ce paramètre est, par défaut, positionné à ON. Si on veut désactiver cela, et revenir à une journalisation "non-ADR", il faut le passer à OFF.

Pour ce qui concerne la mise en trace du listener, les paramètres restent les mêmes (TRACE_LEVEL_, TRACE_DIRECTORY_, TRACE_FILE_ etc.).

Cependant, si DIAG_ADR_ENABLED_ est positionné à ON, et qu'un niveau de trace est défini (USER, ADMIN, SUPPORT), alors le fichier de trace sera positionné dans DIAG.

A partir de la version 11gR2, on peut modifier la BASE ADR pour le listener.

Pour cela, il faut positionner le paramètre ADR_BASE_ dans le fichier listener.ora pour modifier cela.

Exemple pour un listener nommé LISTENER1522 :
other

ADR_BASE_LISTENER1522 = /u01/app/oracle/grid/

III-B-2. Analyse et monitoring


III-B-2-a. SHOW ALERT

Une des commandes des plus importantes dans adrci est la commande SHOW ALERT.

Cette commande va permettre d'exploiter le fichier alert.log version 11g au format XML (elle n'exploite pas l'ancien format qui subsiste pour compatibilité ascendante si le paramètre BACKGROUND_DUMP_DEST est renseigné). Cette commande va également permettre l'exploitation des autres fichiers de trace, par exemple, le fichier de log du listener (qui était bien complexe à exploiter auparavant)

Le prototypage de la commande est le suivant :
other

SHOW ALERT [-p <predicate_string>]  [-term] [ [-tail [num] [-f]] | [-file <alert_file_name>] ]
  • L'option -p permet, via un prédicat de recherche, filtrer le contenu de sortie
  • L'option -term, permet d'envoyer la sortie vers le terminal. Si cette option n'est pas spécifiée, l'ouverture se fera par l'éditeur mentionné via la commande SET EDITOR
  • L'option -tail, comme sous unix, permet d'obtenir les derniers enregistrements de ce fichier. Avec le complément d'option -f, le rafraichissement se fait à la volée. Pour terminer cet affichage à la volée, il faut réaliser un "Ctrl+C".
  • L'option -file, permet de spécifier un fichier d'alert (au format brut et non XML). Cette option est mutuellement exclusive de l'option tail
NB : La normalisation de cette commande au sein d'ADRCI permettra l'implémentation des commandes unix "grep" (option -p) et "tail" (option -tail) sous Windows.

Exemple 1 : obtenir les cinq derniers événements du fichier d'alerte de l'instance ASM :
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/base/sid

adrci> set homepath diag/asm/+asm/+ASM

adrci> show home
ADR Homes:
diag/asm/+asm/+ASM

adrci> show alert -tail 5
Exemple 2 : Obtenir les deux derniers événements de la log du listener
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/base/sid

adrci> set homepath diag/tnslsnr/linux1/listener
adrci> show alert -tail 2
Exemple 3 : Afficher les dernières erreurs ORA-19815 (Flash Recovery area trop petite)
other

ADR base = "/home/oracle"
adrci> show homes
ADR Homes:
diag/rdbms/dbtest/dbtest

adrci> show alert -p "MESSAGE_TEXT LIKE '%ORA-19815%'" -term

ADR home = /home/oracle/diag/rdbms/dbtest/dbtest:
*************************************************************************
2009-01-14 15:12:28.549000 +01:00
Errors in file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_mmon_5486.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 104857600 bytes is 100.00% used, and has 0 remaining bytes available.
2009-01-14 15:13:35.383000 +01:00
Errors in file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_arc2_5782.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 104857600 bytes is 100.00% used, and has 0 remaining bytes available.
 Errors in file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_arc3_5784.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 10485
7600 bytes is 100.00% used, and has 0 remaining bytes available.2009-01-14 15:15:10.870000 +01:00
Errors in file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_ora_15762.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 524288000 bytes is 100.00% used, and has 0 remaining bytes available.
2009-01-14 15:15:17.978000 +01:00
Errors in file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_mmon_5486.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 88.93% used, and has 237809152 remaining bytes available.

III-B-2-b. SHOW TRACEFILE

Cette commande permet de visualiser les fichiers de trace générés pour une home ou plusieurs home ADR :
other

ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/dbtest/dbtest

adrci> show tracefile
    diag/asm/+asm/+ASM/trace/+ASM_ora_1796.trc
    diag/asm/+asm/+ASM/trace/+ASM_gmon_1833.trc
    diag/asm/+asm/+ASM/trace/+ASM_rbal_1831.trc
    diag/asm/+asm/+ASM/trace/alert_+ASM.log
    diag/asm/+asm/+ASM/trace/+ASM_vktm_1803.trc
    diag/tnslsnr/linux1/listener/trace/listener.log
    diag/tnslsnr/linux1/listener/trace/ora_2419_47162629456496.trc
    diag/rdbms/dbtest/dbtest/trace/dbtest_ora_21674.trc
    diag/rdbms/dbtest/dbtest/trace/dbtest_arc2_5782.trc
    diag/rdbms/dbtest/dbtest/trace/dbtest_ora_13896.trc
    diag/rdbms/dbtest/dbtest/trace/dbtest_m000_15784.trc
La commande show tracefile permet également de filtrer les traces associés à un processus d'arrière plan, par exemple :
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/dbtest/dbtest

adrci> show tracefile %arc0%
    diag/rdbms/dbtest/dbtest/trace/dbtest_arc0_5778.trc
La visualisation de ces fichiers peut se faire avec un éditeur de texte de manière externe. ADRCI dispose également de la commande HOST permettant de débrayer sur le shell système. On peut également utiliser la commande SHOW TRACE.


III-B-2-c. SHOW TRACE

Cette commande permet d'afficher un fichier de trace. Soit l'affichage se fait par défaut dans l'éditeur configuré dans adrci, soit dans le terminal avec l'option -term. Il existe également un certain nombre d'options permettant de filtrer certaines données (plus d'infos dans la commande HELP SHOW TRACE)
other

adrci> show tracefile %pmon%
    diag/rdbms/dbtest/dbtest/trace/dbtest_pmon_5458.trc
adrci> show trace dbtest_pmon_5458.trc
adrci> show trace dbtest_pmon_5458.trc -term

III-B-3. Packaging d'incidents pour le support

ADR permet maintenant de détecter problèmes et incidents, et de réaliser des packages pour le support. Ces packages vont contenir, dans une archive ZIP, l'ensemble des fichiers nécessaires au support pour analyser le problème.

Pour commencer, nous allons simuler une erreur interne Oracle avec le code PL/SQL suivant :
other

declare
 ora600 exception;
 pragma exception_init(ora600,-600);
begin
 raise ora600;
end;
/
La visualisation de problème se fait avec la commande SHOW PROBLEM.

La visualisation d'incident se fait avec la commande SHOW INCIDENT.

La relation qui existe entre problème et incident est qu'un PROBLEM peut recenser plusieurs INCIDENTs.

Une fois les incidents identifiés, on utilise IPS (Incident Packaging Service). IPS est integré à ADRCI.

Pour créer un package, cela se fait en plusieurs étapes :

  • créer l'enveloppe du package IPS
  • ajouter des fichiers, des incidents à ce package
  • réaliser le "packaging" pour envoyer l'archive au support Oracle

III-B-3-a. IPS CREATE PACKAGE

Cette commande sert à créer un package IPS. Elle nécessite d'avoir sélectionné la HOME ADR sur laquelle l'incident est référencé.
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/dbtest/dbtest
adrci> set homepath diag/rdbms/dbtest/dbtest
adrci> show incident

ADR Home = /HOME/oracle/diag/rdbms/dbtest/dbtest:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                     CREATE_TIME
-------------------- ------------------------------- ----------------------------------------
21789                ORA 7445                        2009-01-15 14:51:14.061784 +01:00
21788                ORA 600                         2009-01-15 11:55:37.883993 +01:00
21787                ORA 700 [kgerev1]               2009-01-15 11:55:36.292663 +01:00
3 rows fetched
A ce stade, on peut créer un package vide. Il faut veiller à bien noter l'identifiant de ce package qui nous servira durant le processus.
other

adrci> ips create package;
Created package 3 without any contents, correlation level typical
  • On peut également créer un package à partir d'un problème. Tous les incidents référencés dans ce problème seront inclus dans ce package :
other

adrci> ips create package problem 2;
Created package 6 based on problem id 2, correlation level typical
  •  On peut également créer un package contenant déjà un incident :
other

adrci> ips create package incident 21788
Created package 4 based on incident id 21788, correlation level typical

III-B-3-b. IPS ADD FILE

On peut ensuite ajouter d'autres fichiers à ce package :
other

adrci> show tracefile %pmon%
    diag/rdbms/dbtest/dbtest/trace/dbtest_pmon_5458.trc
adrci> ips add file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_pmon_5458.trc package 4
Added file /home/oracle/diag/rdbms/dbtest/dbtest/trace/dbtest_pmon_5458.trc to package 4

III-B-3-c. IPS ADD INCIDENT

On peut également ajouter un incident au package avec la commande :
other

adrci> ips add incident 21787 package 4
Added incident 21787 to package 4

III-B-3-d. IPS SHOW FILES

Le contenu du package en cours peut être visualisé avec la commande IPS SHOW FILES :
other

adrci> ips show files package 4

III-B-3-e. IPS GENERATE

Une fois le package définit, on peut générer l'archive qui sera transmise au support :
other

adrci> ips generate package 4 in /var/tmp
Generated package 4 in file /var/tmp/ORA600_20090116112427_COM_1.zip, mode complete
Le fichier est prêt à être envoyé au support.


III-B-4. Maintenance

La maintenance des fichiers de logs et de trace est une nouveauté car, auparavant, il fallait programmer des méthodes de purge de manière externe (sous OEM, scripts adhoc en shell, perl ou autre).

Désormais, avec ADR et ADRCI, la commande PURGE va permettre de maintenir les fichiers en fonction des politiques de rétention, ou de paramètres qui lui seront passés.

L'aide de la commande PURGE peut-être obtenu par la commande suivante :
other

adrci> HELP PURGE
La commande PURGE s'exécute sur une seule Home ADR. De ce fait, il y a nécessité de sélectionner cette home avec les commandes SET HOME, SET HOMEPATH

Si on utilise la commande purge sans paramètres. Les fichiers seront purgés en fonction des politiques de rétention paramétrées dans ADR.

Pour rappel, il existe deux politiques de rétention :

  • une politique courte durée dénommée SHORTP_POLICY. Cette politique est appliquée aux fichiers et aux dumps des incidents.
  • une politique longue durée dénommée LONGP_POLICY. Cette politique est appliquée aux métadonnées des incidents.
On obtient leurs valeurs avec la commande "SHOW CONTROL" :
other

adrci> SHOW CONTROL
ADRID                SHORTP_POLICY        LONGP_POLICY        
-------------------- -------------------- --------------------
3954336691           360                  720                 
.../...
adrci> PURGE
On peut également spécifier des clauses plus précises pour la purge :

  • Purge spécifique d'incidents La purge spécifique d'incidents s'effectue avec l'option -i suivie de la liste des identifiants d'incidents à purger
other

adrci> set home diag/rdbms/dbtest/dbtest
adrci> show incident

ADR Home = /home/oracle/diag/rdbms/dbtest/dbtest:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                    CREATE_TIME
-------------------- ------------------------------ ----------------------------------------
22983                ORA 600                        2009-01-20 10:34:35.271448 +01:00
22982                ORA 700 [kgerev1]              2009-01-20 10:34:32.527232 +01:00
2 rows fetched
adrci> purge -i 22982
adrci>  show incident

ADR Home = /home/oracle/diag/rdbms/dbtest/dbtest:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                    CREATE_TIME
-------------------- ------------------------------ ----------------------------------------
22983                ORA 600                        2009-01-20 10:34:35.271448 +01:00
1 rows fetched
  • Purge ciblée sur le type et sur l'age;
Cette purge permet de purger une cible particulière (fichier d'alerte (ALERT), fichiers de trace (TRACE), incidents (INCIDENT), core dump (CDUMP), rapport "Health Monitor" (HM))

En complément du type, on purge en fonction d'un age donné en minutes.

Exemple 1 : Purge du fichier d'alerte du listener des évements de plus de 10 jours (14400 minutes) :
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/dbtest/dbtest
adrci>
adrci> set homepath diag/tnslsnr/linux1/listener
adrci> purge -age 14400 -type alert
Exemple 2 : Purge des fichiers de trace de la base "dbtest" de plus de 10 heures (600 minutes)
other

adrci> show homes
ADR Homes:
diag/asm/+asm/+ASM
diag/tnslsnr/linux1/listener
diag/rdbms/dbtest/dbtest
adrci>
adrci> set homepath diag/rdbms/dbtest/dbtest
adrci> purge -age 600 -type trace
NB : noter l'intérêt de pouvoir passer la commande en commande externe pour intégration aux jobs de purge


IV. Conclusion

ADR et ADRCI sont les deux nouveaux outils permettant le diagnostic d'incident.

Ils représentent un changement majeur dans l'organisation des fichiers journaux et de trace de la base de données.

Cependant, ces changements permettent de réelles avancées (stockage XML, packaging d'incidents etc.), un diagnostic et une résolution d'incidents plus rapide qu'auparavant, une gestion plus industrielle des fichiers.


V. Liens




               Version PDF (Miroir)

Valid XHTML 1.0 TransitionalValid CSS!

Copyright © 2009 Laurent Léturgez. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.