Del via

Feilsøke lageret

  • Artikkel

Gjelder for:✅ Lager i Microsoft Fabric

Denne artikkelen gir veiledning i feilsøking av vanlige problemer i Warehouse i Microsoft Fabric.

Midlertidige tilkoblingsfeil

En midlertidig feil, også kjent som en midlertidig feil, har en underliggende årsak som snart løser seg selv. Hvis en tilkobling til Lager brukes til å fungere fint, men begynner å mislykkes uten endringer i brukertillatelse, brannmurpolicy og nettverkskonfigurasjon, kan du prøve disse trinnene før du kontakter kundestøtte:

  1. Kontroller statusen for Lager, og kontroller at den ikke er stanset midlertidig.
  2. Ikke prøv den mislykkede kommandoen umiddelbart. Vent i stedet i 5 til 10 minutter, opprett en ny tilkobling, og prøv deretter kommandoen på nytt. Av og til skifter Azure-systemet raskt maskinvareressurser for å bedre belastningsbalansere ulike arbeidsbelastninger. De fleste av disse rekonfigureringshendelsene avsluttes på mindre enn 60 sekunder. I løpet av denne tidsrommet for ny konfigurasjon kan det hende du har problemer med å koble til databasene. Tilkoblingen kan også mislykkes når tjenesten startes på nytt automatisk for å løse visse problemer.
  3. Koble til ved hjelp av et annet program og/eller fra en annen maskin.

Spørringsfeil på grunn av problem med midlertidig mellomrom

Er tempdb en systemdatabase som brukes av motoren for ulike midlertidige lagringsbehov under kjøring av spørring. Det kan ikke åpnes eller konfigureres av brukere. Spørringer kan mislykkes på grunn av at det går tom for tempdb plass. Gjør følgende for å redusere tempdb plassbruken:

  1. Se artikkelen om statistikk for å bekrefte at riktig kolonnestatistikk er opprettet i alle tabeller.
  2. Kontroller at alle tabellstatistikker oppdateres etter store DML-transaksjoner.
  3. Spørringer med komplekse JOIN-er, GRUPPER ETTER og ORDER BY og forventer å returnere store resultatsett, bruker mer tempdb plass i kjøringen. Oppdater spørringer for å redusere antall GRUPPER ETTER- og ORDER BY-kolonner hvis mulig.
  4. Kjør spørringen på nytt når det ikke kjører noen andre aktive spørringer for å unngå ressursbetingelser under kjøring av spørring.

Spørringsytelsen ser ut til å bli redusert over tid

Mange faktorer kan påvirke ytelsen til en spørring, for eksempel endringer i tabellstørrelse, dataskyvhet, samtidighet av arbeidsbelastning, tilgjengelige ressurser, nettverk osv. Selv om en spørring kjører tregere, betyr det ikke nødvendigvis at det er et problem med spørringsytelsen. Gjør følgende for å undersøke målspørringen:

  1. Identifiser forskjellene i alle ytelsesvirkende faktorer blant gode og dårlige ytelseskjøringer.
  2. Se artikkelen om statistikk for å bekrefte at riktig kolonnestatistikk er opprettet i alle tabeller.
  3. Kontroller at alle tabellstatistikker oppdateres etter store DML-transaksjoner.
  4. Se etter dataskyv i basistabeller.
  5. Stans og fortsett tjenesten midlertidig. Kjør deretter spørringen på nytt når det ikke er noen andre aktive spørringer som kjører. Du kan overvåke lagerarbeidsbelastningen ved hjelp av DMV.

Spørringen mislykkes etter å ha kjørt i lang tid. Ingen data returneres til klienten.

En SELECT-setning kan ha fullført i serverdel og mislykkes når du prøver å returnere spørringsresultatet som er satt til klienten. Prøv å følge fremgangsmåten for å isolere problemet:

  1. Bruk forskjellige klientverktøy til å kjøre den samme spørringen på nytt.
  2. Hvis trinn 1 mislykkes, kjører du en CTAS-kommando med den mislykkede SELECT-setningen for å sende SELECT-spørringsresultatet til en annen tabell i samme lager. Bruk av CTAS unngår at spørringsresultatsettet sendes tilbake til klientmaskinen. Hvis CTAS-kommandoen er fullført og måltabellen er fylt ut, skyldes den opprinnelige spørringsfeilen sannsynligvis lagerfront- eller klientproblemer.

Hva du kan samle inn før du kontakter Microsoft Kundestøtte

  • Angi arbeidsområde-ID-en for lageret.
  • Oppgi ID-en for erklærings-ID og distribuert forespørsel. De returneres som meldinger etter at en spørring er fullført eller mislykket.
  • Oppgi teksten i den nøyaktige feilmeldingen.
  • Angi tidspunktet når spørringen fullføres eller mislykkes.

Relatert innhold