Feilsøke DirectQuery-modeller i Power BI Desktop

Denne artikkelen hjelper deg med å diagnostisere ytelsesproblemer med Power BI DirectQuery-datamodeller du utvikler i Power BI Desktop eller Power Bi-tjeneste. Artikkelen beskriver også hvordan du får detaljert informasjon for å hjelpe deg med å optimalisere rapporter.

Du bør starte enhver diagnose av ytelsesproblemer i Power BI Desktop, i stedet for i Power Bi-tjeneste eller rapportserver for Power BI. Ytelsesproblemer avhenger ofte av ytelsesnivået til den underliggende datakilden. Du kan lettere identifisere og diagnostisere disse problemene i det isolerte Power BI Desktop-miljøet, uten å involvere komponenter som en lokal gateway.

Hvis du ikke finner ytelsesproblemene i Power BI Desktop, kan du fokusere undersøkelsen på detaljene i rapporten i Power Bi-tjeneste.

Du bør også prøve å isolere problemer til et individuelt visualobjekt før du ser på mange visualobjekter på en side.

Ytelsesanalyse

Ytelsesanalyse er et nyttig verktøy for å identifisere ytelsesproblemer gjennom feilsøkingsprosessen. Hvis du kan identifisere et enkelt tregt visualobjekt på en side i Power BI Desktop, kan du bruke Ytelsesanalyse til å finne ut hvilke spørringer Power BI Desktop sender til den underliggende kilden.

Du kan også vise sporings- og diagnoseinformasjon som de underliggende datakildene avgir. Slike sporinger kan inneholde nyttig informasjon om detaljene for hvordan spørringen ble utført, og hvordan du kan forbedre den.

Selv uten spor fra kilden, kan du vise spørringene Power BI sendte, sammen med utførelsestidene deres.

Merk

For Sql-baserte DirectQuery-kilder viser Ytelsesanalyse bare spørringer for datakilder for SQL Server, Oracle og Teradata.

Sporingsfil

Som standard logger Power BI Desktop hendelser under en gitt økt til en sporingsfil kalt FlightRecorderCurrent.trc. Du finner sporingsfilen for gjeldende økt i AppData-mappen for gjeldende bruker, på< User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces.

Følgende DirectQuery-datakilder skriver alle spørringene som Power BI sender dem til sporingsfilen. Loggen kan støtte andre DirectQuery-kilder i fremtiden.

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (tidligere SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

Hvis du enkelt vil gå til sporingsfilmappen i Power BI Desktop, velger du Alternativer for filalternativer>og innstillinger>, og deretter velger du Diagnostikk.

Velg koblingen Åpne krasjdump/sporingsmappe under Krasjdumpsamling for å åpne< mappen User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Gå til mappens overordnede mappe, og åpne deretter AnalysisServicesWorkspaces-mappen , som inneholder én undermappe for arbeidsområdet for hver åpne forekomst av Power BI Desktop. Undermappenavnene har heltallssuffikser, for eksempel AnalysisServicesWorkspace2058279583.

Hver AnalysisServicesWorkspace-mappe inneholder en dataundermappe som inneholder sporingsfilen FlightRecorderCurrent.trc for gjeldende Power BI-økt. Denne mappen forsvinner når den tilknyttede Power BI Desktop-økten avsluttes.

Du kan åpne sporingsfilene ved hjelp av SQL Server Profiler-verktøyet, som du kan få som en del av den gratis NEDLASTINGen av SQL Server Management Studio (SSMS). Når du har lastet ned og installert SQL Server Management Studio, åpner du SQL Server Profiler.

Slik åpner du en sporingsfil:

1. Velg Filåpningssporingsfil>> i SQL Server Profiler.

2. Gå til eller skriv inn banen til sporingsfilen for gjeldende Power BI-økt, for eksempel <User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data, og åpne FlightRecorderCurrent.trc.

SQL Server Profiler viser alle hendelser fra gjeldende økt. Skjermbildet nedenfor uthever en gruppe hendelser for en spørring. Hver spørringsgruppe har følgende hendelser:

• A Query Begin og Query End hendelse, som representerer starten og slutten på en DAX-spørring som genereres ved å endre et visualobjekt eller et filter i Power BI-brukergrensesnittet, eller fra å filtrere eller transformere data i Power Query-redigering.

• Ett eller flere par DirectQuery Begin og DirectQuery End hendelser, som representerer spørringer som sendes til den underliggende datakilden som en del av evalueringen av DAX-spørringen.

Flere DAX-spørringer kan kjøre parallelt, slik at hendelser fra ulike grupper kan interleave. Du kan bruke verdien ActivityID til å bestemme hvilke hendelser som tilhører samme gruppe.

Følgende kolonner er også av interesse:

• TextData: Tekstdetaljene for hendelsen. For Query Begin og Query End hendelser er detaljen DAX-spørringen. For DirectQuery Begin og DirectQuery End hendelser er detaljene SQL-spørringen som sendes til den underliggende kilden. TextData-verdien for den valgte hendelsen vises også i ruten nederst på skjermen.
• Sluttid: Tidspunktet da hendelsen ble fullført.
• Varighet: Varigheten, i millisekunder, det tok å kjøre DAX- eller SQL-spørringen.
• Feil: Om det oppstod en feil, i så fall vises hendelsen også i rødt.

Det foregående bildet begrenser noen av de mindre interessante kolonnene, slik at du lettere kan se de mer interessante kolonnene.

Følg denne fremgangsmåten for å fange opp et spor for å diagnostisere et potensielt ytelsesproblem:

1. Åpne én enkelt Power BI Desktop-økt for å unngå forvirringen i flere arbeidsområdemapper.

2. Gjør settet med handlinger av interesse i Power BI Desktop. Inkluder noen flere handlinger, for å sikre at hendelsene av interesse skylles inn i sporingsfilen.

3. Åpne SQL Server Profiler, og undersøk sporingen. Husk at når du lukker Power BI Desktop, slettes sporingsfilen. Flere handlinger i Power BI Desktop vises heller ikke umiddelbart. Du må lukke og åpne sporingsfilen på nytt for å se nye hendelser.

Hold individuelle økter rimelig små, kanskje 10 sekunder med handlinger, ikke hundrevis. Denne fremgangsmåten gjør det enklere å tolke sporingsfilen. Det er også en grense for størrelsen på sporingsfilen, så for lange økter er det en sjanse for at tidlige hendelser faller.

Spørrings- og delspørringsformat

Det generelle formatet for Power BI Desktop-spørringer er å bruke delspørringer for hver modelltabell spørringsreferansen. Spørringen Power Query-redigering definerer undervalgsspørringene. Anta for eksempel at du har følgende TPC-DS-tabeller i en SQL Server-relasjonsdatabase:

I Power BI-visualobjektet definerer SalesAmount følgende uttrykk målet:

SalesAmount = SUMX(Web_Sales, [ws_sales_price] * [ws_quantity])

Oppdatering av visualobjektet produserer T-SQL-spørringen i bildet nedenfor. Det finnes tre delspørringer for Web_Salestabellene , Itemog Date_dim modellen. Hver spørring returnerer alle modelltabellkolonnene, selv om visualobjektet bare refererer til fire kolonner.

Disse skyggelagte delspørringene er den nøyaktige definisjonen av Power Query-spørringene. Denne bruken av delspørringer påvirker ikke ytelsen for datakildene DirectQuery støtter. Datakilder som SQL Server optimaliserer referansene til de andre kolonnene.

En av grunnene til at Power BI bruker dette mønsteret, er at du kan definere en Power Query-spørring til å bruke en bestemt spørringssetning. Power BI bruker spørringen som angitt, uten et forsøk på å skrive den på nytt. Dette mønsteret begrenser bruken av spørringssetninger som bruker CTE-er (Common Table Expressions) og lagrede prosedyrer. Du kan ikke bruke disse setningene i delspørringer.

Gateway-ytelse

Hvis du vil ha informasjon om feilsøking av gatewayytelse, kan du se Feilsøke gatewayer – Power BI.

Relatert innhold

Hvis du vil ha mer informasjon om DirectQuery, kan du se følgende ressurser:

• Bruke DirectQuery i Power BI Desktop
• Datakilder som støttes av DirectQuery
• DirectQuery-modeller i Power BI Desktop
• Veiledning for DirectQuery-modell i Power BI Desktop

Spørsmål? Prøv å spørre Power BI-fellesskap