Qu'est-ce qu'un fichier journal virtuel?
SQL Server divise le fichier journal des transactions pour chaque base de données en petits morceaux, appelés «fichiers journaux virtuels» (ou VLF pour faire court). Leur fonction principale est de marquer la troncature lors d'une sauvegarde de journal, c'est-à-dire que SQL Server effacera uniquement (et marquera disponible pour réutilisation) les VLF qui sont complètement vides. MSDN a un article sur le journal des transactions - architecture physique .
Qu'est-ce qui détermine le nombre de VLF?
Chaque fois qu'un fichier journal se développe (que ce soit via la croissance automatique ou la croissance manuelle), la nouvelle section du fichier journal est divisée en un certain nombre de VLF, uniquement en fonction de la taille de la nouvelle section (le journal des transactions existant est laissé seul). Ainsi, les petits paramètres de croissance automatique (c'est-à-dire la croissance automatique de 10% par défaut) entraîneront la création d'un grand nombre de VLF.
Quelles sont les implications d'un grand nombre de VLF?
Le problème principal d'un grand nombre de causes de VLF est:
- Récupération lente (la récupération est une phase pendant la restauration de la base de données où les transactions terminées sont écrites sur les pages de données et les transactions incomplètes sont annulées).
- Ralentissement des performances du lecteur de journaux dans une configuration de mise en miroir de bases de données.
- Ralentissement des performances lors de la création d'instantanés de base de données (notez que cela inclut également certaines fonctions
DBCCcar ils utilisent des instantanés de base de données en arrière-plan pour faciliter les vérifications de cohérence sans blocage).
Comment connaître le nombre de VLF dans ma base de données?
DBCC LOGINFOrenverra 1 ligne pour chaque VLF dans le journal des transactions de votre base de données. Cette question contient quelques scripts utiles pour l'appliquer à toutes les bases de données d'un serveur.
Combien de VLF est trop?
C'est un jugement que vous devrez faire vous-même. Ma règle de base personnelle est que moins de 50 ans ne valent pas la peine de jouer, et plus de 100 (ou plus) et je corrige les paramètres de croissance automatique et je note mentalement (dans la prochaine fenêtre de maintenance) de réduire et de repousser le journal (comme ci-dessous) .
Aidez-moi! J'ai onze milliards de VLF et ma récupération de base de données prend toute la journée!
Bref aperçu (du blog de Kimberly Tripp ):
- Assurez-vous que vous êtes la seule connexion active dans la base de données (alors faites-le pendant une fenêtre de maintenance)
- Sauvegardez le journal des transactions sur le disque (en utilisant
BACKUP LOG)
- Exécutez
DBCC SHRINKFILEavec TRUNCATEONLYpour réduire le fichier journal à la plus petite taille possible.
- Exécutez
ALTER DATABASE [...] MODIFY FILE [...] SIZE=newsizepour redimensionner votre journal des transactions en une seule étape **.
** Remarque - si vous avez un fichier journal très volumineux (des dizaines de Go ou plus), vous souhaiterez peut-être redimensionner en plusieurs étapes pour obtenir un nombre approprié de fichiers VLF avec une taille appropriée pour éviter les sauvegardes de journaux excessivement `` grosses ''. Étant donné que les VLF sont l'unité de troncature, ils déterminent également les tailles de sauvegarde des journaux, comme détaillé dans le blog de Kim .