TempDB-Konflikte

Wir haben eine aktive OLTP 40GB Datenbank auf SQL Server 2014 SP1. Es wurde festgestellt, dass Abfragen langsam sind, da IO_Completion wartet, die Länge der Datenträgerwarteschlange auf 900 steigt und SQL Server nicht mehr reagiert. Was wir versucht haben:

1. Starten Sie die Instanz neu und innerhalb einer Minute verhält es sich genauso.

2. Nach dem zweiten Neustart haben wir die Anfangsgröße jeder Tempdb-Datendatei geändert (es wurden 16 Datendateien erstellt) und sie funktioniert nun ordnungsgemäß.

Anmerkung: Wir verwenden Tabellenvariablen für Zwischenergebnismengen. Diese Ergebnismengen sind sehr klein.

Es passierte zweimal im Monat. Jedes Mal, wenn ich den Datendateien manuell etwas Speicherplatz hinzufüge, funktioniert sie normal. Das Interessantere ist, dass das gleiche Setup (gleiche Hardware, gleiche Ordner- und Dateieinstellungen, gleiche Arbeitslast), das wir unter SQL Server 2008 R2 und SQL Server 2012 haben, einwandfrei funktioniert.

Bitte helfen Sie uns, eine dauerhafte Lösung zu finden.

Die anfängliche Größe aller Datendateien ist 1000 MB, die aktuelle Größe beträgt jeweils 1500 MB. Alle sind identisch. Das automatische Wachstum beträgt jeweils 100 MB. Davor hatten wir mit PFS- und GAM-Seiten zu kämpfen und sind auf 16 gestiegen. Das Problem wurde behoben. Beide Trace-Flags 1117 und 1118 sind aktiviert. 24 Kerne auf 2 NUMA-Knoten. Alle Datendateien befinden sich auf demselben Volume. Einfache Festplatte, kein SAN.

Die Instanz befindet sich auf einem physischen Computer. Abfragen mit Tabellenvariablen und Abfragen mit Hash-Joins erzeugen am häufigsten Wartezeiten für IO_Completion.

Die ausführliche Antwort von wBob veranlasste uns, genauer zu suchen. Wie haben wir es vorher verpasst:

Das automatische Anwachsen der Datei 'templog' in der Datenbank 'tempdb' wurde vom Benutzer abgebrochen oder ist nach 7704 Millisekunden abgelaufen. Verwenden Sie ALTER DATABASE, um einen kleineren FILEGROWTH-Wert für diese Datei festzulegen oder eine neue Dateigröße explizit festzulegen.

Dies haben wir im Protokoll gefunden, wenn ein solches Problem auftritt. Wir verschieben TempDB, um schnelles Laufwerk zu trennen.

Ich denke, Sie haben Ihre Tempdb überfragmentiert und es gibt eine Inkongruenz zwischen der Server-CPU und dem Festplatten-Setup, aber lassen Sie uns einige weitere Informationen sammeln:

Fragen / Weitere Informationen erforderlich

• Bitte bestätigen Sie den Prozessornamen und den Prozessortyp (ich versuche im Grunde festzustellen, ob es sich um 2 x Hex-Core mit HT handelt). Verwenden Sie die Systeminformationen (z. B. Systemsteuerung> System und Sicherheit> System unter Windows Server 2012 R2) und / oder das Sysinternals-Tool CoreInfo zur Bestätigung die .
• Bitte bestätigen Sie den Server maxdop (zB EXEC sp_configure 'max degree of parallelism'). Wenn die CPUs Hex-Core sind, sollte der Server maxdop höchstens 6 sein (wie hier beschrieben) ) oder auf einem OLTP-System niedriger sein. Normalerweise halte ich meine Tempdb-Dateien in Übereinstimmung mit meinem Server-DOP auf maximal 8, aber wir werden darauf zurückkommen.
• Bitte bestätigen Sie den Gesamtspeicher des Servers auf der Box und die SQL Server-Speicherbeschränkung (z. B. EXEC sp_configure 'max server memory (MB)' . ).
• Bitte überprüfen Sie, ob andere Dienste auf der Box ausgeführt werden (z. B. SSIS, SSAS, SSRS, die Anwendung, iTunes usw.).
• Vergewissern Sie sich, dass die Instant File-Initialisierung für das SQL Server-Dienstkonto aktiviert ist. (Möglichkeiten, es hier zu testen ).
• Warum gibt es eine so große Diskrepanz zwischen der CPU (NUMA-Setup mit zwei Knoten) und der einen Festplatte (Heim-PC)? Erwägen Sie das Hinzufügen von Festplatten, Striping und SSD für Tempdb (vermeiden Sie jedoch eine Überreaktion:) .
• Bitte fügen Sie einen tatsächlichen Ausführungsplan für eine der Problemabfragen hinzu. Anonymisieren Sie mit SQL Sentry Plan Explorer, wenn Sie möchten.

• Hash-Joins mit Tabellenvariablen in einem OLTP-System? Dies deutet auf einen Mangel an Indizierung für die Tabellenvariable, die Haupttabelle oder beides hin. Deklarieren Sie Ihre Tabellenvariablen wie folgt (ohne Indizes)?

  DECLARE @t TABLE ( x INT )

• Sparen Sie nicht an der Definition der Tabellenvariablen, obwohl diese kleine Ergebnismengen enthält. Es ist immer am besten, dem Optimierer so viele Informationen wie möglich zu geben, also sei explizit mit Nullwert, Eindeutigkeit, ob der Index geclustert oder nicht geclustert ist, z

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• Das Veröffentlichen des Ausführungsplans hilft bei der Diagnose.

• Überprüfen Sie, ob Code verhindert Tabellenvariable Caching per hier , hier . Ich denke, dass dynamisches SQL und proc, die WITH RECOMPILE ausgeführt werden, die einzigen sind, die sich auf Tabellenvariablen auswirken.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Überprüfen Sie das SQL Server-Protokoll (Objekt-Explorer> Verwaltung> SQL Server-Protokolle) auf Meldungen, z. B. E / A-Warnungen.

• Überprüfen Sie die Windows-Ereignisanzeige
• Seit SP1 wurde eine Reihe von Builds veröffentlicht. Überprüfen Sie die seit SP1 eingegebenen CU-Fixes . Möglicherweise wurden in SP1 Fehler in nachfolgenden CUs behoben, z. B. UPDATE: In SQL Server 2012 oder SQL Server 2014 verschüttete Sortieroperatoren in Tempdb, wenn die geschätzte Anzahl der Zeilen und die Zeilengröße korrekt sind. Https://support.microsoft.com/en- us / kb / 3088480
• Stellen Sie vor dem Anwenden von Hotfixes fest, dass dies Ihre Ursache ist, obwohl es aufgrund der Anzahl der neuen Funktionen (speicherinternes OLTP, gruppierter Spaltenspeicher) wichtiger ist, mit CUs mit SQL Server 2014 auf dem neuesten Stand zu bleiben.
• Schließlich ist die Notwendigkeit einer Tempdb-Datei pro Kern ein Mythos, und wenn man sich die Festplattenkonfiguration ansieht, ist die Annahme, dass Tempdb übermäßig fragmentiert ist. Ich habe das quälende Gefühl, Sie haben einen Plattenkopf, Tempdb hat eine Dateigruppe, viele Dateien.

Vergiss jedoch, was wir zu wissen glauben; Erstellen Sie einen Prüfstand, der Ihr Problem reproduziert, und versuchen Sie, die Anzahl der temporären Dateien zu verringern. Beginnen Sie mit 1, 2, 4, 6 usw. Sammeln Sie die Informationen, um eine evidenzbasierte Entscheidung zu treffen. Dies ist das Schwierigere, da Ihr Problem nur zeitweise auftritt und Sie möglicherweise nicht in der Lage sind, sich mit Ihrem Tempdb-Setup herumzuschlagen, aber so würde ich vorgehen.

Viel Glück. Lassen Sie uns wissen, wie es Ihnen geht.