MS SQL Server et les problmatiques du journal de transaction

Date de publication : 2/07/2004 Par SQLPro (autres articles) (CV) niveau : intermdiaire lment rcurent dans les forums : au secours, le fichier de logs grossit de faon incontrlable... les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet ! Pas de remde miracle, avant de vous donner la solution, une petite explication... Article

Article
QUESTION Nous utilisons un logiciel [...] qui s'appuie sur une base SQL Server. Nous constatons que le fichiers LOG grossissent de faon incontrolable. A la cation nous avons autoris la croissance automatique des fichiers sans limite (si ce n'est celle du disque). Le problme est le suivant : - Comment rduire la taille des fichiers LOG, sachant que les commandes de troncature et de compression de BD de SQL Enterprise Manager n'ont aucun effet (mauvaise utilisation ou mauvaise procdure ?) ? - Aprs avoir rduit la taille des fichiers, puis fix une taille maximale que se passe-t-il quand cette taille est atteinte :

le plus ancien enregistrement est cras par le nouveau ? il y a une erreur et la gestion de ce cas est du ressort du crateur du logiciel ?

REPONSE Les fichier de log, sont en fait ce que l'on apelle en franais les "fichiers de journalisation". Ils contiennent toutes les transactions effectues dans la base de donnes (INSERT, UPDATE, DELETE..) enregistre en squence. Ce sont des fichiers en croissance forte qui peuvent parfaitement dpasser de beaucoup la taille des donnes. Par exemple si, partant d'une base

vide, on ajoute et supprime un millier de lignes dans une table, et cela plusieurs centaines de fois, la base sera quasi vide et le journal des transactions important. Il se peut donc que le journal des transactions vienne donc occuper un espace disque important et si l'administrateur n'y prend pas garde, saturer les disques... Les remdes sont les suivants :

surveillance des quotas d'espace disque via l'OS (alertes administratives) planification du vidage des journaux de transactions limitation de la croissance du fichier de transaction (dangereux)

Mais il se peut que vous ayez du mal vider votre journal de transaction ! Pourquoi ce comportement ? Tout simplement par scurit. En effet les diffrentes sauvegardes : base complte, base diffrentielle ou journal des transactions permettent de rcuprer une base corrompue. Tant que ces fichiers ne sont pas tronqus, la rcupration est en principe toujours possible. C'est pourquoi tant que la sauvegarde base + journal n'a pas eut lieu, il n'est pas possible de tronquer les fichiers. EN CAS D'URGENCE voici comment rduire un journal des transactions une valeur voulue : L'exemple suivant illustre ceci avec la base de donnes toto et essaye de rduire le journal toto_log 200 Mo : 1. Excutez ce code dans l'analyseur de requte :
USE toto GO DBCC SHRINKFILE(toto_log, 200)

Cet ordre tente de rcuprer les espaces vides du journal de transaction. Vrifiez la taille du journal de transaction dans l'entreprise manager (au besoin, rafraichissez l'affichage F5)

2. : Si le journal toto_log est toujours plus grand que la taille voulue, excutez ce code dans l'analyseur de requte :
BACKUP LOG toto WITH TRUNCATE_ONLY

Attention, cet ordre effectue une "fausse" sauvegarde du journal de transaction, c'est dire qu'il ne sauvegarde rien, mais transforme l'espace des transactions termines en espace mort. Par scurit, vous pouvez faire une sauvegarde du journal des transactions, ce qui prendra plus de temps mais contribuera au mme but.

Vrifiez la taille du journal de transaction dans l'entreprise manager (au besoin, rafraichissez l'affichage F5) 3. : Si le journal est toujours plus grand que la taille demande, excutez ce code dans l'analyseur de requte :
DBCC SHRINKFILE(toto_log, 200)

Vrifiez la taille du journal de transaction dans l'entreprise manager (au besoin, rafraichissez l'affichage F5) Le journal de transactions devrait tre rduit 200 Mo.

Si ce n'est pas le cas : 1. vrifiez qu'une sauvegarde complte de la base a t prcdemment entreprise 2. vrifiez que le mode de recouvrement de votre base de donnes n'est pas le mode "simple". Pour ce faire : dans entreprise manager, cliquez droit sur la base voulue, slectionnez l'entre de menu "proprits", onglet "option", item "rcupration", champs "Modle".

NOTA : toto est le nom logique de la base, toto_log est le nom logique du journal de transactions PS : si vous ne connaissez pas les noms logique des objets (base et journal des transactions), veuillez excuter la requete suivante :
SELECT CASE WHEN status & CAST(0x40 AS INT) = CAST(0x40 AS INT) THEN 'journal des transactions' ELSE 'donnes' END as contenu, name as nom_logique FROM sysfiles contenu nom_logique ----------------------------------------donnes DB_DS_GIMA_H_Data journal des transactions DB_DS_GIMA_H_Log (2 ligne(s) affecte(s))

ATTENTION : la limitation de la taille du fichier de transaction peut s'avrer un remde pire que le mal : il peut entraner le blocage du serveur. De mme un fichier de transaction ridiculement petit entrainera des performances notablement dgrades. Inversement, une grande taille n'affecte pas les performances du fait qu'il est crit en squentiel. En principe un journal des transactions doit tre capable de recevoir les critures de transaction d'au moins une priode de temps donn (heure, journe, semaine...) avant

sauvegarde. Pour obtenir des performances, sa taille minimale doit donc tre base sur la moyenne de remplissage de ce laps de temps. pour en savoir plus : http://support.microsoft.com/?id=272318