Tout administrateur système Windows a déjà eu l’occasion de pester devant une durée de chargement excessive du journal d’événement Windows (par exemple la rubrique Application ou Système) parce que la machine était en place depuis pas mal de temps et que l’on avait depuis le temps cumulé un nombre d’événements assez important. La limite est bien entendue paramétrable, mais il ne faut pas couper trop court, car on risquerait alors de supprimer des informations encore potentiellement nécessaires.

Côté SQL Server, nous avons aussi une journalisation d’événements. Celle-ci bascule sur un nouveau sous-ensemble à chaque redémarrage d’instance. Mais il n’est pas obligatoire de redémarrer le moteur pour repartir sur un nouveau jeu d’enregistrements, et nous allons voir que nous pouvons éviter les journaux trop longs même sur des instances restant actives très longtemps.

Tout d’abord, voici un petit rappel concernant les journaux SQL Server. Ils sont notamment accessibles via SQL Server Management Studio de la manière suivante :

Par défaut, nous avons le journal courant et 6 journaux au maximum en archives. Ces fichiers correspondent à des fichiers stockés dans le sous-dossier MSSQL\Log de votre dossier d’installation de SQL Server.

Il s’agit du fichier ERRORLOG (sans suffixe), et des fichiers ERRORLOG.1, ERRORLOG.2, et ainsi de suite.

Par défaut, on passe sur un nouveau fichier lors du redémarrage de l’instance. Un nouveau fichier ERRORLOG est créé, le précédent devient .1, le .1 devient .2, …, et l’ancien .6 est supprimé.

Le problème est que lorsqu’une instance reste active longtemps (pendant plusieurs mois), la volumétrie du fichier ERRORLOG, et donc entre autre sa durée d’ouverture, s’allonge de manière déraisonnée. Certains administrateurs de données organisent des redémarrages réguliers planifiés d’instances (par exemple lors du dernier week-end de chaque mois), en synchronisant cela par exemple avec les passages mensuels de hotfix.

Il y a donc une commande dédiée, permettant de “passer au fichier suivant” de manière forcée sans avoir besoin de redémarrer l’instance :

sp_cycle_errorlog

Il est conseillé de lancer cette commande de manière planifiée régulièrement, par exemple une fois par jour ou au pire une fois par semaine.

C’est bien de faire tourner plus rapidement les fichiers, mais on peut aussi souhaiter garder un certain historique. Si l’on effectue un décalage de fichier tous les jours, un historique de 6 fichiers ne nous permettrait même pas de tenir une semaine. Le nombre de fichiers retenus est pour cela paramétrable via Management Studio, par clic droit sur la branche “SQL Server Logs” vue précédemment.

Ainsi, on peut décider de conserver un historique contrôlé de 1, 2 ou 3 mois par exemple en effectuant un décalage de fichier quotidiennement. Attention toutefois, les redémarrages d’instance viendront ajouter à chaque fois un décalage supplémentaire.

A noter enfin que l’Agent SQL Server stocke lui aussi fonctionne son historique via un jeu de fichiers. Toutefois, le paramétrage est différent. Il est tout d’abord disponible via le paramétrage de l’Agent SQL Server lui-même :

Le contenu et l’emplacement des fichiers est lui aussi paramétrable, par clic droit dans l’explorateur d’objets sur la branche des journaux de l’Agent SQL :

Ces paramétrages font partie de toutes ces petites choses que l’on oublie parfois de mettre en place lors de l’installation d’un serveur, et qui pourtant nous simplifient bien la vie. Donc à noter dans nos tablettes …

Post Scriptum : Sur les versions SQL Server 2000 et précédentes, cette procédure stockée système n’existait pas, mais l’opération de maintenance était tout de même réalisable via la commande DBCC ERRORLOG.