Version imprimable
Bonsoir,
J'ai lancé un SHRINKFILE sur le LOG d'une base synchronisée (Alwayson):
Pourtant, j'ai Backup LOG ...Code:
2
3
Merci.
A+
Il y a sans doute eu une opération de sauvegarde au moment du lancement de votre commande. Désactivez temporairement les sauvegardes transactionnelle si vous voulez faire une telle manœuvre.
Mais la vrai question est pourquoi faire cette manœuvre. Je soupçonne que vous ,ne maîtrisez pas ce qui se passe dans votre SGBDR et tentez cette commande un peu au hasard…
A +
Bonjour,
C'était pour vider le journal, y a bien un backup ttes les 2 heures mais il a pris un peu de poids je voulais "shrinker".
Merci.
A+
Vous ne videz pas le journal avec la commande SHRINK en AUCUNE façon !
Le SHRINK est un rétrécissement du fichier qui ne peut s'exercer que s'il à a de la place disponible ! Il ne vide rien, il permet juste de supprimer du fichier de transaction la place vide… Il faut donc commencer par avoir de la place vide, et le vidage se fait par la sauvegarde transactionnelle uniquement (dans votre cas avec AlwaysOn).
Le problème c'est que si votre fichier a crû c'est qu'il y a eu des transactions. Il y a donc toutes les chances que cette croissance reprenne tôt au tard… (sauf si vous demandez aux utilisateurs de faire la grève ou bien que vous les tuez !)
Ainsi vous allez détruire les performances dont le serveur a besoin à des moments critiques….
Ce genre de diminution de fichier est l'une des pires choses à faire en matière de gestion des fichiers des bases…..
Vous êtes exactement le pseudo dba dont je parle dans cet article :
https://blog.developpez.com/sqlpro/p..._fichiers_et_t
A +
Bonjour,
C'était just pour libérer de l'espace disque en urgence suite à une activité exceptionnelle si no c'est blocage total ...
Bonne journée.
Merci.
Une autre solution est de créer un second fichier de journalisation des transactions sur un autre disque.
Assurez-vous cependant que le chemin existe bien sur tous les serveurs esclave AlwaysOn.
A +
Merci bcp.
A+