Freigeben über


Problembehandlung bei einem dedizierten SQL-Pool mit TempDB-Fehlern

Gilt für: Azure Synapse Analytics

In einem dedizierten SQL-Pool wird die tempdb-Datenbank für temporäre Tabellen und Zwischenraum für Datenbewegungen verwendet (z. B. Shuffle-Verschiebungen, Kürzungsverschiebungen), Sortierungen, Lasten, Speicherüberlaufe und andere Vorgänge. Darüber hinaus verhindert eine nicht ausgelassene Transaktion in einer Sitzung, die mit der tempdb-Datenbank interagiert, dass das Protokoll alle anderen Sitzungen löscht, wodurch die Protokolldateien ausgefüllt werden. Da es sich bei der tempdb-Datenbank um eine freigegebene Ressource handelt, kann ein großer Verbrauch des tempdb-Speicherplatzes dazu führen, dass die Abfragen anderer Benutzer fehlschlagen und eskalieren können, um zu verhindern, dass neue Verbindungen eingerichtet werden.

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

Wenn Keine Verbindungen vorhanden sind, um problematische Verbindungen oder Abfragen zu identifizieren, besteht die einzige Methode zum Auflösen der Unfähigkeit, eine neue Verbindung zu erstellen, darin, 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 Pausen- und Skalierungsvorgänge in diesem Szenario möglicherweise länger als normal dauern können.

Problembehandlung für vollständige tempdb-Datendateien

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

Stellen Sie sicher, dass Sie die Abfrage identifizieren, die die tempdb-Datenbank ausfüllt, während die Abfrage ausgeführt wird, es sei denn, Sie haben eine Protokollierungskomponente in Ihr ETL-Framework oder die Überwachung Ihrer dedizierten SQL-Poolanweisungen implementiert. In den meisten Fällen ist nicht immer die längst ausgeführte Abfrage, die während des Zeitrahmens ausgeführt wird, in dem das Problem aufgetreten ist, die Ursache für temporäre Fehler. Führen Sie die folgende Abfrage aus, um eine Liste der lang ausgeführten Abfragen abzurufen:

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

Wenn Sie eine vernünftig verdächtige Abfrage haben, probieren Sie eine der folgenden Optionen aus:

  • Beenden Sie die Anweisung.
  • Versuchen Sie, andere Arbeitslasten daran zu hindern, den tempdb-Speicherplatz weiter zu verbrauchen, damit der Long-Runner abgeschlossen werden kann.

Schritt 2: Verhindern der Wiederholung

Nachdem Sie maßnahmen für die zuständige Abfrage identifiziert und ausgeführt haben, sollten Sie Maßnahmen implementieren, um zu verhindern, dass das Problem wiederholt wird. Die folgende Tabelle zeigt Entschärfungen für die häufigsten Ursachen für vollständige Tempdb-Fehler:

Ursache Beschreibung Minderung
Mangelhafter verteilter Plan Der verteilte Plan, der für eine bestimmte Abfrage generiert wird, kann versehentlich eine hochfrequente Datenverschiebung als Ergebnis einer schlecht verwalteten Tabellenstatistik einführen. Aktualisieren Sie Statistiken für relevante Tabellen, und stellen Sie sicher, dass sie regelmäßig verwaltet werden.
Mangelhafte CCI-Integrität (Clustered Columnstore Index, gruppierter Columnstore-Index) Er verbraucht den tempdb-Speicherplatz aufgrund von Speicherübergängen. Erstellen Sie CCIs neu, und stellen Sie sicher, dass sie regelmäßig verwaltet werden.
Umfangreiche Transaktionen Große Mengen CREATE TABLE AS SELECT (CTAS) oder INSERT SELECT Anweisungen füllen die tempdb bei Datenverschiebungsvorgängen aus. Teilen Sie Anweisungen vom Typ CTAS oder INSERT SELECT auf mehrere kleinere Transaktionen auf.
Unzureichende Arbeitsspeicherzuweisung Abfragen mit unzureichendem Arbeitsspeicher (über Ressourcenklasse oder Workloadgruppe) können in tempdbdas Überlaufen gelangen. Führen Sie Ihre Abfragen mit einer größeren Ressourcenklasse oder mit einer Arbeitsauslastungsgruppe mit mehr Ressourcen aus.
Endbenutzerabfragen für externe Tabellen Abfragen für externe Tabellen sind für Endbenutzerabfragen nicht optimal, da das Modul die gesamte Datei tempdb vor der Verarbeitung der Daten lesen muss. Laden Sie die Daten in eine permanente Tabelle, und leiten Sie dann Benutzerabfragen an diese Tabelle weiter.
Insgesamt unzureichende Ressourcen Möglicherweise stellen Sie fest, dass Ihr dedizierter SQL-Pool bei hoher Aktivität nahe der maximalen tempdb-Kapazität liegt. Erwägen Sie die Skalierung Ihres dedizierten SQL-Pools in Kombination mit einer der oben genannten Entschärfungen.

Problembehandlung für vollständige tempdb-Transaktionsprotokolldateien

Das tempdb-Transaktionsprotokoll füllt in der Regel nur dann aus, wenn ein Client/Benutzer eine der folgenden Aktionen einnimmt:

  • Öffnet eine explizite Transaktion, gibt aber nie ein COMMIT oder ROLLBACKaus.
  • Sets IMPLICIT_TRANSACTION = ON (insbesondere für CLIENTS und Tools, die AutoCommit-Features verwenden).

Schritt 1: Identifizieren offener Transaktionen

Die problematischen Verbindungen können von Clients stammen, die über eine geöffnete Transaktion verfügen, sich aber im Status "Leerlauf" 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 Ausführungen aus, und sehen Sie, welche Verbindungen in diesem Zustand bestehen.

Schritt 2: Beheben und Verhindern des Problems

Nachdem Sie ermittelt haben, welche Kunden offene Transaktionen abhalten, arbeiten Sie mit den Benutzern zusammen, um entweder oder beides zu ändern:

  • Treiberkonfiguration (z. B.: SETTING AUTOCommit auf off, die festgelegt IMPLICIT_TRANSACTIONS = ONwird)
  • Ad-hoc-Abfrageverhalten (z. B. falsch ausgeführt BEGIN TRAN ohne COMMIT/ROLLBACK)

Alternativ können Sie erwägen, einen automatisierten Prozess zu erstellen, um dieses Szenario regelmäßig zu erkennen und potenziell problematische Sitzungen zu beenden .

Ressourcen