Felsöka DirectQuery-modeller i Power BI Desktop

Den här artikeln hjälper dig att diagnostisera prestandaproblem med Power BI DirectQuery-datamodeller som du utvecklar i Power BI Desktop eller Power BI-tjänst. Artikeln beskriver också hur du får detaljerad information som hjälper dig att optimera rapporter.

Du bör starta en diagnos av prestandaproblem i Power BI Desktop i stället för i Power BI-tjänst eller Power BI-rapportserver. Prestandaproblem beror ofta på den underliggande datakällans prestandanivå. Du kan enklare identifiera och diagnostisera dessa problem i den isolerade Power BI Desktop-miljön, utan att involvera komponenter som en lokal gateway.

Om du inte hittar prestandaproblemen i Power BI Desktop kan du fokusera din undersökning på detaljerna i rapporten i Power BI-tjänst.

Du bör också försöka isolera problem till ett enskilt visuellt objekt innan du tittar på många visuella objekt på en sida.

Prestandaanalys

Prestandaanalys är ett användbart verktyg för att identifiera prestandaproblem under hela felsökningsprocessen. Om du kan identifiera ett enda trögt visuellt objekt på en sida i Power BI Desktop kan du använda Prestandaanalys för att avgöra vilka frågor Power BI Desktop skickar till den underliggande källan.

Du kanske också kan visa spårningar och diagnostikinformation som de underliggande datakällorna genererar. Sådana spårningar kan innehålla användbar information om hur frågan kördes och hur du kan förbättra den.

Även utan spårningar från källan kan du visa de frågor som Power BI skickade, tillsammans med deras körningstider.

Kommentar

För DirectQuery SQL-baserade källor visar Prestandaanalys endast frågor för SQL Server-, Oracle- och Teradata-datakällor.

Spårningsfil

Som standard loggar Power BI Desktop händelser under en viss session till en spårningsfil med namnet FlightRecorderCurrent.trc. Du hittar spårningsfilen för den aktuella sessionen i mappen AppData för den aktuella användaren, på <User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces.

Följande DirectQuery-datakällor skriver alla frågor som Power BI skickar dem till spårningsfilen. Loggen kan ha stöd för andra DirectQuery-källor i framtiden.

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

Om du enkelt vill komma till mappen spårningsfil i Power BI Desktop väljer du Alternativ för filalternativ>och inställningar> och väljer sedan Diagnostik.

Under Kraschdumpsamling väljer du länken Öppna kraschdump/spårningsmapp för att öppna <mappen User>\AppData\Local\Microsoft\Power BI Desktop\Traces .

Gå till mappens överordnade mapp och öppna sedan mappen AnalysisServicesWorkspaces , som innehåller en arbetsyteundermapp för varje öppen instans av Power BI Desktop. Undermappsnamnen har heltalssuffix, till exempel AnalysisServicesWorkspace2058279583.

Varje AnalysisServicesWorkspace-mapp innehåller en dataundermapp som innehåller spårningsfilen FlightRecorderCurrent.trc för den aktuella Power BI-sessionen. Den här mappen försvinner när den associerade Power BI Desktop-sessionen avslutas.

Du kan öppna spårningsfilerna med verktyget SQL Server Profiler, som du kan hämta som en del av den kostnadsfria nedladdningen av SQL Server Management Studio (SSMS). När du har hämtat och installerat SQL Server Management Studio öppnar du SQL Server Profiler.

Så här öppnar du en spårningsfil:

1. I SQL Server Profiler väljer du Arkiv Öppna>spårningsfil.>

2. Navigera till eller ange sökvägen till spårningsfilen för den aktuella Power BI-sessionen, till exempel <User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data, och öppna FlightRecorderCurrent.trc.

SQL Server Profiler visar alla händelser från den aktuella sessionen. Följande skärmbild visar en grupp händelser för en fråga. Varje frågegrupp har följande händelser:

• En Query Begin händelse som Query End representerar början och slutet av en DAX-fråga som genereras genom att ändra ett visuellt objekt eller filter i Power BI-användargränssnittet, eller från filtrering eller transformering av data i Power Query-redigeraren.

• Ett eller flera par DirectQuery Begin med och DirectQuery End händelser, som representerar frågor som skickas till den underliggande datakällan som en del av utvärderingen av DAX-frågan.

Flera DAX-frågor kan köras parallellt, så händelser från olika grupper kan interleave. Du kan använda värdet för ActivityID för att avgöra vilka händelser som tillhör samma grupp.

Följande kolumner är också av intresse:

• TextData: Textinformationen om händelsen. För Query Begin och Query End händelser är informationen DAX-frågan. För DirectQuery Begin och DirectQuery End händelser är informationen den SQL-fråga som skickas till den underliggande källan. Värdet TextData för den markerade händelsen visas också i fönstret längst ned på skärmen.
• EndTime: Tiden då händelsen slutfördes.
• Varaktighet: Varaktigheten i millisekunder tog det att köra DAX- eller SQL-frågan.
• Fel: Om ett fel inträffade, i vilket fall händelsen också visas i rött.

Föregående bild begränsar några av de mindre intressanta kolumnerna, så att du lättare kan se de mer intressanta kolumnerna.

Följ den här metoden för att samla in en spårning för att diagnostisera ett potentiellt prestandaproblem:

1. Öppna en enda Power BI Desktop-session för att undvika förvirring i flera arbetsytemappar.

2. Utför de åtgärder som är intressanta i Power BI Desktop. Inkludera några fler åtgärder för att säkerställa att händelser av intresse spolas in i spårningsfilen.

3. Öppna SQL Server Profiler och granska spårningen. Kom ihåg att om du stänger Power BI Desktop tas spårningsfilen bort. Dessutom visas inte ytterligare åtgärder i Power BI Desktop omedelbart. Du måste stänga och öppna spårningsfilen igen för att se nya händelser.

Håll enskilda sessioner någorlunda små, kanske 10 sekunders åtgärder, inte hundratals. Den här metoden gör det enklare att tolka spårningsfilen. Det finns också en gräns för spårningsfilens storlek, så för långa sessioner finns det en risk att tidiga händelser släpps.

Fråge- och underfrågeformat

Det allmänna formatet för Power BI Desktop-frågor är att använda underfrågor för varje modelltabell som frågereferensen. Den Power Query-redigeraren frågan definierar undervalsfrågorna. Anta till exempel att du har följande TPC-DS-tabeller i en SQL Server-relationsdatabas:

I det visuella Power BI-objektet definierar följande uttryck måttet SalesAmount :

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

När du uppdaterar det visuella objektet skapas T-SQL-frågan i följande bild. Det finns tre underfrågor för tabellerna Web_Sales, Itemoch modell Date_dim . Varje fråga returnerar alla modelltabellkolumner, även om det visuella objektet endast refererar till fyra kolumner.

Dessa skuggade underfrågor är den exakta definitionen av Power Query-frågorna. Den här användningen av underfrågor påverkar inte prestanda för de datakällor som DirectQuery stöder. Datakällor som SQL Server optimerar bort referenserna till de andra kolumnerna.

En orsak till att Power BI använder det här mönstret är att du kan definiera en Power Query-fråga för att använda en specifik frågeuttryck. Power BI använder frågan enligt angivet, utan att försöka skriva om den. Det här mönstret begränsar användningen av frågeinstruktioner som använder Common Table Expressions (CTE) och lagrade procedurer. Du kan inte använda dessa instruktioner i underfrågor.

Gatewayprestanda

Information om hur du felsöker gatewayprestanda finns i Felsöka gatewayer – Power BI.

Relaterat innehåll

Mer information om DirectQuery finns i följande resurser:

• Använda DirectQuery i Power BI Desktop
• Datakällor som stöds av DirectQuery
• DirectQuery-modeller i Power BI Desktop
• Vägledning för DirectQuery-modell i Power BI Desktop

Frågor? Prova att fråga Power BI Community