TempDB-Konflikt mit 24 physischen Tempdb-Dateien auf einer AMD Opteron-Box mit 48 Kernen

Ich habe gerade die folgende Benachrichtigung über eine Instanz von SQL Server 2005 erhalten. Die Instanz hat ein Verhältnis von Kern zu Tempdb-Datei von 2: 1 bei einer Gesamtanzahl von Tempdb-Dateien von 24 Dateien. Es sollte kein Konflikt stattfinden - wie würde ich die Quelle dieses Konflikts erkennen? TempDB und alle anderen Datenbanken befinden sich im SAN-Speicher über 10 GB Ethernet. Das SAN verfügt über 46 10k SAS-Laufwerke, die in einem RAID-60-Array konfiguriert sind. Dieses Array wird von mehreren VMWare-Servern und einem oder zwei Exchange-Servern gemeinsam genutzt.

Benachrichtigung von Idera SQL Diagnostic Manager:

08.11.2012 22:49:00, Tempdb-Konflikt (ms) auf MGSQL01 ist kritisch.

Auf MGSQL01 wurde ein Tempdb-Latch-Konflikt festgestellt. Die erkannte Gesamtwartezeit beträgt 1782 Millisekunden. Dies ist ein Hinweis darauf, dass die Leistung durch Konflikte bei Zuordnungszuordnungen in Tempdb beeinträchtigt wird. Wenn dies ein reguläres Problem ist, kann es durch Befolgen der Best Practices in Bezug auf die Anzahl der Tempdb-Dateien, die Größe und das E / A-Subsystem behoben werden.

PFS-Wartezeit: 1782 ms GAM-Wartezeit: 0 ms SGAM-Wartezeit: 0 ms

Tempdb-Konflikt (ms): Aktuelle Wartezeit für Tempdb-Zuordnungszuordnungen (GAM, SGAM und PFS) in Millisekunden. Diese Warnung kann nur bei Instanzen ausgelöst werden, auf denen SQL 2005 oder höher ausgeführt wird.

sql-server sql-server-2005

— Max Vernon
quelle

Heya Max, nur ein paar kurze Fragen. Ich musste mich kürzlich mit einem ähnlichen Problem befassen. -Ist es pagelatch_SH oder pageiolatch_SH? Ich bin mir ziemlich sicher, dass es in Ihrem Fall pagelatch_SH ist, aber ich möchte nur sicher sein. - Haben Sie erweiterte Ereignisse verwendet, um zu verfolgen, welche Abfragen die meisten PAGELATCH_SH-Wartezeiten aufweisen? Können Sie bitte auch Ihre Top 20 Wartestatistiken von SELECT * FROM SYS.DM_OS_WAIT_STATS ORDER BY 3 veröffentlichen? Was sagt Ihnen perfmon? Tritt auf dem TempDB-Laufwerk tatsächlich ein echter E / A-Konflikt auf? Spike bei MS?

— Ali Razeghi

Befinden sich die Wartezeiten auf einer PFS-Seite in einer bestimmten Datei oder in allen? Sind alle Tempdb-Dateien gleich groß? Wissen Sie, welche Art / Größe von Objekten in Tempdb zugewiesen wird? Werden temporäre Tabellen explizit abgeschnitten und vom App-Code gelöscht? Haben Sie darüber nachgedacht, das Trace-Flag 1118 zu implementieren?

— Straße

Hallo Max, schauen Sie hier sqlblog.com/blogs/adam_machanic/archive/2011/04/21/…

@ MaxVernon: Führen Sie als Faustregel immer T1118 aus. Es gibt wirklich keinen Grund, ohne es zu laufen

— Thomas Kejser

@maxvernon, ich +1 dein Verbindungselement. Schön.

— Edward Dortland

Das Ablaufverfolgungsflag 1118 erzwingt einheitliche Ausdehnungszuweisungen anstelle gemischter Seitenzuweisungen. Das Ablaufverfolgungsflag wird üblicherweise verwendet, um die Skalierbarkeit von TEMPDB zu unterstützen, indem SGAM und andere Zuordnungskonfliktpunkte vermieden werden. Wenn Sie SQL Server 2008 oder SQL Server 2005 haben und das Update angewendet wurde und immer noch TEMPDB-Konflikte auftreten, ziehen Sie das Trace-Flag 1118 in Betracht, um weitere Unterstützung bei der Lösung des Konflikts zu erhalten.

— Troy
quelle

Könnten Sie, vorzugsweise anhand eines Beispiels, erklären, wie der Wechsel von der gemeinsamen Zuweisung einzelner Seiten zu einer dedizierten Umfangszuweisung PFS-Konflikte löst?

— Edward Dortland