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?
la source
SELECT @@VERSION;
? Selon ma réponse, ma première suggestion sera de vous assurer que vous êtes sur SP4 et la mise à jour cumulative la plus récente.Réponses:
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:
Et aussi ce script (et ceux dans les commentaires) de @SQLSoldier:
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.
la source
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
la source
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:
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
la source
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
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
la source