comment diminuer fichier des transaction

**hamadi19000** · 14/07/2010, 11h57

j'ai une base de données SQL SEVER2000 installée sur un Disque Dur de 40 GO, le problème est que le fichier transaction devient de plus en plus grand malgré que j'ai lui est limité la taille.
comment diminuer la taille de ce fichier sans perdre les données la base de données?

merci d'avance

**mikedavem** · 14/07/2010, 12h04

Bonjour,

Faites vous des sauvegardes régulières de votre journal ? (Ce qui peut être un bon moyen d'éviter l'agrandissement du journal)

Dans quel mode de récupération êtes vous ? (FULL, BULK LOGGED ou SIMPLE)

++

**hamadi19000** · 14/07/2010, 15h54

BONJOUR
Pour la sauvegarde du journal non je n'ai pas fait de sauvegarde du journal mais seulement la sauvegarde de la BASE DE DONNEES
pour le mode de récupération : Full (complet)

**mikedavem** · 14/07/2010, 16h13

Le seul moyen de vider le journal (ou tronquer le journal) est d'effectuer une sauvegarde des journaux de transactions soit BACKUP LOG.

Il faut ajouter à votre plan de maintenance une sauvegarde de ce type.

++

**hamadi19000** · 16/07/2010, 08h12

Merci
en faisant la sauvegarde du journal ca va librer l'espace occupé ?

**mikedavem** · 16/07/2010, 08h36

Tout dépend de ce que vous appelez "libérer l'espace".

La sauvegarde du journal ne fait que tronquer celui-ci. Certaines parties du journal sont alors rendues inactives et peuvent être réutilisées.

La sauvegarde du journal ne réduit pas en terme d'espace disque le ou les fichiers concernant le journal.

++

**LaCap** · 22/09/2010, 21h42

Bonsoir à tous.

Donc si je comprends bien, il n'est pas possible de réduire la taille du log de JT?
Car j'ai actuellement une base de 16Go avec un fichier de log de JT de 66Go qui commence à prendre presque toute la place sur le disque dur.
Je ne sais pas comment faire diminuer cette taille.
Pour information, j'ai réalisé un backup complet de la base et un backup du fichier de log des JT.
Je ne sais plus quoi faire

Par avance merci.

Benoît

**mikedavem** · 22/09/2010, 22h21

Vous pouvez réduire la taille du journal à l'aide la commande DBCC SHRINFILE.
Cependant interrogez vous sur la taille de votre journal et de ce qui a pu le faire grossir car réduire le journal risque de n'être qu'une solution temporaire.

++

**elsuket** · 23/09/2010, 07h06

Bonjour,

Vous pouvez voir la requête suivante que je viens de publier.

Est-il nécessaire que votre base de données soit en mode de restauration FULL ?
Comme le suggère MikeDavem, avez-vous des plans de maintenance, des procédures stockées ou des requêtes qui manipulent un grand jeu de données ?

@++

**LaCap** · 23/09/2010, 08h52

Bonjour elsuket,

Je vais jouer votre requête pour voir ce qui se passe avec ces fichiers virtuels.

Par contre je ne connais pas les modes de restaurations.
Je vais regarder ce que c'est. Mais en quoi le mode FULL serait problèmatique dans mon cas?

Pour ce qui est des requêtes manipulant un grand jeu de donnée, il faut que je me renseigne.

Merci,

Benoît

**LaCap** · 23/09/2010, 09h06

elsuket,

Je viens de jouer votre requête et voilà mon résultat:
total_file_size_MB file_size_in_use_MB VLF_amount VLF_in_use
65574 65574 622 622

**mikedavem** · 23/09/2010, 09h25

Par contre je ne connais pas les modes de restaurations.
Je vais regarder ce que c'est. Mais en quoi le mode FULL serait problèmatique dans mon cas?

Le mode de récupération FULL nécessite obligatoirement la mise en place d'une sauvegarde du journal des transactions d'une base de données. Ceci permet :

- De pouvoir restaurer dans le temps
- De vider le journal (important dans votre cas car sans cette sauvegarde le fichier journal ne fera que grossir)

Apparemment tous les VLF sont utilisés

Que donne la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC SQLPERF(LOGSPACE)

++

**LaCap** · 23/09/2010, 09h34

mikedavem,

Voilà ce que me retourne la commande pour cette base:

BASE 65644,74 99,89246 0

**mikedavem** · 23/09/2010, 09h41

Votre journal est plein.

Tout d'abord il faut regarder le mode de récupération de votre base :

1.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 
 DB_NAME(database_id) AS database_name,
 recovery_model_desc
FROM sys.databases
WHERE database_id = DB_ID('BASE')

2.
Effectuer une sauvegarde du journal pour le vider

3.
Tentez une réduction de votre journal à l'aide de la commande DBCC SHRINFILE

4.
Implémentez dans un plan de maintenance (existant) une sauvegarde régulière du journal --> Je suppose fortement que le mode récupération est FULL

++

**elsuket** · 23/09/2010, 10h04

La requête montre que votre fichier du journal des transactions est plein : il compte 622 fichiers virtuels, et tous sont utilisés.

Je ne parviens pas à me rappeler, sous SQL Server 2000, quelle table système interroger pour récupérer le mode de récupération des bases de données ...
La requête suivante fonctionnera néanmoins :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT DATABASEPROPERTYEX('maBD', 'Recovery')

Pour faire simple, si vous utilisez le mode de restauration :

- FULL, vous n'admettez pas la perte de données entre deux sauvegardes de votre base de données, et toutes les opérations sont complètement journalisées

- BULK LOGGED est globalement identique à FULL, excepté que les opérations comme la reconstruction d'index ou le chargement de données en masse sont journalisés de façon minimale

- SIMPLE vide les fichiers virtuels dès la fin de la transaction (c'est en fait un processus asynchrone en arrière-plan qui s'en charge).
En revanche, toutes les données modifiées depuis la dernière sauvegarde complète de la base de données peuvent être perdues.

Les deux premiers modes vous obligent à effectuer des sauvegardes régulières de votre fichier du journal des transactions.
L'intervalle des sauvegardes est à déterminer par vous-même suivant l'activité qu'enregistre votre base de données.

@++

**LaCap** · 23/09/2010, 10h19

Je viens de résoudre le problème.
J'ai passé la base en mode de récupération simple.
Puis fais un backup des logs.
Et repassé la base en mode de récupération FULL.

Je pense que les logs ne se vidaient pas proprement, tout simplement car les backups ne tournaient plus depuis un certain temps.

Merci pour tout.

Benoît