Discussion :

[Bernardos]

Bonjour,
il y a quelques temps nous avions eu plusieurs discussions sur l'importance d'avoir un équilibre entre le nombre de fichier VLF pour le journal de transaction d'une base données et leurs volumes.
une bonne pratique qui était ressortie était de créer le fichier de log à 1Go et immédiatement augmenter par tranche de 1go jusqu'à arriver à la taille souhaitée. Ainsi on obtient un nombre de VLF ni trop grand ni trop petit.
Ma question est la suivante : cette réflexion est elle également valable pour le journal de transaction du tempdb ?
une autre question du même acabit : faut il également taillé le journal de transaction à +- 30 % de la taille réservée pour le tempdb?

Je me pose la question car chez un client j' ai 8 fichiers tempdb taillés à 12 Go chacun. ce qui me fait 96 Go et donc la logique voudrait que je size mon templog entre 25 et 30 Go.
Si je reviens sur ma technique, je size à 1 Go puis j'augmente progressivement. jusque là tout va bien.
mais si l'instance redémarre, le tempdb est détruit ainsi que son journal de transactions. Le journal de transaction est directement recréés à 25Go avec seulement 16 Fichiers VLF.
D'où ma question.
Cordialement,

[mikedavem]

Hello

Ma question est la suivante : cette réflexion est elle également valable pour le journal de transaction du tempdb ?

Cette réflexion reste valable même pour tempdb même si cette dernière utilise un système de logging différent des autres bases de données utilisateurs.

une autre question du même acabit : faut il également taillé le journal de transaction à +- 30 % de la taille réservée pour le tempdb?

Pour ma part cela dépend beaucoup de l'utilisation de tempdb (tout comme pour la taille des fichiers de données d'ailleurs). Le journal étant beaucoup moins sollicité que pour les autres bases de données, je taille au cas par cas. J'ai déjà vu des exemples comme toi avec une base de données à plus de 30 ou 40GB et avec un journal à 2 voir 4GB qui était suffisant. Bien souvent les tailles de fichiers de bases de donnée tempdb sont surestimés. Je peux donner une telle règle si l'espace disque est vraiment un problème et qu'il faut absolument faire du capacity planning à court terme. Maintenant comme tu disais dans un autre thread la place disque n'est plus vraiment un souci et je préfère dire au client de monitorer et ajuster.

A 30GB en taille initiale pour le Tlog de tempdb, ca te ferait 16 VLF avec une taille de VLF moyenne à 2GB .. ce qui ne me paraît pas être énorme non plus d'autant plus qu'à 70% de remplissage le journal sera vidé par un checkpoint (à moins d'une transaction ouverte qui empêcherait le vidage du journal).

++

[Bernardos]

Merci de ta réponse.
Imaginons que je décide malgré tout de mettre en place "quelque chose" pour automatiquement recréé mon tempdb à 1Go et juste après le démarrage, "quelque chose" qui lancerait mon script de croissance Go par GO jusque 25 GO.
quels seraient ces quelques choses.
je ne pense pas qu'il existe des trigger au démarrage de l'instance si?
Cordialement,

[mikedavem]

Si tu veux faire quelque chose dans le genre tu pourrais par exemple créer une procédure stockée qui ferait le boulot de grossissement de journal et qui serait exécutée à chaque redémarrage de SQL Server.
Pour cela tu peux regarder du coté de sp_procoption pour marquer ta procédure comme devant être exécutée au démarrage de SQL Server mais cela nécessite aussi que l'option de serveur 'scan for startup procs' soit activée.

Tu peux aussi faire un job SQL qui démarre à chaque redémarrage de l'agent (en tant que compte que l'agent peut redémarrer à chaque redémarrage du service SQL mais pas que ... il faudra donc modifier la logique d'exécution).

++

[SQLpro]

Perso, à défaut d'info je met 10 % pour le JT par rapport aux données.

L'augmentation par pas de 1 Go n'a plus d'intérêt depuis la modification de l'algo de calcul de VLF à partir de la version 2014...

A +

[Bernardos]

ok j'avais bien capté que l'algorithme changeait en 2014 mais j'ai 90% des instances sur lesquelles je travaille qui sont encore en 2005, 2008R2 et 2012(j'ai même de manière anecdotique des clients qui ont encore du sql server 2000) .
Merci de ta réponse
Cordialement,