Comme son nom l'indique, TempDB est un espace de travail temporaire requis par SQL Server pour créer et conserver des objets intermédiaires et temporaires.
TempDB est un rouage important dans l'ensemble de l'appareil SQL Server et en tant qu'espace de travail temporaire - les données qu'il contient sont de nature transitoire. En d'autres termes, votre instance SQL Server recrée TempDB à chaque redémarrage, ce qui lui donne un bloc-notes propre avec lequel elle peut fonctionner.
- objets temporaires déclenchés par les demandes des utilisateurs
- objets requis par les processus système internes
- informations de version de ligne
Inutile de dire que si TempDB n'est pas configuré de manière optimale, cela peut entraîner des goulots d'étranglement opérationnels et une dégradation des performances. Vous vous demandez peut-être pourquoi vos requêtes avec des opérations de jointure et de tri complexes ne produisent pas les résultats aussi rapidement que prévu.
Il n'y a pas de moyen facile de généraliser les meilleures pratiques pour optimiser TempDB, les scénarios sont trop divers et ce qui fonctionne dans une situation donnée peut ne pas fonctionner dans une autre. Même si votre base de données est passée en production, il est toujours judicieux de continuer à revoir votre configuration TempDB pour vous assurer qu'elle est configurée comme il se doit.
L'un des problèmes les plus graves dans les performances de la base de données est la contention TempDB. Cela se produit lorsque plusieurs ressources nécessitent TempDB, mais qu'il n'y a qu'un seul fichier de données TempDB auquel accéder.
Les conflits TempDB peuvent entraîner de graves problèmes de performances et sont souvent interprétés à tort comme un blocage normal en raison de verrous de base de données. Souvent, il s'agit en fait d'un conflit verrouillé sur les pages d'allocation par des processus simultanés. Cela peut entraîner des goulots d'étranglement car chaque processus attend son tour. Comme le virage ne vient pas assez vite, les connexions sous-jacentes expirent et les processus doivent être désalloués.
Qu'est ce que tu obtiens? Un embouteillage virtuel de processus bloqués.
Comment résoudre les conflits TempDB et optimiser les performances de SQL Server ? Jetons un coup d'œil aux bases et travaillons à partir de là.
Nombre de fichiers de données – Combien dois-je avoir ?
Lorsque vous configurez SQL Server et conservez la configuration par défaut, vous n'avez qu'un seul fichier de données pour TempDB. Ne vous contentez pas de cette configuration.
L'une des règles empiriques souvent vantées est un seul fichier de données par cœur. Mais soyez prudent dans ce cas, si votre serveur a 12 cœurs, n'utilisez pas 12 fichiers de données TempDB à moins que cela ne soit justifié par les exigences de l'application et de la charge.
La meilleure option, compte tenu des configurations matérielles actuelles, consiste à commencer avec 8 fichiers de données primaires de taille égale et à voir si le problème de conflit est résolu. Progressez vers le haut et ajoutez quatre autres fichiers si nécessaire. L'assistant d'installation et de configuration de SQL Server 2016 dispose d'une fonctionnalité intégrée qui garantit que vous disposez d'un nombre suffisant de fichiers de données TempDB en détectant le nombre de cœurs de processeur et en créant automatiquement le nombre approprié de fichiers de données TempDB.
La taille compte – Comment la taille des fichiers de données doit-elle être configurée ?
Maintenant que nous avons couvert le nombre de fichiers, examinons la taille recommandée de chaque fichier. La taille par défaut est de 8 Mo, ce qui fournit à SQL Server un total de 64 Mo d'espace TempDB, insuffisant pour la plupart des environnements de production. Conserver Autogrowth est également une option, mais SQL Server devra s'arrêter et allouer plus d'espace disque pour les fichiers TempDB si nécessaire, ce qui ajoute une surcharge importante à SQL Server lors d'une exécution en production.
La pratique recommandée consiste à conserver les fichiers et l'espace initial requis pour chaque fichier à environ 80 à 90 % du volume sur lequel le TempDB est stocké. Les 10 à 20 % d'espace disque sont réservés à la mémoire virtuelle basée sur le système d'exploitation.
En d'autres termes, prédimensionnez les fichiers de données lors de l'installation ou modifiez la taille des fichiers dans l'environnement de production. Cela garantira que suffisamment d'espace disque est alloué à TempDB. Il est toujours recommandé de garder l'option Autogrowth activée à ce stade, mais idéalement, essayez de vous assurer que SQL Server n'a pas à allouer trop souvent de l'espace disque supplémentaire à la volée.
Fait intéressant, avant SQL Server 2017, il n'était pas possible d'allouer plus de 1 Go par fichier de données TempDB au moment de l'installation. Avec la dernière version, il est possible d'allouer jusqu'à 256 Go pour un fichier de données TempDB lors de l'installation.
Ce qui nous amène à la question suivante :
Où puis-je conserver les fichiers de données TempDB ?
Avant SQL Server 2012, dans le cas d'un environnement en cluster, TempDB devait être situé sur des disques partagés entre l'environnement en cluster, comme un réseau de stockage (SAN). À partir de SQL Server 2012, il est possible de conserver les fichiers de données TempDB sur un stockage local basé sur SSD. Cela réduit ce qui aurait été beaucoup de trafic entre le SAN partagé et l'instance SQL Server.
Dans la plupart des cas, la meilleure option pour l'emplacement TempDB est un SSD local dédié. Si cela n'est pas possible, le conserver sur un volume dédié, avec suffisamment d'espace disque pré-alloué, devrait résoudre les problèmes de performances probables. Assurez-vous de surveiller en permanence la santé du disque afin que les lectures et les écritures sur le disque soient effectuées à un niveau optimal.
Idéalement, le support doit être le plus rapide possible compte tenu de la configuration du serveur, des exigences de l'application et, enfin et surtout, du budget alloué.
Maintenant que nous avons examiné les bases, examinons les ajouts pertinents et bienvenus aux divers ajouts de SQL Server après SQL Server 2012.
Quoi d'autre de neuf ?
SQL Server 2016
Onglet dédié lors de la configuration
- Avec cette édition, SQL Server dispose d'un onglet dédié à la configuration de TempDB lors du workflow de configuration
- L'assistant d'installation et de configuration de SQL Server 2016 dispose d'une fonctionnalité intégrée qui garantit que vous disposez d'un nombre suffisant de fichiers de données TempDB au moment de l'installation de SQL Server. Il détecte le nombre de cœurs de processeur et crée automatiquement des fichiers de données TempDB, sous réserve d'un maximum de 8. Vous pouvez augmenter ce nombre après avoir configuré SQL Server.
Initialisation instantanée du fichier
- SQL Server doit allouer de l'espace disque pour TempDB lors de la configuration initiale, ainsi que lorsque la taille du fichier augmente lors d'une exécution en production. Cette répartition peut être possible de deux manières. La première consiste à initialiser l'espace disque inutilisé en écrivant des zéros avant d'allouer l'espace. La deuxième méthode consiste à allouer instantanément de l'espace fichier pour la croissance de TempDB.
- Dans la première méthode, SQL Server doit effectuer une opération gourmande en disque en initialisant chaque cluster de disques logiques. Dans cette méthode, les processus exécutés sur le serveur qui ont besoin de TempDB peuvent devoir attendre, créant un goulot d'étranglement.
- Si vous choisissez d'allouer instantanément de l'espace fichier à la place, le serveur SQL alloue instantanément de l'espace pour Autogrowth sans initialiser l'espace disque. Cela réduit les E/S de disque chaque fois qu'il y a une exigence de croissance automatique et garantit un meilleur débit et de meilleures performances. Bien qu'il ait été possible d'activer IFI dans les éditions précédentes, le processus était fastidieux. Dans cette édition de SQL Server, il est plus facile de configurer IFI au moment de la configuration du serveur.
- Les drapeaux de trace 1117 et 1118 sont redondants
SQL Server 2017
- Avant SQL Server 2017, il n'était pas possible d'allouer plus de 1 Go par fichier de données TempDB au moment de la configuration, ce qui signifiait que la taille du fichier TempDB devait être augmentée une fois la configuration terminée. Avec cette version, il est possible d'allouer jusqu'à 256 Go pour un fichier de données TempDB lors de l'installation.
Surveillance de TempDB
Garder une trace de TempDB peut être difficile. Comment savoir si vous rencontrez un conflit TempDB ? Qu'est-ce qui est alloué aux objets utilisateur, au magasin de versions ou aux objets internes ? Comment évoluent-ils dans le temps ? Quelles sessions consomment TempDB et dans quelle mesure ? Spotlight Cloud permet de répondre facilement à ces questions. Il surveille tous les aspects des performances de votre serveur SQL 24h/24 et 7j/7 et fournit des flux de travail analytiques approfondis pour résoudre tout problème de performances. Suivez votre TempDB au fil du temps et obtenez des avis d'experts automatisés sur la configuration.
En tant que solution SaaS, Spotlight Cloud est facile à installer et à configurer. Il conserve jusqu'à un an de données de performances, ce qui donne des informations de réglage imbattables. Les problèmes de performances peuvent être résolus en quelques secondes grâce à l'analyse des causes profondes. Ne perdez plus de temps à fouiller dans des scripts complexes - commencez votre essai de 30 jours maintenant. La surveillance des performances SQL Server de premier ordre commence maintenant.
