Meilleure pratique pour le fichier journal tempdb
J'ai lu de nombreux blogs ici et là sur la façon de configurer les fichiers de données tempdb mais je n'ai trouvé aucune information concernant le fichier journal tempdb .
Voici la stratégie que j'utilise actuellement avec mon tempdb:
- J'ai utilisé les recommandations de Paul Randal sur la façon de diviser mes fichiers de données tempdb
- J'ai défini la taille de mes fichiers de données tempdb sur leur croissance automatique maximale et désactivée. Par exemple, j'ai 100 Go d'espace disque libre et je définis la taille de mes 8 fichiers de données tempdb à 10 Go chacun. Cela empêche la fragmentation sur le disque comme recommandé par Brent Ozar et j'ai également 20 Go de libre pour mon fichier journal.
Mais comme je l'ai dit, personne ne parle du fichier journal tempdb . Que dois-je en faire? Sur ma configuration, ce fichier est au même endroit que les fichiers de données tempdb. Quelle est la taille et la valeur de croissance automatique que je dois utiliser avec le fichier journal tempdb?
Cela dépend vraiment de la quantité de données qui circulera dans le journal des transactions. Regardez la taille du journal aujourd'hui. Vous devez configurer le journal pour qu'il ait au moins cette taille au démarrage de SQL. Pour la plupart de mes clients, ils se retrouvent avec un journal des transactions de 3-4 Gig pour le tempdb, qui ne contient que quelques VLF et tout fonctionne bien et en douceur.
Aaron a raison de configurer TempDB dépend de beaucoup de variables telles que si vous envisagez d'utiliser l'isolement des instantanés, etc. Voici un ancien livre blanc SQL 2005 de MS/TN qui pourrait vous aider car un une bonne partie s'applique toujours. Jetez un œil à "l'espace requis pour la journalisation tempdb" afin de voir quels types de transactions sont consignés dans le journal tempdb afin de pouvoir configurer les choses en conséquence. Ce sera probablement le genre de chose que vous devrez surveiller et modifier au fil du temps.
En ce qui concerne l'authogrowth pour tempdb, j'ai à contrecœur désactivé cela sur un serveur de rapports dans le passé et le comportement que j'ai rencontré était qu'il a provoqué l'abandon et la restauration de la longue transaction, ce qui a instantanément libéré l'espace du journal, mais cela pourrait dépendre de la type de transaction qui dans mon cas était des tris massifs et des opérations de jointure (requêtes de rapport mal écrites). Je suis d'accord avec Aaron et je recommanderais d'éviter cela si possible, en particulier dans les situations à volume de transaction élevé.
On m'a toujours dit de stocker les fichiers journaux sur une baie physique/disque distincte si votre matériel peut écrire simultanément dans les données et se connecter en même temps pour améliorer les performances. Je suppose que la limitation qui a engendré votre limite tempdb 20G pourrait définir une réponse pour la taille. Pour la croissance automatique, cela peut dépendre des transactions que vous exécutez ainsi que de l'espace libre disponible et d'autres ressources sur le disque. Je choisis généralement arbitrairement 1/6 de la taille initiale.