MaBase_Log.ldf est trop volumineux

Version imprimable

31/10/2003, 10h48
Fractal Blue

MaBase_Log.ldf est trop volumineux

8O Bonjour,
Je souhaite réduire la taille du fichier MaBase_Log.ldf
Débutante, je n'ai pas pensé à restreindre dès le départ la taille du journal des transactions.
Maintenant il fait 6G0! pour une base de 200Mo.
Je vous remercie de votre aide.

FractalBlue

Utilises

Code:

1
2
 
         ShrinkDatabase MaBase_Log, 200

31/10/2003, 12h21
Fractal Blue

:oops:
J'ai tapé la commande
DBCC SHRINKDATABASE (MaBase, 200,TRUNCATEONLY)

Mais la taille physique du fichier n'a pas changé.
Merci de ton aide.

FractalBlue
31/10/2003, 12h58
WOLO Laurent

Citation:

Envoyé par Fractal Blue

:oops:
J'ai tapé la commande
DBCC SHRINKDATABASE (MaBase, 200,TRUNCATEONLY)

Mais la taille physique du fichier n'a pas changé.
Merci de ton aide.

FractalBlue

Oui, j'ai oublier de vous le dire, la taille physique ne change pas.
Tu ne dois pas t'en faire pour cela.
31/10/2003, 15h27
Fractal Blue

:D Merci, j'ai détourné le problème et j'ai fini par arrivée à mes fins.
31/10/2003, 15h38
WOLO Laurent

Et comment tu as fait ?
31/10/2003, 16h01
Fractal Blue

Réaliser une sauvegarde de MaBase avant tout.

J'ai créé une nouvelle base, MaBase_2, pour laquelle j'ai configuré d'entrée la taille maximal des fichiers. Ensuite importé toute mes données de Mabase vers MaBase_2. Vérification d'usage de la complétude des données au sein de MaBase_2. Enfin il suffit de renommer MaBase_2 en MaBase.

Bon je vous l'accorde, ce n'est pas très correcte comme procédure, mais l'espace disque est une denrée rare dans ma boite.

Merci beaucoup pour les renseignements qui m'ont aidé à mieux comprendre les journaux de transactions.

FractalBlue
31/10/2003, 16h12
WOLO Laurent

Très bien Fractal Blue,
J'y est pensé aussi mais hésité par la suite de proposer cette solution.
Je l'ai trouvé trop longue.
Merci pour ton inspiration.
04/11/2003, 10h55
Thomad

Perso je m'en suis sorti comme çà:

Use Tabase

dbcc shrinkfile(NomFichier_log) // ton fichier journal transac.

backup log Tabase with truncate_only

Ici regarde si la taille du fichier est réduite sinon

Faire dbcc shrinkfile(NomFichier_log) une douzaine de fois pour que le VLF ( Virtual Log Files ) se déplace

Ensuite refaire

backup log Tabase with truncate_only

Maintenant regarde la taille du fichier de log.

Manip. tirée d'un livre de MicroSoft

Mon fichier est passé de 75 Mo à 1 Mo

Attention !!! je l'ai fais sur une base de test

Tiens-moi au courant.

A+
04/11/2003, 11h12
WOLO Laurent

Citation:

Envoyé par Thomad

Perso je m'en suis sorti comme çà:

Manip. tirée d'un livre de MicroSoft

Mon fichier est passé de 75 Mo à 1 Mo

Tiens-moi au courant.

A+

Quel manuel de Microsoft ?
Et pour quoi 12 fois.
04/11/2003, 11h22
Thomad

Au coeur de SQL Server 7.0 de Microsoft / page 203

Ne me demande pas pourquoi mais en tout cas çà marche.Une douzaine de fois pour, comme je dis plus haut , le VLF actif se déplace.

A+
04/11/2003, 11h47
WOLO Laurent

Avec mon SQL Serveur 2000, il n'y a même pas la pagination.
Mais merci pour l'info.
05/11/2003, 12h19
Fractal Blue

Merci Thomad

Ta manip. marche très bien
De plus elle est rapide.

Fractal Blue
15/01/2009, 11h48
Igmar

Thanks
Merci Thomad,

Par contre je n'ai pas eu ton pb. Le faire une seule fois a été suffisant.

Voici le détail :
Code:

1 2 3 4 Use MaBase DBCC SHRINKFILE(MaBase_Log) backup log MaBase with truncate_only
15/01/2009, 20h17
elsuket

Bonjour,

Effectivement tout cela marche très bien mais ce sont des manipulations dangereuses en ce qui concerne la consistance et les performances de la base de données.
L'option TRUNCATE_ONLY, équivalente à NO_LOG, de la commande BACKUP LOG rompt la séquence de sauvegardes.
En effet, une fois que vous avez exécuté cette opération, toutes les données qui étaient dans la partie inactive du journal sont perdues, donc vous ne pourrez pas les récupérer.
Supposons qu'un crash se produise ...

Si vous êtes en mode de récupération FULL, effectuez un backup complet de la base de données, puis un BACKUP LOG sans options, une à deux fois, et ensuite de réduire la taille de fichier.
Si cela ne fonctionne pas, réaliser un backup complet de la base de données, puis la passer en SIMPLE, patienter un peu plus d'une minute (pour attendre un CHECKPOINT qui écrive les données dans le log), et repasser la base de données en mode FULL, puis refaire un backup complet de la BD et de la base de données système Master.

Si vous êtes en mode SIMPLE, (comme en FULL d'ailleurs) il vaut mieux chercher ce qui a causé le retard de la troncature du journal : ce peut être une transaction restée ouverte (que l'on trouve par exemple avec DBCC OPENTRAN), ou bien une mise en miroir, une réplication, ...

Dans tous les cas il ne faut pas tailler les fichiers de base de données trop juste, que ce soit le(s) fichier(s) de données ou le log de transaction, et réserver les rétrécissements à des manœuvres d'urgence.
Laisser les fichiers en taille fixe est aussi un danger ...

Lorsque vous réduisez un fichier, vous forcez SQL Server à rendre de la mémoire disque qu'il s'est allouée et qu'il reprendra tôt ou tard.
L'accès à un disque étant au moins 1000 fois plus lent que celui à la RAM, je vous laisse imaginer la contention que cela peut créer.

@++ ;)