Une qualité intéressante des logiciels Oracle en général et de la base en particulier est l’enregistrement dans des fichiers de journaux les évènements survenant lors de l’exécution du logiciel, comme par exemple le fichier d’alerte pour la base. Il est ainsi plus aisé de comprendre un problème quand celui-ci survient.
Toutefois, il est possible qu’à force d’enregistrer ces évènements, votre fichier de journal remplisse entièrement la place disponible sur le disque et mette en péril l’exécution du logiciel. Il existe ainsi sous Linux un outil standard bien pratique pour gérer les fichiers de log qui s’appelle Logrotate. Je vous propose ainsi de découvrir comment intégrer les logiciels Oracle avec.
Le but de Logrotate est non seulement d’éviter que votre système de fichier se remplisse, mais aussi d’archiver les journaux. Il est possible par exemple de dire de conserver les logs sur 5 semaines glissantes. C’est important notamment pour les sites web ou il est obligatoire de conserver les logs de connexion pendant 1 an.
Ce que fait basiquement Logrotate lors d’une opération d’archivage (en partant de l’hypothèse que l’on veut un historique de 5 versions ) est décrit ci-dessous :

• suppression de l’archive 5 ;
• déplacement de l’archive 4 en 5 ;
• déplacement de l’archive 3 en 4 ;
• déplacement de l’archive 2 en 3 ;
• déplacement de l’archive 1 en 2 ;
• déplacement du log courant en archive 1.

Ce qui est important de noter, c’est le mot « déplacement ». Dans le cas des applications standard livrées avec votre distribution Linux, celles sont intégrées au Logrotate et gèrent nativement le déplacement du fichier en effectuant un rechargement de l’application après avoir déplacement le fichier de log (kill -HUP sur le processus). Dans le cas des logiciels Oracle, on pourrait mettre en place aussi un tel système, mais cela nous empêcherait d’avoir une disponibilité à 100% : à un moment donné, il faudrait arrêter la base ou le serveur d’application ce qui n’est pas possible dans la plupart des cas. Heureusement il existe un autre mode qui, au lieu de déplacer le fichier de log de courant, le copie et le tronque.
Concrètement, pour faire tourner vos fichiers de log de base de données en version inférieure à la 11, il suffit de créer un fichier /etc/logrotate.d/oracle qui contient :

# rotation des logs d'alerte
/u01/app/oracle/admin/*/bdump/alert_*.log {
 # on veut 5 semaines
 rotate 5
 # compression des archives
 compress
 # rotation hebdomadaire
 weekly
 # mode copie et  tronque
 copytruncate
 # continue même si il y a une erreur
 missingok
}
# rotation des logs sql*net
/u01/app/oracle/product/10.2.0/network/log/*.log {
 rotate 5
 compress
 weekly
 copytruncate
 missingok
}

En version 11, cela diffère un peu car les emplacement ont changé :

/u01/app/oracle/diag/rdbms/*/*/alert/log.xml {
 rotate 5
 compress
 weekly
 copytruncate
 missingok
}
/u01/app/oracle/diag/rdbms/*/*/trace/alert_*.log {
  rotate 5
  compress
  weekly
  copytruncate
  missingok
}
/u01/app/oracle/diag/tnslsnr/*/*/alert/log.xml {
 rotate 5
 compress
 weekly
 copytruncate
 missingok
}
/u01/app/oracle/diag/tnslsnr/*/*/trace/listener.log {
  rotate 5
  compress
  weekly
  copytruncate
  missingok
}
/u01/app/oracle/product/11.1.0/network/log/*.log {
  rotate 5
  compress
  weekly
  copytruncate
  missingok
}

Enfin, un dernier exemple pour Oracle Application Server :

/u01/app/as102/j2ee/*/log/*/*.log {
    rotate 5
    compress
    weekly
    copytruncate
    missingok
}
/u01/app/as102/j2ee/*/log/*.log {
    rotate 5
    compress
    weekly
    copytruncate
    missingok
}