Dela via

Felsök tempdb-fel i en dedikerad SQL-pool

  • Artikel

Gäller för: Azure Synapse Analytics

I en dedikerad SQL-pool används tempdb-databasen för tillfälliga tabeller och mellanliggande utrymme för dataförflyttningar (till exempel shuffle moves, trim moves), sortering, belastningar, minnesutsläpp och andra åtgärder. Dessutom förhindrar en icke-tilldelad transaktion i en session som interagerar med tempdb-databasen loggen från att rensa alla andra sessioner, vilket gör att loggfilerna fylls. Eftersom tempdb-databasen är en delad resurs kan en stor förbrukning av tempdb-utrymmet leda till att andra användares frågor misslyckas och kan eskalera för att förhindra att nya anslutningar upprättas.

Vad gör jag om jag inte kan ansluta till den dedikerade SQL-poolen?

Om du inte har några befintliga anslutningar för att identifiera eventuella problematiska anslutningar eller frågor är den enda metoden för att lösa oförmågan att skapa en ny anslutning att pausa och återuppta eller skala den dedikerade SQL-poolen. Den här åtgärden avslutar de användartransaktioner som ledde till det här problemet och återskapar tempdb-databasen när tjänsten startas om.

Obs! Se till att ge tjänsten extra tid att ångra alla transaktioner som körs eftersom paus- och skalningsåtgärder kan ta längre tid än normalt att slutföras i det här scenariot.

Felsöka fullständiga tempdb-datafiler

Steg 1: Identifiera frågan som fyller tempdb-databasen

Se till att du identifierar frågan som fyller tempdb-databasen medan frågan körs, såvida du inte har implementerat en loggningskomponent i ETL-ramverket eller granskning av dina dedikerade SQL-poolinstruktioner. I de flesta fall, inte alltid, är den längsta körningsfrågan som kördes under den tidsperiod då problemet inträffade orsaken till tempdb out-of-space-fel. Kör följande fråga för att hämta en lista över långvariga frågor:

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

När du har en ganska misstänkt fråga kan du prova något av följande alternativ:

  • Döda uttalandet.
  • Försök att förhindra att andra arbetsbelastningar förbrukar tempdb-utrymmet ytterligare så att long-runner kan slutföras.

Steg 2: Förhindra upprepning

När du har identifierat och vidtagit åtgärder mot den ansvariga frågan kan du överväga att implementera åtgärder för att förhindra att problemet återkommer. I följande tabell visas åtgärder för de vanligaste orsakerna till fullständiga tempdb-fel:

Orsak Beskrivning Åtgärd
Dåligt distribuerad plan Den distribuerade plan som genereras för en viss fråga kan oavsiktligt introducera dataflytt med hög frekvens till följd av dåligt underhållen tabellstatistik. Uppdatera statistik för relevanta tabeller och se till att de underhålls enligt ett regelbundet schema.
Dåligt hälsotillstånd för grupperat kolumnlagringsindex (CCI) Det förbrukar tempdb-utrymmet på grund av minnesutsläpp. Återskapa CCIs och se till att de underhålls enligt ett regelbundet schema.
Stora transaktioner Stora mängder CREATE TABLE AS SELECT (CTAS) eller INSERT SELECT instruktioner fyller tempdb under dataförflyttningsåtgärder. Dela upp CTAS- eller INSERT SELECT-instruktionerna i flera mindre transaktioner.
Otillräcklig minnesallokering Frågor med otillräckligt allokerat minne (via resursklass eller arbetsbelastningsgrupp) kan spillas till tempdb. Kör dina frågor med en större resursklass eller en arbetsbelastningsgrupp med fler resurser.
Externa tabellfrågor för slutanvändare Frågor mot externa tabeller är inte optimala för slutanvändarfrågor eftersom motorn måste läsa hela filen innan tempdb data bearbetas. Läs in data till en permanent tabell och dirigera sedan användarfrågor dit.
Otillräckliga övergripande resurser Du kanske upptäcker att din dedikerade SQL-pool ligger nära den maximala tempdb-kapaciteten under hög aktivitet. Överväg att skala upp din dedikerade SQL-pool i kombination med någon av minskningarna ovan.

Felsöka fullständiga tempdb-transaktionsloggfiler

Tempdb-transaktionsloggen fylls vanligtvis bara när en klient/användare antingen:

  • Öppnar en explicit transaktion men utfärdar aldrig en COMMIT eller ROLLBACK.
  • Uppsättningar IMPLICIT_TRANSACTION = ON (särskilt för JDBC-klienter och verktyg som använder AutoCommit-funktioner).

Steg 1: Identifiera öppna transaktioner

De problematiska anslutningarna kan komma från klienter som har en öppen transaktion men har statusen "Inaktiv". Kör följande fråga för att identifiera det här scenariot:

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

Obs! Alla anslutningar som returneras till följd av den här frågan är inte nödvändigtvis problematiska. Kör frågan minst två gånger med mer än 15 minuter mellan körningarna och se vilka anslutningar som finns kvar i det här tillståndet.

Steg 2: Åtgärda och förhindra problemet

När du har identifierat vilka klienter som har öppna transaktioner kan du arbeta med användarna för att ändra antingen eller båda:

  • Drivrutinskonfiguration (till exempel: JDBC AutoCommit-inställning till off, som anger IMPLICIT_TRANSACTIONS = ON)
  • Ad hoc-frågebeteenden (till exempel felaktig körning BEGIN TRAN utan COMMIT/ROLLBACK)

Du kan också överväga att skapa en automatiserad process för att regelbundet identifiera det här scenariot och döda eventuella problematiska sessioner.

Resurser