Meilleure pratique pour le fichier journal tempdb

11

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?

sql-server sql-server-2012 tempdb Alexandre Jobin
la source
4
Il n'y a pas de réponse magique à cela, sauf que je ne désactiverais pas la croissance automatique pour les données tempdb ou le journal, sauf si vous voulez absolument que le système s'arrête de manière stridente si la croissance automatique est nécessaire. Je ne désactiverais jamais la croissance automatique sur n'importe quel fichier, car peu importe la façon dont vous planifiez, il y a toujours des situations anormales.
Aaron Bertrand
2
@AaronBertrand: activer la croissance automatique sur un tempdb de taille normale n'aidera pas. Ils sont déjà à leur maximum, ils peuvent être sur le disque. Il n'y a plus d'espace disque qu'ils peuvent utiliser de toute façon. C'est pourquoi j'ai désactivé la croissance automatique.
Alexandre Jobin
2
Peu importe qu'il soit désactivé ou non, n'est-ce pas? Si une croissance automatique est requise, elle échouera dans les deux cas. Si vous le laissez activé, c'est une chose de moins que vous devez changer lorsque vous réalisez que vous devez peut-être le déplacer vers un disque plus grand.
Aaron Bertrand
1
PS 8 x 20> 100
Aaron Bertrand
1
Le fractionnement de vos fichiers n'est pas nécessairement "une bonne configuration". Cela dépend de la configuration de votre matériel; que vous n'avez pas fourni.
Paul

Réponses:

5

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.

mrdenny
la source
0

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.

Robert Gannon
la source
0

Aaron a raison de configurer TempDB dépend de beaucoup de variables telles que si vous prévoyez d'utiliser l'isolement des instantanés, etc. Voici un livre blanc SQL 2005 plus ancien de MS / TN qui pourrait vous aider car une bonne partie de celui-ci s'applique toujours. Jetez un œil à l '"Espace requis pour la journalisation tempdb" afin de voir quels types de transactions sont enregistrées 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'autograndissement 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 recommanderais d'éviter cela si possible, en particulier dans les situations à volume de transaction élevé.

Miketk
la source