Freigeben über

Behandeln von tempdb-Fehlern in einem dedizierten SQL-Pool

  • Artikel

Gilt für: Azure Synapse Analytics

In einem dedizierten SQL-Pool wird die tempdb-Datenbank für temporäre Tabellen und Zwischenspeicherplatz für Datenverschiebungen (z. B. Shuffleverschiebungen, Kürzungen von Verschiebungen), Sortierungen, Ladevorgängen, Speicherüberläufen und anderen Vorgängen verwendet. Darüber hinaus verhindert eine Transaktion ohne Commit in einer Sitzung, die mit der tempdb-Datenbank interagiert, dass das Protokoll alle anderen Sitzungen leert, wodurch die Protokolldateien gefüllt werden. Da es sich bei der tempdb-Datenbank um eine freigegebene Ressource handelt, kann der große Verbrauch des tempdb-Speicherplatzes dazu führen, dass die Abfragen anderer Benutzer fehlschlagen und eskalieren können, um zu verhindern, dass neue Verbindungen hergestellt werden.

Was ist zu tun, wenn ich keine Verbindung mit dem dedizierten SQL-Pool herstellen kann?

Wenn Keine vorhandenen Verbindungen vorhanden sind, um problematische Verbindungen oder Abfragen zu identifizieren, besteht die einzige Methode zum Beheben der Unfähigkeit, eine neue Verbindung zu erstellen, darin, den dedizierten SQL-Pool anzuhalten und fortzusetzen oder den dedizierten SQL-Pool zu skalieren . Diese Aktion beendet die Benutzertransaktionen, die zu diesem Problem geführt haben, und erstellt die tempdb-Datenbank neu, wenn der Dienst neu gestartet wird.

Hinweis: Achten Sie darauf, dem Dienst zusätzliche Zeit zu geben, um alle ausgeführten Transaktionen rückgängig zu machen, da die Ausführung von Pausen- und Skalierungsvorgängen in diesem Szenario länger als normal dauern kann.

Problembehandlung bei vollständigen tempdb-Datendateien

Schritt 1: Identifizieren der Abfrage, die die tempdb-Datenbank auffüllt

Stellen Sie sicher, dass Sie die Abfrage identifizieren, die die tempdb-Datenbank füllt, während die Abfrage ausgeführt wird, es sei denn, Sie haben eine Protokollierungskomponente in Ihrem ETL-Framework implementiert oder ihre dedizierten SQL-Poolanweisungen überprüft. In den meisten Fällen ist die Abfrage mit der längsten Ausführungszeit, die während des Zeitraums ausgeführt wurde, in dem das Problem aufgetreten ist, die Ursache für fehler aufgrund von tempdb-Fehlern aufgrund von fehlendem Speicherplatz. Führen Sie die folgende Abfrage aus, um eine Liste mit Abfragen mit langer Ausführungsdauer abzurufen:

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

Sobald Sie eine einigermaßen verdächtige Abfrage haben, probieren Sie eine der folgenden Optionen aus:

  • Beenden Sie die Anweisung.
  • Versuchen Sie, zu verhindern, dass andere Workloads den tempdb-Speicherplatz weiter verbrauchen, damit der Longrunner abgeschlossen werden kann.

Schritt 2: Verhindern der Wiederholung

Nachdem Sie die verantwortungsvolle Abfrage identifiziert und maßnahmen ergriffen haben, sollten Sie die Implementierung von Entschärfungen in Betracht ziehen, um zu verhindern, dass sich das Problem wiederholt. Die folgende Tabelle enthält Entschärfungen für die häufigsten Ursachen von tempdb full-Fehlern:

Ursache Beschreibung Risikominderung
Schlechter verteilter Plan Der verteilte Plan, der für eine bestimmte Abfrage generiert wird, kann versehentlich eine hochfrequente Datenverschiebung aufgrund von schlecht verwalteten Tabellenstatistiken einführen. Aktualisieren Sie Statistiken für relevante Tabellen, und stellen Sie sicher, dass sie regelmäßig verwaltet werden.
Schlechte Integrität des gruppierten Columnstore-Indexes (CCI) Der tempdb-Speicherplatz wird aufgrund von Speicherüberläufen verbraucht. Erstellen Sie CCIs neu , und stellen Sie sicher, dass sie nach einem regelmäßigen Zeitplan verwaltet werden.
Große Transaktionen Große Mengen von CREATE TABLE AS SELECT (CTAS) - oder INSERT SELECT -Anweisungen füllen tempdb während Datenverschiebungsvorgängen aus. Unterteilen Sie Ihre CTAS - oder INSERT SELECT -Anweisung in mehrere kleinere Transaktionen.
Unzureichende Speicherbelegung Abfragen mit unzureichendem Arbeitsspeicher (über Ressourcenklasse oder Arbeitsauslastungsgruppe) können in überlaufen tempdb. Führen Sie Ihre Abfragen mit einer größeren Ressourcenklasse oder einer Arbeitsauslastungsgruppe mit mehr Ressourcen aus.
Abfragen externer Tabellen für Endbenutzer Abfragen für externe Tabellen sind für Endbenutzerabfragen nicht optimal, da die Engine vor der Verarbeitung der Daten die gesamte Datei tempdb lesen muss. Laden Sie die Daten in eine permanente Tabelle, und leiten Sie dann Benutzerabfragen dorthin weiter.
Unzureichende Gesamtressourcen Möglicherweise stellen Sie fest, dass Ihr dedizierter SQL-Pool bei hoher Aktivität nahe an der maximalen tempdb-Kapazität liegt. Erwägen Sie das Hochskalieren Ihres dedizierten SQL-Pools in Kombination mit einer der oben genannten Risikominderungen.

Problembehandlung für vollständige tempdb-Transaktionsprotokolldateien

Das tempdb-Transaktionsprotokoll wird in der Regel nur gefüllt, wenn ein Client/Benutzer eines der folgenden Aktionen ausgeführt wird:

  • Öffnet eine explizite Transaktion, gibt aber niemals ein oder ROLLBACKausCOMMIT.
  • Legt fest IMPLICIT_TRANSACTION = ON (insbesondere für JDBC-Clients und -Tools, die AutoCommit-Features verwenden).

Schritt 1: Identifizieren offener Transaktionen

Die problematischen Verbindungen können von Clients stammen, die über eine offene Transaktion verfügen, sich aber in einem "Leerlauf"-status befinden. Führen Sie die folgende Abfrage aus, um dieses Szenario zu identifizieren:

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

Hinweis: Nicht alle Verbindungen, die als Ergebnis dieser Abfrage zurückgegeben werden, sind notwendigerweise problematisch. Führen Sie die Abfrage mindestens zweimal mit mehr als 15 Minuten zwischen den Ausführungen aus, und sehen Sie, welche Verbindungen in diesem Zustand bestehen.

Schritt 2: Beheben und Verhindern des Problems

Nachdem Sie ermittelt haben, welche Clients offene Transaktionen enthalten, arbeiten Sie mit den Benutzern zusammen, um eine oder beides zu ändern:

  • Treiberkonfiguration (z. B. JDBC AutoCommit-Einstellung auf off, die festlegt IMPLICIT_TRANSACTIONS = ON)
  • Ad-hoc-Abfrageverhalten (z. B. falsche Ausführung BEGIN TRAN ohne COMMIT/ROLLBACK)

Alternativ können Sie die Erstellung eines automatisierten Prozesses in Betracht ziehen, um dieses Szenario regelmäßig zu erkennen und potenziell problematische Sitzungen zu beenden .

Ressourcen