Division de TempDB en plusieurs fichiers égaux au nombre de CPU

L'article Meilleures pratiques SQL Server tempdb Augmenter les performances suggère que je devrais diviser tempdben un nombre de fichiers égal au nombre de cœurs. Donc, pour 4 cœurs, vous obtenez 4 fichiers.

En ayant le plus grand nombre de fichiers, vous pouvez augmenter le nombre d'opérations d'E / S physiques que SQL Server peut envoyer au disque à tout moment. Plus SQL Server peut pousser d'E / S jusqu'au niveau du disque, plus la base de données s'exécutera rapidement. Avec les bases de données standard, SQL Server peut mettre en cache une grande quantité de données dont il a besoin en mémoire. En raison de la nature à haute écriture de tempdb, les données doivent être écrites sur le disque avant de pouvoir être mises en cache dans la mémoire.

Bien que cela semble bon en théorie, est-ce vraiment aussi bon qu'une optimisation générale? Est-ce quelque chose qui ne peut s'appliquer qu'à des systèmes spécifiques où les E / S sont très élevées?

Un ratio de 1/4 à 1/2 fois le nombre de fichiers de données TempDB sur les cœurs de machine est depuis longtemps la recommandation ...

Mais il y a maintenant encore de meilleurs conseils. Au PASS en 2011, mon bon ami Bob Ward, qui est le meilleur gars du support produit SQL, a adopté une nouvelle formule: si vous avez moins de 8 cœurs, utilisez #files = #cores. Si vous avez plus de 8 cœurs, utilisez 8 fichiers et si vous voyez des conflits en mémoire, ajoutez 4 fichiers supplémentaires à la fois. [lien]

La dernière phrase a toujours été pertinente. Si vous ne voyez pas de conflit, pourquoi ajouter des fichiers supplémentaires? Pour jouer en toute sécurité, la plupart ajouteront 2 à 4 fichiers comme point de départ pour la majorité des versions, mais au-delà, mesurer et réagir.

Comme la plupart des directives générales , c'est une simplification excessive dans sa lumière la plus positive. Au mieux, c'est un bon point de départ (à condition que vous ne respectiez pas le ratio 1: 1 core: fichier de données avec une grande quantité de cœurs).

Il n'y a aucun remplacement pour une conception appropriée et une surveillance et un suivi de base appropriés . La raison d'avoir plusieurs fichiers de données pour tempdb est de réduire et d'atténuer les conflits de page d'allocation. Il existe de nombreux articles publiés sur la façon de surveiller cette contention et de prendre des mesures en conséquence. Voici quelques ressources:

Décomposition du conflit TempDB (partie 1)
Décomposition du conflit TempDB (partie 2)
Analyse du conflit Tempdb
Optimisation de la configuration tempdb avec les événements étendus SQL Server 2012

Mais pour répondre à votre question, non, ce n'est pas une partie difficile à configurer et à oublier de tempdb .