Comment la réduction d'un fichier journal SQL Server affecte-t-elle les performances?
J'ai une base de données SQL Server 2008 qui a un fichier de données d'environ 2 Go, mais le fichier journal dépasse 8 Go. Avec les bases de données antérieures à 2008, je pouvais utiliser le "journal de sauvegarde" et le TRUNCATE_ONLY option mais elle n'est plus disponible avec les bases de données 2008 et ultérieures.
J'ai un script qui tronque le fichier journal:
USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO
Cela tronque complètement le fichier journal, mais ma question est: cela affecte-t-il les performances?
J'effectue deux sauvegardes complètes par jour, donc le journal ne devrait pas vraiment être nécessaire en ce qui concerne le transfert de données.
Je recommande vraiment la lecture Importance d'une bonne gestion de la taille du journal des transactions par Paul S. Randal.
La quintessence est qu'il n'y a que deux très bonnes façons de faire la gestion du journal des transactions :
Soit aller avec des sauvegardes de fichiers LOG régulières et le fichier LOG réutilisera son espace après chaque sauvegarde LOG et ne se développera pas indéfiniment, ou
Utilisez le modèle de récupération SIMPLE et vous n'avez pas à vous soucier de la taille de votre fichier journal, car vous effectuez des sauvegardes complètes régulières.
Ce qui inquiète la troncature et les performances du fichier LOG , c'est que vous obtiendrez toujours un résultat de performance lorsque le fichier LOG doit être augmenté (une citation de ce qui précède- article de blog lié):
Si vous réduisez le journal, il augmentera à nouveau, ce qui entraînera peut-être une fragmentation VLF, et provoquera définitivement une pause de votre charge de travail pendant la croissance du journal, car le journal ne peut pas utiliser l'initialisation instantanée [. ..]
Mise à jour: Ne confondez pas la troncature du fichier LOG avec la réduction du fichier DATA. Le rétrécissement du fichier DATA est vraiment mauvais. Voir Pourquoi vous ne devriez pas réduire vos fichiers de données pour plus de détails.
OK d'abord oui le journal est nécessaire même avec les sauvegardes complètes quotidiennes si vous souhaitez recovoer en cas de problème. Nous sauvegardons notre journal des transactions toutes les 15 minutes. Le problème est que vous ne sauvegardez pas votre journal des transactions et c'est pourquoi le journal se développe de manière scandaleuse. Vous ne devriez presque jamais avoir besoin de réduire un journal des transactions si vous effectuez des sauvegardes correctes du journal des transactions.
Vous devrez sauvegarder la base de données avant de tronquer le journal. Je suggère de le faire en dehors des heures d'ouverture afin qu'aucune nouvelle donnée ne soit insérée entre la sauvegarde et la troncature. Ensuite, configurez les sauvegardes de journal des transactions appropriées afin que vous n'ayez plus jamais ce problème.
Quant à affecter les performances, bien sans connaître les détails du matériel et de l'utilisation de votre système, ce serait difficile à dire.
À quelle vitesse le journal des transactions se développe-t-il? S'il est plutôt rapide, vous affecterez les performances en les réduisant à presque rien, car il devra passer du temps à les repousser. Cela ne signifie pas que vous ne devriez pas le réduire de temps en temps, mais vous devez penser au problème de taille plutôt que de le réduire au minimum. Le perf est-il énorme? Probablement pas, mais cela dépend de la charge sur le serveur (nombre de transactions, etc.).
Une chose que je trouve problématique est "J'effectue 2 sauvegardes complètes par jour, donc le journal ne devrait pas vraiment être nécessaire en ce qui concerne le transfert de données." Le journal est extrêmement important pour les points entre vos sauvegardes complètes. Même deux fois par jour n'élimine pas la nécessité d'un fichier journal pour la récupération après sinistre, sauf s'il s'agit d'une base de données en lecture seule (si c'était le cas, vous ne verriez pas l'énorme augmentation du fichier journal, cependant).