suppression log sql server 2008

**vince2005** · 09/01/2012, 10h32

Bonjour,

Je souhaiterai tronquer la Log d'une base lorsque celle-ci grossi trop rapidement sous Sql Server 2008. Comme par exemple tous les matins.

Quel est la ligne de commande pour supprimer la log d'une base de données ?

Merci d'avance

**Jinroh77** · 09/01/2012, 11h05

Si à propos de "Log", vous parlez du journal de transactions, et que celui-ci augmente tous les matins, il n'y a aucune raison de réduire la taille du fichier de manière automatique.
Cela sera contre-performant.

Pour en savoir plus, faites une recherche rapide sur le forum, beaucoup (trop) de topics traitent de ce sujet.

**mikedavem** · 09/01/2012, 11h09

Bonjour,

Pour tronquer le journal des transactions d'une base il faut utiliser le sauvegarder ou éventuellement utiliser la commande DBCC SHRINKFILE et l'option TRUNCATE_ONLY pour tenter de libérer de la place à l'intérieur du journal.

Pour réduire la taille du fichier journal il faut utiliser la commande DBCC SHRINKFILE avec une valeur cible.

Cependant permettez quelques questions :

Pourquoi voulez-vous faire cela tous les matins ?
Qu'est ce qui fait grossir votre journal ?
Quel mode de récupération utilisez-vous ?

++

**vince2005** · 09/01/2012, 11h38

en fait il s'agit bien du journal des transactions. Lorsqu'il n'est pas vider pendant plusieurs semaines, il peut atteindre 200Go. Donc mon disque physique est full.

Par prevention, je voulais lancer cette commande tous les matins ou tous les soirs.

Quelle strategie semble la plus adapté ?

**Jinroh77** · 09/01/2012, 11h42

Selon votre description, votre base de données en mode de récupération COMPLET. Cela implique que chaque transaction est enregistrée dans.. votre journal de transaction.
Vous avez alors 2 possibilité :
- soit vous ne réalisez aucune maintenance (dangereux) et une sauvegarde unique par jour vous suffit, alors, passer votre base en mode de récupération SIMPLE.

- soit vous ne pouvez vous perdre plus de x heures/minutes de données en cas de plantage et dans ce cas, laissez le mode de récupération complet et appliquez un plan de maintenance qui réalisera une sauvegarde complète pendant la nuit et des sauvegardes des journaux de transactions dans la journée, toutes les X heures/minutes.
Cette sauvegarde aura pour effet de vider l'intérieur du fichier, l’empêchant alors de grandir abusivement.

**mikedavem** · 09/01/2012, 11h44

Visiblement (corrigez moi si je me trompe) vous n'utilisez pas les sauvegardes du journal pour pouvoir faire une restauration dans le temps.

Dans ce cas passez votre base en mode de récupération simple pour éviter le remplissage à l'infini du fichier journal de votre base.

Dans le cas où vous utilisez une stratégie de sauvegarde comprenant celle des journaux il faudra penser à sauvegarder régulièrement le journal pour le vider.

++

**vince2005** · 09/01/2012, 12h31

En effet, ma base de données est en mode de récupération complet. La sauvegarde de ma base est journalière et se réalise via la plan de maintenance vers 22H00. Donc une fois par jour. Dans ce cas, si j'ai bien compris, je peux basculer en mode de récupération simple. Puisque la compléte sert s'il y a plusieurs sauvegardes par jour ?

D'aprés vous, le fait de sauvegarder ma base, vide la log automatiquement ?

**mikedavem** · 09/01/2012, 13h03

Dans ce cas, si j'ai bien compris, je peux basculer en mode de récupération simple. Puisque la compléte sert s'il y a plusieurs sauvegardes par jour ?

Avec une complète par jour, vous pouvez perdre jusqu'à une journée de données. Si vous pouvez vous permettre cela, passez en mode de récupération simple.

D'aprés vous, le fait de sauvegarder ma base, vide la log automatiquement ?

Le fait de sauvegarder le fichier journal videra le log (BACKUP LOG ...) quand vous êtes en mode de récupération FULL ou BULK-LOGGED. Le mode de récupération simple tronquera votre journal automatiquement ce qui empêchera celui-ci de grossir indéfininement.

++

**vince2005** · 09/01/2012, 14h00

chaque soir , je réalise une sauvegarde de ma base complete ( data + log) et ce n'est pas pas cela que le log se vide aprés mon dump ?

**mikedavem** · 09/01/2012, 15h40

chaque soir , je réalise une sauvegarde de ma base complete ( data + log) et ce n'est pas pas cela que le log se vide aprés mon dump ?

Quelles tâches utilisez-vous dans votre plan de maintenance pour la sauvegarde ?

++

**vince2005** · 09/01/2012, 16h19

=> Verifier l'intégrité de la base de données
=> Compacter la base de données
=> Reorganiser l'index
=> Nettoyer l'historique
=> Sauvegarder la base de données (complète)
=> Tâche de nettoyage de maintenance

Voilà les tâches que j'execute chaque soir.

**Jinroh77** · 09/01/2012, 16h28

Attention, dans ce plan le compactage de la base de données est à désactiver, il est néfaste pour les performance, surtout dans le cas où l'espace est réellement utilisé par la BDD pendant la journée.

de plus, la réorganisation des indexs, peut potentiellement générer beaucoup d'écriture dans les journaux de transactions dans le cas où la base est en mode complet.
Si vous souhaitez conserver votre base en mode complet (et donc y appliquer obligatoirement une sauvegarde des journaux pendant la journée), vous devriez passer la base en mode simple au début de votre plan de maintenance, puis la repasser en mode complet avant la sauvegarde.

**mikedavem** · 09/01/2012, 17h01

@vince2005 >

Au vu de votre plan vous ne sauvegardez les journaux. C'est normal que vos fichiers de log grossissent. Il faut également implémenter une sauvegarde des journaux comme expliqué un peu plus haut avec une autre tâche de sauvegarde. La sauvegarde FULL ne vide pas le journal.

@Jinhro77 >

de plus, la réorganisation des indexs, peut potentiellement générer beaucoup d'écriture dans les journaux de transactions dans le cas où la base est en mode complet.
Si vous souhaitez conserver votre base en mode complet (et donc y appliquer obligatoirement une sauvegarde des journaux pendant la journée), vous devriez passer la base en mode simple au début de votre plan de maintenance, puis la repasser en mode complet avant la sauvegarde.

Je pense que ce n'est pas forcément la meilleure chose à faire dans ce cas. Le passage en mode simple dans ce cas invalide la séquence des LSN. Si la base est utilisée à ce moment là et que l'on doit revenir à l'état le plus proche du crash cela va poser problème. Il vaut mieux dans ce cas prévoir une tâche SQL avec un script personnalisé de réindexation pour ne s'occuper que des indexes réellement fragmentés.

De plus si la base est volumineuse il faudra refaire une seconde sauvegarde donc prévoir plus de place dans un même plan de maintenance. Si la base est volumineuse ce n'est pas forcément ce qu'il y a de mieux à faire.

++

**Jinroh77** · 09/01/2012, 17h14

Envoyé par mikedavem

Je pense que ce n'est pas forcément la meilleure chose à faire dans ce cas. Le passage en mode simple dans ce cas invalide la séquence des LSN. Si la base est utilisée à ce moment là et que l'on doit revenir à l'état le plus proche du crash cela va poser problème. Il vaut mieux dans ce cas prévoir une tâche SQL avec un script personnalisé de réindexation pour ne s'occuper que des indexes réellement fragmentés.

De plus si la base est volumineuse il faudra refaire une seconde sauvegarde donc prévoir plus de place dans un même plan de maintenance. Si la base est volumineuse ce n'est pas forcément ce qu'il y a de mieux à faire.

++

Merci pour la précision sur les LSN David.
Par contre, même avec un script personnalisé, si l'on traite un grand nombre d'index, le volume augmentera de la même manière ?

On se retrouve alors avec un fichier de journal plein, pour lequel il faut faire une sauvegarde afin de le vider avant de commencer la journée. Le volume de sauvegarde augmente donc grandement.

Dans mon cas de passage en mode simple, c'est à propos de plan de maintenance sur des bases de petite taille non utilisées 24/24. Mon plan n'est donc pas valable pour de la forte volumétrie.

**mikedavem** · 09/01/2012, 17h26

Par contre, même avec un script personnalisé, si l'on traite un grand nombre d'index, le volume augmentera de la même manière ?

Effectivement si tous les indexes sont fragmentés et que leur nombre est important on n'aura pas gagné grand chose je te l'accorde. Cependant la tâche par défaut des plans de maintenance va traiter tous les indexes sans exception. Avec un script personnalisé il y a de grandes chances de réduire le volume d'indexes à traiter de manière conséquente.

On se retrouve alors avec un fichier de journal plein, pour lequel il faut faire une sauvegarde afin de le vider avant de commencer la journée. Le volume de sauvegarde augmente donc grandement.

Même chose le volume sera directement dépend de la volumétrie liée aux indexes. A tester. Rmq on peut tout à fait à l'aide d'un script personnalisé faire une maintenance étalée sur plusieurs jours pour réduire le nombre de données dans le journal pour un plan de maintenance donné. Bref, il y a pleins de façons d'arriver à réduire la quantité de données dans le journal liée à la maintenance

Ceci étant dit dans le cas de vince2005 je pense qu'il suffirait d'adopter un mode simple aux vu des contraintes ...

++

**vince2005** · 10/01/2012, 21h32

moi ce que je souhaite, c'est de faire une sauvegarde en fin de journée. S'il y a un plantage, je reparts de ma sauvegarde la veille et les utilisateurs resaisiront les données si nécessaires.

donc quel technique adopté ?