Version imprimable
Bonjour,
un post de plus sur cette malédiction sql-serveur .
sqlpro cite :
Peut-on utiliser cette commande à chaud (base ouverte) ou faut-il déconnecter les fichiers auparavant ?Citation:
USE toto
GO
DBCC SHRINKFILE(toto_log, 200)
Sinon, quelles est la différence entre les commandes :
BACKUP LOG
et BACKUP TRAN ou TRANSACTION que j' ai vu sur ce forum
(j' ai bien compris le backup log , enfin presque )
cdlt
Salut,
oui tu peux les utiliser à chaud. Mais attention, si tu as des transactions ouvertes au moment de faire cela, ca peut foutre la grouille. Je te conseille de le faire dans une période pendant laquelle tu es sur qu'il n'y a aucune activitée sur la base (plage horaire de maintenance par exemple).
BACKUP TRAN est obsolète, tout comme DUMP TRAN. Il faut utiliser BACKUP LOG pour être sur que tu pourras migrer ta base dans des versions ultérieures de SQL Server.
Petite remarque : SCHRINKFILE réduit la taille physique du fichier. Mais cela n'est possible qui si les transactions dites 'mortes' ont d'abord été virées. Il faut donc faire un BACKUP LOG quoi qu'il arrive. Ensuite, tu peux réduire la taille de ton fichier mais cela n'a guère d'importance.
Cdlt
Bonjour,
Le fichier LDF correspondant au log file vient de passer de 1 G à 100M
sans que je jance la commande schrink....
simplement apres plusieurs sauvegardes completes base + log .
Quelqu' un a-t-il une explication ?
(ce comportement correspond mieux à la gestion des logs habituelle
dans les autres sgbd ( suppression des logs apres sauvegarde compléte) )
cdlt
A mon avis tu dois avoir l'option autoshrink log (réduire automatiquement) activée.
Merci de ta réponse,
ds quel menu je peux trouver cette option ?
cdlt
Tu fais bouton droit sur ta base => propriétés et c'est dans l'onglet options
l' option est cochée, je n' avais pas compris son utilité ...
Que font , en général, les dbas: cocher cette option ou non
car compacter des fichiers de données peut être dangereux , non ?
cdlt
En production, il vaut mieux la décocher pour des problématiques de performances.
Perso je conseille de ne pas mettre cette option pour les bases de grosses tailles et à accès fréquent. En effet, il vaut mieux avoir un fichier de 1Go "vide", plutot que de laisser SQL server agrandir le fichier dès qu'il a besoin de place. Question de performance bien sur.
Métaphore : il vaut mieux avoir une bouteille d'1l et la remplir goutte à goutte que de changer de taille de bouteille à l'ajout de chaque verre d'eau dans la bouteille devenue trop petite ;)
merci pour vos réponses,
je vais décocher cette case ( conseil donné aussi ds le bouquin microsoft
sql-server)
cdlt
C'est surtout aussi que ça risque de fragmenter ton disque à force de changer de taille tout le temps comme ça.
Ducho, post résolu non ?