Dela via

Felsöka tempdb-fel på en dedikerad SQL-pool

  • Artikel

Gäller för: Azure Synapse Analytics

I en dedikerad SQL-pool används tempdb-databasen för temporära tabeller och mellanliggande utrymme för datarörelser (till exempel shuffle-rörelser, trimningsflyttningar), sortering, belastningar, minnesspill och andra åtgärder. Dessutom förhindrar en obekräftad 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 användartransaktionerna som ledde till det här problemet och återskapar tempdb-databasen när tjänsten startas om.

Observera: Se till att ge tjänsten extra tid att ångra alla pågående transaktioner eftersom paus- och skalningsåtgärder kan ta längre tid än normalt att slutföra 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-felen med slut på utrymme. 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 instruktionen.
  • Försök att förhindra att andra arbetsbelastningar förbrukar tempdb-utrymmet ytterligare så att den långa körningen kan slutföras.

Steg 2: Förhindra upprepning

När du har identifierat och vidtagit åtgärder mot den ansvarsfulla frågan bör 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 Riskreducering
Dålig distribuerad plan Den distribuerade planen som genereras för en viss fråga kan oavsiktligt introducera dataförflyttning 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ålig status för grupperat kolumnlagringsindex (CCI) Det förbrukar tempdb-utrymmet på grund av minnesspill. Återskapa CCI:er 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 din CTAS eller INSERT SELECT -instruktionen i flera mindre transaktioner.
Otillräcklig minnesallokering Frågor med otillräckligt allokerat minne (via resursklass eller arbetsbelastningsgrupp) kan spilla 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 i tempdb innan data bearbetas. Läs in data till en permanent tabell och dirigera sedan användarfrågor där.
Otillräckliga övergripande resurser Du kanske upptäcker att din dedikerade SQL-pool är nära sin maximala tempdb-kapacitet 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 i 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 som 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 samarbeta 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 avsluta eventuella problematiska sessioner.

Resurser