Dela via


Felsöka informationslagret

Gäller för:✅ Warehouse i Microsoft Fabric

Den här artikeln innehåller vägledning för felsökning av vanliga problem i Warehouse i Microsoft Fabric.

Tillfälliga anslutningsfel

Ett tillfälligt fel, även kallat ett tillfälligt fel, har en underliggande orsak som snart löser sig själv. Om en anslutning till Warehouse fungerade bra men börjar misslyckas utan ändringar i användarbehörighet, brandväggsprincip och nätverkskonfiguration kan du prova följande steg innan du kontaktar supporten:

  1. Kontrollera statusen för Warehouse och se till att den inte har pausats.
  2. Försök inte omedelbart igen med det misslyckade kommandot. Vänta i stället i 5 till 10 minuter, upprätta en ny anslutning och försök sedan köra kommandot igen. Ibland flyttar Azure-systemet snabbt maskinvaruresurser till bättre belastningsutjämning av olika arbetsbelastningar. De flesta av dessa omkonfigurationshändelser slutförs på under 60 sekunder. Under den här omkonfigurationstiden kan du ha problem med att ansluta till dina databaser. Anslutningen kan också misslyckas när tjänsten startas om automatiskt för att lösa vissa problem.
  3. Anslut med ett annat program och/eller från en annan dator.

Frågefel på grund av problem med tempdb-utrymme

tempdb är en systemdatabas som används av motorn för olika tillfälliga lagringsbehov under frågekörningen. Det kan inte nås eller konfigureras av användare. Frågor kan misslyckas på grund av att tempdb utrymmet börjar ta slut. Gör så här för att minska tempdb utrymmesanvändningen:

  1. Se artikeln om statistik för att verifiera att rätt kolumnstatistik har skapats i alla tabeller.
  2. Se till att all tabellstatistik uppdateras efter stora DML-transaktioner.
  3. Frågor med komplexa JOIN: er, GROUP BY och ORDER BY och förväntar sig att returnera stora resultatuppsättningar använder mer tempdb utrymme i körningen. Uppdatera frågor för att minska antalet GROUP BY- och ORDER BY-kolumner om möjligt.
  4. Kör frågan igen när det inte finns några andra aktiva frågor som körs för att undvika resursbegränsningar under frågekörningen.

Frågeprestanda verkar försämras med tiden

Många faktorer kan påverka en frågas prestanda, till exempel ändringar i tabellstorlek, datasnedvridning, samtidighet i arbetsbelastningar, tillgängliga resurser, nätverk osv. Bara för att en fråga körs långsammare betyder det inte nödvändigtvis att det finns ett problem med frågeprestanda. Utför följande steg för att undersöka målfrågan:

  1. Identifiera skillnaderna i alla prestandapåverkande faktorer bland bra och dåliga prestandakörningar.
  2. Se artikeln om statistik för att verifiera att rätt kolumnstatistik har skapats i alla tabeller.
  3. Se till att all tabellstatistik uppdateras efter stora DML-transaktioner.
  4. Sök efter datasnedvridning i bastabeller.
  5. Pausa och återuppta tjänsten. Kör sedan frågan igen när det inte finns några andra aktiva frågor som körs. Du kan övervaka lagerarbetsbelastningen med DMV.

Frågan misslyckas när den har körts under en längre tid. Inga data returneras till klienten.

En SELECT-instruktion kan ha slutförts i serverdelen och misslyckas när du försöker returnera frågeresultatet som angetts till klienten. Försök med följande steg för att isolera problemet:

  1. Använd olika klientverktyg för att köra samma fråga igen.
  2. Om steg 1 misslyckas kör du ett CTAS-kommando med den misslyckade SELECT-instruktionen för att skicka SELECT-frågeresultatet till en annan tabell i samma lager. Med CTAS undviker du att frågeresultatuppsättningen skickas tillbaka till klientdatorn. Om CTAS-kommandot har slutförts och måltabellen har fyllts i orsakas det ursprungliga frågefelet troligen av informationslagrets klientdel eller klientproblem.

Vad du ska samla in innan du kontaktar Microsofts support

  • Ange arbetsytans ID för Warehouse.
  • Ange instruktions-ID och distribuerat begärande-ID. De returneras som meddelanden när en fråga har slutförts eller misslyckas.
  • Ange texten i det exakta felmeddelandet.
  • Ange den tid då frågan slutförs eller misslyckas.