Bonjour,
J'aimerais connaître l'impacte sur les performances d'une base de donnée si le nombre de fichier de log virtuel est élevé.
Qu'est-ce qui cause l'augmentation du nombre de fichier?
Qu'elle solution sont possibles pour corrigé?
Merci
Version imprimable
Bonjour,
J'aimerais connaître l'impacte sur les performances d'une base de donnée si le nombre de fichier de log virtuel est élevé.
Qu'est-ce qui cause l'augmentation du nombre de fichier?
Qu'elle solution sont possibles pour corrigé?
Merci
Bonjour,
Cela peut engendrer une écriture plus longue dans fichier du journal des transactions de tout changement de la base de données.Citation:
J'aimerais connaître l'impacte sur les performances d'une base de donnée si le nombre de fichier de log virtuel est élevé.
Cela peut aussi engendrer des sauvegardes de fichier du journal des transactions plus longue, avec des dégradations de performances durant celles-ci.
Enfin l'opération de restauration de la base de données peut être plus longue que si l'on avait un nombre raisonnable de fichiers virtuels.
Ceci est directement lié à la taille de l'incrément de grossissement du fichier. La règle est la suivante :Citation:
Qu'est-ce qui cause l'augmentation du nombre de fichier?
- Si l'incrément est < 64 Mo, on a 4 fichiers virtuels pour cet incrément
- Si l'incrément est >= 64 Mo et < 1Go, on a 8 fichiers virtuels pour cet incrément
- Si l'incrément est >= 1Go, on a 16 fichiers virtuels pour cet incrément
Depuis SQL Server 2014, La règle dépend du test suivant : la taille de l'incrément est-elle plus petite que 12.5% de la taille totale du fichier du journal des transactions ?
- Si oui, un nouveau fichier virtuel dont la taille est égale à celle de l'incrément configuré est ajouté
- Si non, la règle ci-dessus est appliquée
Donc dès SQL Server 2014, le nombre de fichiers virtuels nouvellement créés est plus faible qu'avec les versions précédentes.
Ce qui est important, c'est d'allouer la taille des fichiers (de données mais aussi du journal des transactions) à la création de la base de données.
A l'inverse, il ne faut pas avoir un nombre trop faible de fichiers virtuels, car le moteur ne peut marquer le fichier virtuel pour réutilisation que lorsque celui ci est plein et qu'il ne reflète plus aucune transaction encore active (i.e. encore "en vol", pas encore committée, ni rollbackée).
J'ai pour habitude d'allouer la taille des fichiers du journal des transactions par incréments d'1Go lors de la création d'une base de données, avec une taille totale variant entre 10 et 30% de la taille totale des fichiers de données. Donc je le crée à 1Go, puis je le fais grossir à 2Go, puis à 3Go, ... Cela permet, je trouve, de n'avoir ni trop peu ni pas assez de fichiers virtuels.
Vous pouvez rétrécir le fichier du journal des transactions autant que possible (cf. DBCC SHRINKFILE), puis le faire grossir à nouveau à la taille désirée (ALTER DATABASE maBASE MODIFY FILE(NAME = [nomLogiqueDuFichierDuJournalDesTransactions], SIZE = [TailleCible] GB). Réservez ce type de manipulation aux cas exceptionnels, et aux heures de faible trafic sur la base de données. Si votre base de données n'est pas en mode de récupération SIMPLE, il vous faut prendre une sauvegarde du fichier du journal des transactions, peut-être même deux, pour être sûr qu'il sera en grande partie marqué pour réutilisation. Avec DBCC LOGINFO, vérifiez sur quel fichier virtuel la colonne Status est à 2. Il y a autant de lignes retournées par cette instruction qu'il y a de fichiers virtuels. Le Status d'un fichier virtuel est à 2 s'il est actif. L'idéal est qu'il soit sur le premier fichier virtuel.Citation:
Qu'elle solution sont possibles pour corrigé?
@++ ;)
Autre façon de faire :
1) sauvegardes transactionnelle
2) ajout d'un nouveau fichier de JT bien dimensionné
3) SHRINKFILE de l'ancien fichier au minimum (1 Mo)
A +
Merci SQLPro.
Il doit être de possible supprimer l'ancien fichier ensuite, non ?
@++ ;)
pas obligé, il ne va l'utiliser qu'un court instant... Et un seul VLF
Oui, mais une transaction peut aussi s'étendre sur plusieurs VLF, et dans ce cas sur plusieurs fichiers physiques :weird:
Ce n'est pas obligé, mais c'est plus propre :)
@++ ;)