Conflit DDL sur TempDB

J'ai un SQL Server 2005 Standard x64 qui rencontre des problèmes avec la contention DDD TempDB au cours des derniers mois. Le serveur rencontrera des conflits sur la ressource d'attente 2: 1: 103 (le type d'attente étant PAGELATCH_EX).

Le problème semble se produire sporadiquement lorsque le serveur est sous une charge décente. J'ai surveillé le taux de "tables temporaires pour la destruction" et il peut atteindre 5 000+ pendant les périodes où nous avons des problèmes de PAGELATCH_EX sur 2: 1: 103. D'après ce que j'ai lu, ce compteur devrait être 0 la majorité du temps, mais le nôtre semble rester de 300 à 1100 la majorité du temps. Le compteur ne passe à 0 que lorsqu'il y a très peu d'utilisateurs sur le système.

Comment puis-je réduire ce qui cause la contention DDL sur tempdb sans avoir à chercher une aiguille dans une pile de foin?

J'ai vu ce problème et le correctif qui a finalement été publié pour le résoudre était en fait le résultat direct de mon cas avec Microsoft CSS. Il n'y a aucun article public de la base de connaissances pour le correctif. Veuillez vous assurer que vous avez appliqué le Service Pack 4 et la mise à jour cumulative la plus récente à SQL Server (au moment de la rédaction, il s'agit de la mise à jour cumulative # 3 (9.00.5259) ).

Jusqu'à la publication du correctif, la suggestion de Microsoft était simplement d'arrêter de créer des tables #temp (un peu comme KB # 916086 ). Étant donné que cela aurait signifié une réécriture substantielle de dizaines et de dizaines de procédures de rapport, la solution de contournement dans mon cas (indépendamment des indicateurs de trace ou de la disposition des fichiers temporaires) était de redémarrer notre cluster tous les week-ends. Beurk.

Afin de suivre l'utilisation de tempdb, plusieurs scripts peuvent vous aider, par exemple, voir sp_whoIsActive d'Adam Machanic , en particulier:

• sp_whoisactive: Analyse de la contention Tempdb
• Comment identifier quelle requête remplit le journal des transactions tempdb?

Et aussi ce script (et ceux dans les commentaires) de @SQLSoldier:

• Briser les conflits TempDB

Je m'assurerais que tous vos curseurs utilisent LOCAL STATIC READ_ONLY FORWARD_ONLY(voir ceci et cela ), et voir s'il existe des requêtes coûteuses connues qui utilisent largement les tables #temp / les variables @table, CTE, ou peuvent contenir des tris inutiles ou conduire à des jointures de hachage ... qui peuvent tous contribuer au problème (je doute que vous trouviez une cause en or). La solution de balayage la plus simple en tant que point de départ "en avoir pour son argent" sera d'utiliser des options de curseur appropriées et peu coûteuses au lieu des valeurs par défaut.

En attendant, je (a) installerais CU # 3 et (b) appellerais PSS. Dites-leur que vous recherchez un correctif très spécifique qui a déjà été confirmé en tant que bogue et diffusé à d'autres utilisateurs en tant que correctif privé: "VSTS # 109112 - La suppression différée de la table temporaire ne s'adapte pas à certaines charges de travail." Vous devrez peut-être payer les frais de dossier au départ, mais comme il s'agit d'un bug, les frais doivent être remboursés.

Vous avez probablement besoin d'un indicateur de trace 1118

Découvrez d'abord les mythes de Paul Randal sur tempdb et son article sur TF 1118

Le TF est décrit ici dans KB 328551

Je n'ai aucune expérience directe de cela, mais cela ressemble à ce que j'ai lu

Je suppose que vous avez déjà fractionné vos fichiers de données TempDB pour essayer d'atténuer les conflits (via la pré-production d'abord évidemment). Si vous êtes plus courageux, considérez l'indicateur de trace auquel Paul Randal fait référence avec autorité: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-devrait-toujours-avoir-un-fichier-de-données-par-processeur-core.aspx

En ce qui concerne la cause de la douleur, vous devez effectuer un travail d'enquête:

• cela vient-il de commencer? Qu'est ce qui a changé?
• le serveur est-il sous pression mémoire, donc les tris doivent être effectués dans TempDB?
• Existe-t-il des processus DBA comme CheckDB ou une réindexation en ligne en cours d'exécution?
• utilise-t-on des niveaux d'isolement plus exotiques ou un courtier de services? jetez un œil à sys.databases

Il y a une belle requête au bas de ce document Microsoft TempDB pour essayer de déterminer ce qui utilise tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Si vous cherchez toujours à suivre cela, j'ai récemment eu un problème de performances tout aussi étrange avec les baisses de table synchrones. Si vous avez un grand nombre de bases de données (> 100 ou plus) sur une instance SQL exécutant SQL 2005 et que vous disposez de nombreuses instructions de création et de suppression de table temporaire, vous pouvez obtenir des suppressions de table temporaire lentes. La vérification du nombre de lignes renvoyées par sys.dm_db_index_usage_stats peut éliminer cela presque tout de suite en tant que coupable.

L'article de la base de connaissances décrit le problème. http://support.microsoft.com/kb/2003031

Les performances des requêtes diminuent lorsque sys.dm_db_index_usage_stats a un grand nombre de lignes

Considérez le scénario suivant:

Dans Microsoft SQL Server 2005, vous effectuez fréquemment des opérations DDL qui impliquent la suppression et la recréation d'un grand nombre de tables (en particulier les tables temporaires dans la base de données tempdb). La vue de gestion dynamique (DMV) sys.dm_db_index_usage_stats contient un grand nombre d'entrées (100 000 ou plus).

Tiré de ma réponse acceptée à cette question. Il y a aussi plus de détails. Ralentissement de la table des températures au sql 2005