J'ai vu que notre base de données a le modèle de récupération complète et a un journal des transactions de 3 Go. Au fur et à mesure que le journal s'agrandit, quel effet cela aura-t-il sur les performances de la base de données et sur les performances des applications accédant à la base de données?Comment un grand journal de transactions affecte-t-il les performances?
JD
La meilleure pratique recommandée consiste à affecter un fichier journal de transaction SQL Server à son propre disque ou LUN. Ceci a pour but d'éviter la fragmentation du fichier journal des transactions sur le disque, comme d'autres affiches l'ont mentionné, et d'éviter/minimiser les conflits de disque.
Le scénario idéal consiste à faire en sorte que votre administrateur de base de données alloue suffisamment d'espace de journal pour votre environnement de base de données, c'est-à-dire pour allouer x Go de données en une fois. Sur un disque dédié, cela crée une allocation contiguë, évitant ainsi la fragmentation.
Si vous avez besoin de développer votre journal des transactions, vous devriez vous efforcer de le faire en segments importants afin d'essayer d'allouer de manière contiguë.
Vous devez également chercher à ne pas réduire votre fichier journal des transactions, car la réduction répétée et la croissance automatique peuvent entraîner la fragmentation du fichier de données sur le disque. Je pense qu'il est préférable de considérer la propriété de base de données autogrowth comme une sécurité intégrée, c'est-à-dire que votre administrateur de base de données surveille de manière proactive l'espace des journaux de transaction (peut-être en configurant des alertes). exigences, mais la propriété de croissance automatique peut être en place pour assurer que votre base de données peut continuer à fonctionner normalement en cas de croissance inattendue. Un fichier journal de transactions plus volumineux en lui-même, si cela ne nuit pas aux performances du serveur SQL. Dans la mesure où vous gérez votre taille de journal globale et l'allocation d'espace supplémentaire de manière appropriée, vous ne devriez pas être concerné.
Si le journal se fragmente ou a besoin de se développer, il va ralentir l'application.
Si vous n'effacez pas le journal des transactions périodiquement en effectuant des sauvegardes, le journal sera plein et consommera tout l'espace disque disponible.
De plusieurs façons.
Si votre système est configuré pour développer automatiquement le journal des transactions, au fur et à mesure que le fichier grossit, votre serveur SQL devra faire plus de travail et vous risquez d'être ralenti. Lorsque vous manquez d'espace, vous n'avez plus de chance et votre base de données arrête de prendre de nouvelles transactions.
Vous devez obtenir avec votre DBA (ou peut-être vous êtes le DBA?) Et effectuer des sauvegardes fréquentes et périodiques des journaux. Sauvegardez-les de votre serveur sur un autre système de sauvegarde dédié. Lorsque vous sauvegardez le journal, l'espace dans votre fichier journal existant sera récupéré, ce qui empêchera le journal d'être beaucoup plus volumineux. La sauvegarde du journal des transactions vous permettra également de restaurer votre base de données à un moment spécifique après votre dernière sauvegarde complète ou différentielle, ce qui réduit considérablement vos pertes de données en cas de panne du serveur.
Si le fichier journal augmente plus rapidement, vous obtiendrez de nombreux fichiers journaux virtuels Ces fichiers journaux virtuels ralentiront les opérations de démarrage, de restauration et de sauvegarde de la base de données.
ici est un article qui montre comment résoudre ce problème: http://www.sqlserveroptimizer.com/2013/02/how-to-speed-up-sql-server-log-file-by-reducing-number-of-virtual-log-file/
C'est un titre trompeur. Je suis sûr que c'est juste une faute de frappe, mais "grande transaction" et "grand journal des transactions" sont des choses très différentes, comme vous le savez sûrement! –