Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:✅ Lagerlokal 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:
- Kontrollera statusen för Warehouse och se till att den inte har pausats.
- 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 för att bättre balansera 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.
- 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. Förfrågningar kan misslyckas om tempdb utrymmet tar slut. Gör så här för att minska tempdb utrymmesanvändningen:
- Se artikeln om statistik för att verifiera att rätt kolumnstatistik har skapats i alla tabeller.
- Se till att all tabellstatistik uppdateras efter stora DML-transaktioner.
- Frågor med komplexa JOIN-operationer, GROUP BY och ORDER BY som förväntas returnera stora resultatuppsättningar använder mer
tempdbutrymme vid körning. Uppdatera frågor för att minska antalet GROUP BY- och ORDER BY-kolumner om möjligt. - 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:
- Identifiera skillnaderna i alla prestandapåverkande faktorer bland bra och dåliga prestandakörningar.
- Se artikeln om statistik för att verifiera att rätt kolumnstatistik har skapats i alla tabeller.
- Se till att all tabellstatistik uppdateras efter stora DML-transaktioner.
- Sök efter datasnedvridning i bastabeller.
- 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.
Sökfrågan misslyckas med att köras efter att ha pågått 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:
- Använd olika klientverktyg för att köra samma fråga igen.
- SQL Server Management Studio (SSMS)
- MSSQL-tillägget med Visual Studio Code
- Frågeredigeraren SQL i Microsoft Fabric-portalen
- Visual Query-redigeraren i Microsoft Fabric-portalen
- SQLCMD-verktyget (för autentisering via Microsoft Entra ID (tidigare Azure Active Directory) Universal med MFA använder du parametrar
-G -U)
- 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 med framgång och måltabellen är befolkad, så orsakas det ursprungliga frågefelet troligen av datalagrets frontend eller klientproblem.
Skriv- eller uppdateringskonflikter
Skrivkonflikter eller uppdateringskonflikter kan uppstå när två transaktioner försöker UPDATE, DELETE, MERGE eller TRUNCATE samma tabell. Du kan se felmeddelanden som:
- Fel 24556: Ögonblicksbildisoleringstransaktionen avbröts på grund av en uppdateringskonflikt. Att använda ögonblicksbildisolering för att komma åt tabellen%.*ls direkt eller indirekt i databasen%.*ls kan orsaka uppdateringskonflikter om rader i tabellen har tagits bort eller uppdaterats av en annan samtidig transaktion. Försök utföra transaktionen igen.
- Fel 24706: Ögonblicksbildisoleringstransaktionen avbröts på grund av uppdateringskonflikt. Du kan inte använda ögonblicksbildisolering för att komma åt tabellen%.*ls direkt eller indirekt i databasen%.*ls för att uppdatera, ta bort eller infoga raden som har ändrats eller tagits bort av en annan transaktion. Försök utföra transaktionen igen.
Mer information finns i Metodtips för att undvika skriv- och skrivkonflikter.
Vad du ska samla in innan du kontaktar Microsofts support
- Ange arbetsytans ID för Warehouse.
- Ange uttalande-ID och distribuerad begäran-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.