Avant d’envisager une réduction du fichier du journal des transactions, il convient de connaître le nombre de fichiers virtuels que contient le fichier du journal des transactions.
On peut également envisager de le faire grossir de nouveau pour avoir moins de fichiers virtuels, et obtenir de meilleures performances pour les transactions manipulant un grand volume de données.
Voyons comment faire cela :
Il s’agit ici d’utiliser une bonne vieille commande DBCC non documentée : DBCC LOGINFO.
Chaque ligne retournée par l’instruction DBCC LOGINFO représente en fait un fichier virtuel.
Sur une base de données de production pour laquelle le fichier du journal des transactions est sauvegardé régulièrement mais où la croissance automatique a été mal gérée, on peut obtenir un grand nombre de fichiers virtuels.
En effet, le fichier du journal des transactions grossit suivant le paramètre d’agrandissement de celui-ci pour la base de données considérée.
Si celui-ci est petit, nous aurons un nombre de fichiers virtuels élevé.
D’où, encore une fois, l’importance de tailler les fichiers de la base de données lors de la création de celle-ci.
En fait, les fichiers virtuel en cours d’utilisation ont leur valeur de colonne Status égale à 2.
Si l’on veut donc savoir combien sont en cours d’utilisation, il suffit d’exécuter le petit script suivant :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | DECLARE @vlf TABLE ( FileId tinyint , FileSize bigint , StartOffset bigint , FSeqNo int , Status tinyint , Parity tinyint , CreateLSN varchar(21) ) INSERT @vlf EXEC ('DBCC LOGINFO') SELECT SUM(FileSize) / 1048576 AS total_file_size_MB , SUM ( CASE Status WHEN 2 THEN FileSize ELSE 0 END ) / 1048576 AS file_size_in_use_MB , COUNT(*) AS VLF_amount , SUM ( CASE Status WHEN 2 THEN 1 ELSE 0 END ) AS VLF_in_use FROM @vlf |
Bonne gestion du fichier du journal des transactions
ElSuket
Merci les gars
Pour la taille de CreateLSN, quelle taille avez-vous mis ?
@++
Attention, la taille du champ « CreateLSN » est parfois trop petite
Petite precision sur le nombre de vlf crees par taille d’allocation supplementaire au transaction log:
chunks less than 64MB = 4 VLFs
chunks of 64MB and less than 1GB = 8 VLFs
chunks of 1GB and larger = 16 VLFs
Les fichiers logs ne benificient pas de l’instant file initialisation ce qui force le moteur a remplir le nouvel espace allouer de 0 car un bout de disque pourrait contenir des informations similaires a un log file.
Etant donne l’aspect cyclique du transaction log, un bit de parite fixe a 64 ou 128 permet de definir ou un VLF « reutilise » s’arrete.
Cheers