Discussion :

[Fractal Blue]

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

[WOLO Laurent]

Utilises

Code :

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

1
2
 
         ShrinkDatabase MaBase_Log, 200

[Fractal Blue]

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

[WOLO Laurent]

: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.

[Fractal Blue]

Merci, j'ai détourné le problème et j'ai fini par arrivée à mes fins.

[WOLO Laurent]

Et comment tu as fait ?

[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

[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.

[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+

[WOLO Laurent]

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.

[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+

[WOLO Laurent]

Avec mon SQL Serveur 2000, il n'y a même pas la pagination.
Mais merci pour l'info.

[Fractal Blue]

Merci Thomad

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

Fractal Blue

[Igmar]

Merci Thomad,

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

Voici le détail :

Code :

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

1
2
3
4
 
Use MaBase
DBCC SHRINKFILE(MaBase_Log)
backup log MaBase with truncate_only

[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.

@++