Foretag fejlfinding af lageret
Gælder for:✅ Warehouse i Microsoft Fabric
Denne artikel indeholder en vejledning i fejlfinding af almindelige problemer i Warehouse i Microsoft Fabric.
Midlertidige forbindelsesfejl
En forbigående fejl, også kendt som en forbigående fejl, har en underliggende årsag, der snart løser sig selv. Hvis en forbindelse til Warehouse tidligere fungerede fint, men begynder at mislykkes uden ændringer i brugertilladelser, firewallpolitik og netværkskonfiguration, kan du prøve disse trin, før du kontakter support:
- Kontrollér status for Lager, og sørg for, at den ikke er midlertidigt afbrudt.
- Prøv ikke straks at udføre den mislykkede kommando igen. Vent i stedet i 5 til 10 minutter, opret en ny forbindelse, og prøv derefter kommandoen igen. Nogle gange skifter Azure-systemet hurtigt hardwareressourcer til bedre belastningsjustering af forskellige arbejdsbelastninger. De fleste af disse omkonfigureringshændelser afsluttes på mindre end 60 sekunder. I løbet af denne omkonfigureringstid kan du have problemer med at oprette forbindelse til dine databaser. Forbindelsen kan også mislykkes, når tjenesten genstartes automatisk for at løse visse problemer.
- Opret forbindelse ved hjælp af et andet program og/eller fra en anden computer.
Forespørgselsfejl på grund af problemer med tempdb-plads
tempdb
er en systemdatabase, der bruges af programmet til forskellige midlertidige lagerbehov under udførelse af forespørgsler. Brugerne kan ikke få adgang til den eller konfigurere den. Forespørgsler kan mislykkes, fordi tempdb
der ikke er mere plads. Udfør disse trin for at reducere tempdb
pladsforbruget:
- Se artiklen om statistik for at kontrollere, at der er oprettet korrekt kolonnestatistik på alle tabeller.
- Sørg for, at alle tabelstatistikker opdateres efter store DML-transaktioner.
- Forespørgsler med komplekse JOIN'er, GROUP BY og ORDER BY og forventer at returnere store resultatsæt bruger mere
tempdb
plads i udførelsen. Opdater forespørgsler for at reducere antallet af GROUP BY- og ORDER BY-kolonner, hvis det er muligt. - Kør forespørgslen igen, når der ikke kører andre aktive forespørgsler for at undgå ressourcebegrænsning under udførelse af forespørgslen.
Forespørgselsydeevnen synes at blive forringet over tid
Mange faktorer kan påvirke en forespørgsels ydeevne, f.eks. ændringer i tabelstørrelse, dataforvrængelse, samtidighed af arbejdsbelastninger, tilgængelige ressourcer, netværk osv. Bare fordi en forespørgsel kører langsommere, betyder det ikke nødvendigvis, at der er et problem med forespørgslens ydeevne. Udfør følgende trin for at undersøge destinationsforespørgslen:
- Identificer forskellene i alle faktorer, der påvirker ydeevnen, blandt kørsler med god og dårlig ydeevne.
- Se artiklen om statistik for at kontrollere, at der er oprettet korrekt kolonnestatistik på alle tabeller.
- Sørg for, at alle tabelstatistikker opdateres efter store DML-transaktioner.
- Kontrollér, om der er dataforvrængede i basistabeller.
- Afbryd tjenesten midlertidigt, og fortsæt den. Kør derefter forespørgslen igen, når der ikke kører andre aktive forespørgsler. Du kan overvåge lagerbelastningen ved hjælp af DMV.
Forespørgslen mislykkes, efter at den har kørt i lang tid. Der returneres ingen data til klienten.
En SELECT-sætning kunne være fuldført i backend og mislykkes, når du forsøger at returnere forespørgselsresultatsættet til klienten. Prøv følgende trin for at isolere problemet:
- Brug forskellige klientværktøjer til at køre den samme forespørgsel igen.
- SQL Server Management Studio (SSMS)
- Azure Data Studio
- SQL-forespørgselseditoren på Microsoft Fabric-portalen
- Visual Query-editoren på Microsoft Fabric-portalen
- SQLCMD-værktøj (til godkendelse via Microsoft Entra ID (tidligere Azure Active Directory) Universal med MFA, brug parametre
-G -U
)
- Hvis trin 1 mislykkes, skal du køre en CTAS-kommando med den mislykkede SELECT-sætning for at sende SELECT-forespørgselsresultatet til en anden tabel i det samme lager. Når du bruger CTAS, undgår du, at forespørgselsresultatsættet sendes tilbage til klientcomputeren. Hvis CTAS-kommandoen afsluttes, og destinationstabellen udfyldes, skyldes den oprindelige forespørgselsfejl sandsynligvis problemer med lagerets frontend eller klient.
Hvad du skal indsamle, før du kontakter Microsoft Support
- Angiv arbejdsområde-id'et for Warehouse.
- Angiv sætnings-id'et og id'et for distribuerede anmodninger. De returneres som meddelelser, når en forespørgsel er fuldført eller mislykket.
- Angiv teksten til den nøjagtige fejlmeddelelse.
- Angiv det tidspunkt, hvor forespørgslen fuldføres eller mislykkes.