DDL-Konflikt auf TempDB

Ich habe einen SQL Server 2005 Standard x64, bei dem in den letzten Monaten Probleme mit TempDB-DDL-Konflikten aufgetreten sind. Auf dem Server tritt ein Konflikt mit der Warte-Ressource 2: 1: 103 auf (der Wartetyp ist PAGELATCH_EX).

Das Problem tritt sporadisch auf, wenn der Server unter angemessener Last steht. Ich habe die Rate "Temp Tables for Destruction" überwacht und sie kann in Zeiten, in denen Probleme mit PAGELATCH_EX in 2: 1: 103 auftreten, auf über 5.000 springen. Nach dem, was ich gelesen habe, sollte dieser Zähler die meiste Zeit 0 sein, aber unser Zähler scheint die meiste Zeit irgendwo zwischen 300 und 1100 zu bleiben. Der Zähler geht nur auf 0, wenn sich nur sehr wenige Benutzer im System befinden.

Wie kann ich eingrenzen, was den DDL-Konflikt auf Tempdb verursacht, ohne nach einer Nadel in einem Heuhaufen suchen zu müssen?

Ich habe genau dieses Problem gesehen und der Hotfix, der letztendlich veröffentlicht wurde, um es zu beheben, war tatsächlich ein direktes Ergebnis meines Falls mit Microsoft CSS. Es gibt keinen öffentlichen KB-Artikel für das Update. Stellen Sie sicher, dass Sie Service Pack 4 und das neueste kumulative Update auf SQL Server angewendet haben (zum Zeitpunkt des Schreibens ist dies das kumulative Update Nr. 3 (9.00.5259) ).

Bis zur Veröffentlichung des Hotfixes schlug Microsoft vor, die Erstellung von # temp- Tabellen einfach einzustellen (ähnlich wie bei KB # 916086 ). Da dies ein erhebliches Umschreiben von Dutzenden und Dutzenden von Berichtsverfahren bedeutet hätte, bestand die Problemumgehung in meinem Fall (unabhängig von Ablaufverfolgungsflags oder temporärem Dateilayout) darin, unseren Cluster jedes zweite Wochenende neu zu starten. Yuck.

Um die Verwendung von Tempdb aufzuspüren, gibt es verschiedene Skripte, die helfen können, z. B. Adam Machanics sp_whoIsActive , insbesondere:

• sp_whoisactive: Analysieren von Tempdb-Konflikten
• Wie kann festgestellt werden, welche Abfrage das temporäre Transaktionsprotokoll ausfüllt?

Und auch dieses Skript (und eines in den Kommentaren) von @SQLSoldier:

• TempDB-Konflikt auflösen

Ich würde sicherstellen, dass alle Ihre Cursor verwenden LOCAL STATIC READ_ONLY FORWARD_ONLY(siehe dies und das ) und prüfen, ob es bekannte teure Abfragen gibt, die #temp tables / @table-Variablen, CTEs in großem Umfang verwenden oder unnötige Sortierungen enthalten oder zu Hash-Joins führen ... all dies kann zu dem Problem beitragen (ich bezweifle, dass Sie eine goldene Ursache finden werden). Die einfachste Lösung als "Bang-for-Your-Buck" -Startpunkt ist die Verwendung geeigneter und kostengünstiger Cursoroptionen anstelle der Standardeinstellungen.

In der Zwischenzeit würde ich (a) CU # 3 installieren und (b) PSS aufrufen. Sagen Sie ihnen, dass Sie nach einem ganz bestimmten Fix suchen , der bereits als Fehler bestätigt und als privater Hotfix für andere Benutzer freigegeben wurde: "VSTS # 109112 - Der verzögerte Drop der temporären Tabelle lässt sich für bestimmte Workloads nicht skalieren." Möglicherweise müssen Sie die Fallgebühr zunächst bezahlen, aber da es sich um einen Fehler handelt, sollte die Gebühr erstattet werden.

Sie benötigen wahrscheinlich das Trace-Flag 1118

Siehe zuerst Paul Randals Mythen über Tempdb und auch seinen Artikel über TF 1118

Der TF ist hier in KB 328551 beschrieben

Ich habe keine direkte Erfahrung damit, aber es klingt wie das, was ich gelesen habe

Ich gehe davon aus, dass Sie Ihre TempDB-Datendateien bereits aufgeteilt haben, um Konflikte zu lindern (natürlich zuerst über die Vorproduktion). Wenn Sie mutiger sind, ziehen Sie das Trace-Flag in Betracht, auf das sich Paul Randal maßgeblich bezieht: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-sollte-immer-eine-Datendatei-pro-Prozessor-core.aspx haben

In Bezug auf die Ursache der Schmerzen müssen Sie einige Nachforschungen anstellen:

• Hat dies gerade erst begonnen? Was hat sich verändert?
• Befindet sich der Server unter Speicherdruck, müssen also Sortierungen in TempDB durchgeführt werden?
• Gibt es DBA-Prozesse wie CheckDB oder Online-Neuindizierung?
• Werden exotischere Isolationsstufen oder Service Broker verwendet? Schauen Sie sich sys.databases an

Am Ende dieses Microsoft TempDB-Dokuments befindet sich eine nette Abfrage, um herauszufinden, was Tempdb verwendet: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Wenn Sie immer noch versuchen, dies aufzuspüren, hatte ich kürzlich ein ähnlich seltsames Leistungsproblem mit synchronen Tabellenabbrüchen. Wenn Sie eine große Anzahl von Datenbanken (> 100 oder so) auf einer SQL-Instanz haben, auf der SQL 2005 ausgeführt wird, und Sie viele temporäre Anweisungen zum Erstellen und Löschen von Tabellen haben, können Sie langsame temporäre Tabellen löschen. Das Überprüfen der von sys.dm_db_index_usage_stats zurückgegebenen Zeilenanzahl kann dies als Schuldiger so gut wie sofort ausschließen.

KB-Artikel beschreibt das Problem. http://support.microsoft.com/kb/2003031

Die Abfrageleistung nimmt ab, wenn sys.dm_db_index_usage_stats eine große Anzahl von Zeilen enthält

Stellen Sie sich das folgende Szenario vor:

In Microsoft SQL Server 2005 führen Sie häufig DDL-Vorgänge aus, bei denen viele Tabellen gelöscht und neu erstellt werden (insbesondere temporäre Tabellen in der Tempdb-Datenbank). Sie haben eine große Anzahl von Einträgen (100.000 oder mehr) in der dynamischen Verwaltungsansicht (DMV) von sys.dm_db_index_usage_stats.

Entnommen meiner akzeptierten Antwort auf diese Frage. Dort gibt es auch einige Details. Langsame temporäre Tabelle fällt in SQL 2005