![\"ObjectExplorer\"](\"https:\/\/www.sqlserver.fr\/blog\/wp-content\/uploads\/2013\/05\/ObjectExplorer.png\")
<\/a><\/p>\nPar d\u00e9faut, nous avons le journal courant et 6 journaux au maximum en archives. Ces fichiers correspondent \u00e0 des fichiers stock\u00e9s dans le sous-dossier MSSQL\\Log de votre dossier d’installation de SQL Server.<\/p>\n
Il s’agit du fichier ERRORLOG (sans suffixe), et des fichiers ERRORLOG.1, ERRORLOG.2, et ainsi de suite.<\/p>\n Par d\u00e9faut, on passe sur un nouveau fichier lors du red\u00e9marrage de l’instance. Un nouveau fichier ERRORLOG est cr\u00e9\u00e9, le pr\u00e9c\u00e9dent devient .1, le .1 devient .2, …, et l’ancien .6 est supprim\u00e9.<\/p>\n Le probl\u00e8me est que lorsqu’une instance reste active longtemps (pendant plusieurs mois), la volum\u00e9trie du fichier ERRORLOG, et donc entre autre sa dur\u00e9e d’ouverture, s’allonge de mani\u00e8re d\u00e9raisonn\u00e9e. Certains administrateurs de donn\u00e9es organisent des red\u00e9marrages r\u00e9guliers planifi\u00e9s d’instances (par exemple lors du dernier week-end de chaque mois), en synchronisant cela par exemple avec les passages mensuels de hotfix.<\/p>\n Il y a donc une commande d\u00e9di\u00e9e, permettant de \u00ab\u00a0passer au fichier suivant\u00a0\u00bb de mani\u00e8re forc\u00e9e sans avoir besoin de red\u00e9marrer l’instance :<\/p>\n Il est conseill\u00e9 de lancer cette commande de mani\u00e8re planifi\u00e9e r\u00e9guli\u00e8rement, par exemple une fois par jour ou au pire une fois par semaine.<\/p>\n 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\u00e9calage de fichier tous les jours, un historique de 6 fichiers ne nous permettrait m\u00eame pas de tenir une semaine. Le nombre de fichiers retenus est pour cela param\u00e9trable via Management Studio, par clic droit sur la branche \u00ab\u00a0SQL Server Logs\u00a0\u00bb vue pr\u00e9c\u00e9demment.<\/p>\n Ainsi, on peut d\u00e9cider de conserver un historique contr\u00f4l\u00e9 de 1, 2 ou 3 mois par exemple en effectuant un d\u00e9calage de fichier quotidiennement. Attention toutefois, les red\u00e9marrages d’instance viendront ajouter \u00e0 chaque fois un d\u00e9calage suppl\u00e9mentaire.<\/p>\n A noter enfin que l’Agent SQL Server stocke\u00a0lui aussi fonctionne son historique via un jeu de fichiers. Toutefois, le param\u00e9trage est\u00a0diff\u00e9rent. Il est tout d’abord\u00a0disponible via le param\u00e9trage de l’Agent SQL Server lui-m\u00eame :<\/p>\n Le contenu et l’emplacement des fichiers est lui aussi param\u00e9trable, par clic droit dans l’explorateur d’objets sur la branche des journaux de l’Agent SQL :<\/p>\n Ces param\u00e9trages 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 \u00e0 noter dans nos tablettes …<\/p>\n Post Scriptum<\/span> : Sur les versions SQL Server 2000 et pr\u00e9c\u00e9dentes, cette proc\u00e9dure stock\u00e9e syst\u00e8me n’existait pas, mais l’op\u00e9ration de maintenance \u00e9tait tout de m\u00eame r\u00e9alisable via la commande DBCC ERRORLOG.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Tout administrateur syst\u00e8me Windows a d\u00e9j\u00e0 eu l’occasion de pester devant une dur\u00e9e de chargement excessive du journal d’\u00e9v\u00e9nement Windows (par exemple la rubrique Application ou Syst\u00e8me) parce que la machine \u00e9tait en place depuis pas mal de temps et … Continuer la lecture <\/a><\/p>\nsp_cycle_errorlog<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n