Om bruk av DirectQuery i Power BI

Du kan koble til alle slags forskjellige datakilder når du bruker Power BI Desktop eller Power BI-tjenesten, og gjøre disse datatilkoblingene på forskjellige måter. Du kan importere data til Power BI, som er den vanligste måten å hente data på, eller koble direkte til data i det originale kilderepositoriet, kjent som DirectQuery. Artikkel beskriver egenskaper for DirectQuery:

  • Ulike tilkoblingsmuligheter for DirectQuery
  • Veiledning for når du bør vurdere å bruke DirectQuery i stedet for import
  • Ulempene ved å bruke DirectQuery
  • Anbefalte fremgangsmåter for bruk av DirectQuery

Følg de anbefalte fremgangsmåtene for bruk av import versus DirectQuery:

  • Du burde importere data til Power BI når mulig. Importering drar fordel av den høye ytelsen til spørringsmotoren for Power BI, og gir en svært interaktiv og fullt utstyrt opplevelse.
  • Hvis målene dine ikke kan møtes ved å importere data, vurder å bruke DirectQuery. Hvis dataene for eksempel endres ofte, og rapportene må gjenspeile de nyeste dataene, kan det være best med DirectQuery. Imidlertid er bruk av DirectQuery bare mulig når den underliggende datakilden kan gi interaktive spørsmål, mindre enn fem sekunder for den typiske samlede spørringen, og kan håndtere spørringsbelastningen som genereres. I tillegg burde listen med begrensninger for bruk av DirectQuery vurderes nøye.

Settet med egenskaper tilbydd av Power BI for import og DirectQuery utvikler seg over tid. Endringer vil inkludere å gi mer fleksibilitet når du bruker importerte data, slik at import kan brukes i flere tilfeller og eliminere noen av ulempene ved å bruke DirectQuery. Når du bruker DirectQuery, uavhengig av forbedringer, er ytelsen til den underliggende datakilden alltid en viktig vurdering. Hvis den underliggende datakilden er treg vil bruk av DirectQuery for kilden forbli umulig.

Artikkelen dekker DirectQuery med Power BI, og ikke SQL Server Analysis Services. DirectQuery er også en funksjon av SQL Server Analysis Services. Mange av detaljene beskrevet i artikkelen gjelder den funksjonen. Det er også viktige ulikheter. For informasjon om hvordan du bruker DirectQuery med SQL Server Analysis Services, se DirectQuery i SQL Server 2016 Analysis Services.

Artikkelen fokuserer på anbefalt arbeidsflyt for DirectQuery, der rapporten er opprettet i Power BI Desktop, men dekker også tilkobling direkte i Power BI-tjenesten.

Tilkoblingsmodus for Power BI

Power BI kobler til et stort antall varierte datakilder. Disse omfatter:

  • Onlinetjenester (Salesforce, Dynamics 365, andre)
  • Databaser (SQL Server, Access, Amazon Redshift, andre)
  • Enkle filer (Excel, JSON, andre)
  • Andre datakilder (Spark, nettsteder, Microsoft Exchange, andre)

For disse kildene er det mulig å importere dataene til Power BI. For noen er det også mulig å koble til ved hjelp av DirectQuery. Hvis du vil ha en oppsummering over datakilder som støtter DirectQuery kan du se Datakilder som støttes av DirectQuery. Flere kilder vil bli aktivert for DirectQuery i fremtiden, der vi fokuserer først og fremst på kilder som kan forventes å levere god interaktiv spørringsytelse.

SQL Server Analysis Services er et spesielt tilfelle. Når du kobler deg til SQL Server Analysis Services kan du velge å importere data eller bruke en direkte tilkobling. Bruk av direkte tilkobling ligner på DirectQuery. Ingen data importeres, og den underliggende datakilden spørres alltid for å oppdatere et visualobjekt. En direkte tilkobling er forskjellig fra mange andre forhold, så med andre ord brukes direkte tilkobling versus DirectQuery.

Disse tre alternativene for tilkobling til data: import, DirectQuery og direkte tilkobling.

Import-tilkoblinger

For import, ved bruk av Hent data i Power BI Desktop for å koble til en datakilde som SQL Server, er oppførselen for tilkoblingen som følgende:

  • Under den innledende Hent data-opplevelsen definerer det valgte tabellsettet hver sin spørring, som vil returnere et sett med data. Spørringene kan redigeres før dataene lastes inn, for eksempel for å bruke filtre, aggregere dataene, eller sette sammen ulike tabeller.
  • Ved innlasting vil alle dataene som er definert av disse spørringene, bli importert til Power BI-hurtigbufferen.
  • Ved bygging av et visualobjekt i Power BI Desktop vil de importerte dataene spørres. Power BI sikrer at spørringen er rask. Alle endringer for visualobjektet reflekteres umiddelbart.
  • Alle endringer for de underliggende dataene reflekteres ikke i visualobjekter. Det er nødvendig å Oppdater for å importere data på nytt.
  • Ved publisering av rapporten som en .pbix-fil til Power BI-tjenesten opprettes et datasett som lastes inn i Power BI-tjenesten. De importerte dataene er inkludert i dette datasettet. Det er da mulig å planlegge en oppdatering av dataene, for eksempel å laste inn dataene på nytt hver dag. Avhengig av plasseringen av den originale datakilden kan det være nødvendig å konfigurere en lokal datainngang.
  • Når du åpner en eksisterende rapport i Power BI-tjenesten, eller forfatter en ny rapport, spørres de importerte dataene på nytt, som sikrer interaktivitet.
  • Visualobjekter, eller hele rapportsider, kan festes som instrumentbordfliser. Flisene oppdateres automatisk når det underliggende datasettet oppdateres.

DirectQuery-tilkoblinger

For DirectQuery, når du bruker Hent data i Power BI Desktop for å koble til en datakilde, er oppførselen for tilkoblingen som følgende:

  • Under den innledende Hent data-opplevelsen velges kilden. For relasjonskilder velges et tabellsett og hver definerer fremdeles en spørring som logisk returnerer et datasett. For flerdimensjonale kilder, for eksempel SAP BW, vil bare kilden velges.
  • Men ingen data importeres til Power BI ved lasting. I stedet for, ved bygging av et visualobjekt i Power BI Desktop, sendes spørringer til den underliggende datakilden for å hente nødvendig data. Tiden det tar å oppdatere visualobjektet er avhengig av ytelsen til den underliggende datakilden.
  • Alle endringer for de underliggende dataene reflekteres ikke umiddelbart i eksisterende visualobjekter. Det er fremdeles nødvendig å oppdatere. De nødvendige spørringene sendes på nytt for hvert visualobjekt, og visualobjektet oppdateres.
  • Ved publisering av rapporten til Power BI-tjenesten vil det på nytt resultere i et datasett i Power BI-tjenesten, det samme som for import. Det vil imidlertid ikke inkludere noen data i dette datasettet.
  • Når du åpner en eksisterende rapport i Power BI-tjenesten, eller forfatter en ny rapport, spørres den underliggende datakilden på nytt for å hente nødvendig data. Avhengig av plasseringen av den originale datakilden kan det være nødvendig å konfigurere en lokal datainngang, som for importmodus hvis dataene oppdateres.
  • Visualobjekter, eller hele rapportsider, kan festes som instrumentbordfliser. For å sikre at åpningen av et instrumentbord er rask blir flisene automatisk oppdatert etter en plan, for eksempel hver time. Frekvensen for oppdateringen kan kontrolleres for å gjenspeile hvor ofte dataene endres, og hvor viktig det er å se de nyeste dataene. Når du åpner et instrumentbord reflekterer flisene dataene på tidspunktet for den siste oppdateringen, og ikke nødvendigvis de siste endringene som ble gjort i den underliggende kilden. Du kan oppdatere et åpent instrumentbord for å sikre at det er gjeldende.

Aktive tilkoblinger

Når du kobler deg til SQL Server Analysis Services er det et alternativ enten å importere data fra eller koble direkte til den valgte datamodellen. Hvis du bruker import definerer du en spørring mot den eksterne kilden til SQL Server Analysis Services, og dataene blir importert som normalt. Hvis du bruker direkte tilkobling er det ingen definert spørsmål, og hele den eksterne modellen vises i feltlisten.

Situasjonen beskrevet i forrige avsnitt gjelder også tilkobling til følgende kilder, forvent at det ikke er alternativ for å importere dataene:

  • Power BI-datasett, for eksempel når du kobler deg til et Power BI-datasett som er opprettet tidligere og publisert til tjenesten, for å skrive en ny rapport over den.
  • Microsoft Dataverse.

Oppførselen til rapporter over SQL Server Analysis Services, etter publisering til Power BI-tjenesten, ligner på DirectQuery-rapporter på følgende måter:

  • Når du åpner en eksisterende rapport i Power BI-tjenesten, eller forfatter en ny rapport, spørres den underliggende SQL Server Analysis Services-kilden, noe som kan kreve en lokal datainngang.
  • Instrumentbordfliser oppdateres automatisk etter en plan, for eksempel hver time.

Det er også viktige ulikheter. Eksempel: For direkte tilkoblinger, sendes alltid identiteten til brukeren som åpner rapporten til den underliggende SQL Server Analysis Services-kilden.

Med disse sammenligningene ute av veien kan vi fokusere på DirectQuery resten av artikkelen.

Når er DirectQuery nyttig?

Følgende tabell beskriver scenarioer hvor tilkobling med DirectQuery kan være spesielt nyttig. Det inkluderer tilfeller hvor det å etterlate dataene i originalkilden kan være fordelaktig. Beskrivelsen inneholder en diskusjon om hvorvidt det angitte scenarioet er tilgjengelig i Power BI.

Begrensning Beskrivelse
Data endres jevnlig, og det er behov for rapportering i tilnærmet sanntid Modeller med importerte data kan oppdateres maks én gang per time (oftere hvis man har Power BI Pro eller et Power BI Premium-abonnement). Hvis dataene endres kontinuerlig, og det er nødvendig for rapporter å vise de nyeste dataene, vil kanskje ikke import med planlagt oppdatering møte disse behovene. Du kan strømme data direkte til Power BI, selv om det er begrensninger for datavolumet som støttes i dette tilfellet.

Ved bruk av DirectQuery derimot vil det å åpne eller oppdatere en rapport eller et instrumentbord alltid vise de nyeste dataene i kilden. I tillegg kan instrumentbordflisene oppdateres oftere, så ofte som hvert 15. minutt.
Svært store data Hvis dataene er svært store vil de ikke være mulige å importere. DirectQuery derimot krever ikke store overføringer av data fordi de spørres på plass.

Men store data kan også antyde at ytelsen til spørringene mot den underliggende kilden er for treg, som diskutert i Implikasjoner ved bruk av DirectQuery. Du må ikke alltid importere fullt detaljerte data. I stedet for kan dataene før-aggregeres under import. Den Power Query-redigering gjør det enkelt å forhåndsaggregere under import. I ekstreme tilfeller vil det være mulig å importere nøyaktig de aggregerte dataene som er nødvendige for hvert visualobjekt. Mens DirectQuery er den enkleste tilnærmingen til store data kan import av aggregeringsdata være en løsning hvis den underliggende kilden er for treg.
Sikkerhetsregler er definert i den underliggende datakilden Når dataene importeres kobles Power BI til datakilden ved å bruke den gjeldende brukerens legitimasjon fra Power BI Desktop, eller legitimasjonene som er definert som en del av konfigurering av planlagt oppdatering fra Power BI-tjenesten. Når du publiserer og deler en slik rapport med data i importeringsmodus, må du være forsiktig så du bare deler med brukere som får lov til å se de samme dataene, eller definere sikkerhetsnivået på raden som en del av datasettet.

DirectQuery gjør det mulig å sende en rapportlesers legitimasjon til den underliggende kilden og ta i bruk sikkerhetsreglene der. Enkel pålogging støttes for SQL Azure-datakilder og gjennom datagatewayen til lokale SQL-servere. Dette beskrives mer detaljert i Oversikt over enkel pålogging (SSO) for gatewayer i Power BI.
Begrensninger for datasuverenitet gjelder Noen organisasjoner har retningslinjer rundt datasuverenitet, som betyr at data ikke kan forlate organisasjonens lokaler. En løsning basert på import vil åpenbart føre til problemer. Med DirectQuery forblir derimot dataene i den underliggende datakilden.

Men selv med DirectQuery lagres noen cacher av data på nivået for visualobjekter i Power BI-tjenesten på grunn av planlagt oppdatering av fliser.
Den underliggende datakilden er en OLAP-kilde som inneholder målinger Hvis den underliggende datakilden inneholder målinger, som SAP HANA eller SAP Business Warehouse, vil import av data bringe med seg andre problemer. Det betyr at dataene som importeres, er på et bestemt nivå av aggregasjon, som definert av spørringen. Eksempel: Målingene TotalSales etter Class, Year, og City. Hvis et visualobjekt bygges og ber om data på et høyere nivå, for eksempel TotalSales innen År, aggregerer det ytterligere den aggregerte verdien. Aggregeringen er ikke et problem for additive målinger, som Sum og Min, men det er et problem for ikke-additive målinger, som Average, DistinctCount.

For å gjøre det enkelt å få riktig aggregert data, etter behov for det aktuelle visualobjektet, direkte fra kilden, ville det være nødvendig å sende spørringer per visualobjekt, som i DirectQuery.

Når du kobler til SAP Business Warehouse (BW), vil du kunne få denne behandlingen for målinger ved å velge DirectQuery. For informasjon om SAP BW se DirectQuery og SAP BW.

For øyeblikket behandler DirectQuery over SAP HANA det samme som en relasjonskilde, og behandler import likt. Denne tilnærmingen dekkes ytterligere i DirectQuery og SAP HANA.

Oppsummert, gitt nåværende kapasiteter for DirectQuery i Power BI, tilbyr det fordelene i følgende scenarioer:

  • Data endres jevnlig, og det er behov for rapportering i tilnærmet sanntid.
  • Håndtere svært store data, uten behov for før-aggregering.
  • Begrensninger for datasuverenitet gjelder.
  • Kilden er en multidimensjonal kilde som inneholder målinger, som SAP BW.

Detaljene i listen over gjelder for bruk av Power BI alene. Hvis du vil ha mer informasjon om hvordan du bruker store modeller i Power BI, kan du se store datasett i Power BI Premium. Det er ingen restriksjoner for hvor ofte dataene kan oppdateres.

Implikasjoner ved bruk av DirectQuery

Bruk av DirectQuery har potensielt negative implikasjoner, som nærmere forklart i dette avsnittet. Noen av disse begrensningene varierer avhengig av nøyaktig hvilken kilde som brukes. Vi adresserer begrensninger hvor gjeldende, og separate artikler dekker kildene som er vesentlig forskjellige.

Ytelse og belastning på den underliggende datakilden

Når du bruker DirectQuery avhenger den samlede opplevelsen i stor grad av ytelsen til den underliggende datakilden. Det er rimelig at det å oppdatere hvert visualobjekt tar noen sekunder (vanligvis mindre enn fem sekunder), for eksempel etter å ha endret en utsnittsverdi. Opplevelsen kan føles treg sammenlignet med den umiddelbare responsen når du importerer dataene til Power BI. Hvis kildene er så trege at individuelle visualobjekter bruker lengre tid enn ti sekunder blir opplevelsen veldig dårlig. Spørringer kan til og med gå ut på tid.

Følg med på belastningen på kilden, i tillegg til ytelsen for den underliggende kilden. Belastningspåvirkning på ytelsen. Hver bruker som åpner en delt rapport, og hver instrumentbordflis som oppdateres, sender minst én spørring per visualobjekt til den underliggende kilden. Dette krever at kilden kan håndtere en slik spørringsbelastning, samtidig som den opprettholder rimelig ytelse.

Sikkerhetsimplikasjoner ved kombinasjon av datakilder

Det er mulig å bruke flere datakilder i en DirectQuery-modell, akkurat som når du importerer data med funksjonen Sammensatte modeller. Når du bruker flere datakilder er det viktig å forstå hvordan data flyttes frem og tilbake mellom de underliggende datakildene, og sikkerhetsimplikasjoner det fører med seg.

Begrensede datatransformasjoner

På samme måte finnes det begrensninger i datatransformasjonene som kan brukes i Power Query-redigering. Med importert data kan et sofistikert sett av transformasjoner enkelt brukes for å rense og omforme dataene før de brukes til å opprette visualobjekter, som å analysere JSON-dokumenter, eller flytte data fra en kolonne til et rad-skjema. Disse transformasjonene er mer begrenset i DirectQuery.

Først, når du kobler deg til en OLAP-kilde som SAP Business Warehouse kan ingen transformasjoner defineres, og hele den eksterne modellen tas fra kilden. Av relasjonskilder, som SQL Server, er det fremdeles mulig å definere et sett av transformasjoner per spørring, men transformasjonene er begrenset av ytelsesgrunner.

Slike transformasjoner må brukes på hver spørring for den underliggende kilden, heller enn en gang ved dataoppdatering, slik at de er begrenset til transformasjonene som rimelig kan oversettes til en enkel opprinnelig spørring. Hvis du bruker en transformasjon som er for kompleks mottar du en feilmelding som enten må slettes eller modellen må byttes til import.

I tillegg vil spørringen som kommer fra dialogboksen Hent data eller Power Query-redigering bli brukt i en merking i spørringene som genereres og sendes for å hente de nødvendige dataene for et visualobjekt. Spørringen som er definert i Power Query-redigering, må være gyldig i denne konteksten. Spesielt er det ikke mulig å bruke en spørring ved hjelp av vanlige tabelluttrykk, heller ikke ett som påkaller lagrede prosedyrer.

Begrensninger for modellering

Begrepet modellering i denne sammenhengen betyr justering og forbedring av rådata som del av opprettingen av en rapport, der disse brukes. Eksempler omfatter:

  • Definere relasjoner mellom tabeller
  • Legge til nye beregninger (beregnede kolonner og målinger)
  • Gi nytt navn til, og skjule kolonner og målinger
  • Definere hierarkier
  • Definere formateringen, standardoppsummeringen og sorteringsrekkefølgen for en kolonne
  • Gruppere eller klynge verdier

Ved bruk av DirectQuery kan mange av modellberikelsene fremdeles opprettes, og det er fremdeles prinsippet at rådataene suppleres for å forbedre senere forbruk. Men det er noen modelleringsfunksjoner som ikke er tilgjengelige, eller begrensede, ved bruk av DirectQuery. Begrensningene brukes vanligvis for å unngå ytelsesproblemer. Settet med begrensninger som er vanlige for alle DirectQuery-kilder er listet opp her. Tilleggsbegrensninger kan gjelde for individuelle kilder, som beskrevet i Neste trinn.

  • Har ikke innebygd datohierarki: Ved import av data vil hver kolonne for dato og klokkeslett bestå av et innebygd datohierarki tilgjengelig som standard. Eksempel: Ved import av en tabell for salgsordre, inkludert en kolonne for OrderDate, vil det ved å bruke en OrderDate i et visualobjekt være mulig å velge aktuelt bruksnivå (år, måned, dag). Dette innebygde datohierarkiet er ikke tilgjengelig ved bruk av DirectQuery. Hvis en tabell for Dato er tilgjengelig i den underliggende kilden, som er vanlig for mange datalagre, kan funksjonen DAX-tidsintelligens brukes som normalt.
  • Støtte for dato/klokkeslett bare til sekundnøyaktighet: Når du bruker tidskolonner i datasettet, utsteder Power BI bare spørringer til den underliggende kilden ned til sekundnivå. Spørringer sendes ikke til DirectQuery-kilden i millisekunder. Fjern denne delen av tidene fra kildekolonnene.
  • Begrensninger i beregnede kolonner: Beregnede kolonner er begrenset til å være radinterne, som vil si at de bare kan referere til verdiene i andre kolonner i samme tabell, uten bruk av noen mengdefunksjoner. I tillegg er DAX-skalarfunksjonene som er tillatt, som LEFT(), begrenset til funksjonene som kan skyves til den underliggende kilden. Funksjonene varier avhengig av de eksakte kapasitetene til kilden. Funksjoner som ikke støttes er ikke listet i autofullfør når du skriver DAX for en beregnet kolonne, og vil føre til en feil hvis den brukes.
  • Ingen støtte for overordnede/underordnede DAX-funksjoner: Det er ikke mulig å bruke familien av DAX PATH()funksjoner som generelt håndterer strukturer for foreldre-barn når i modusen DirectQuery, slik som kontodiagrammer eller hierarkier for ansatte.
  • Beregnede tabeller: Du kan bruke beregnede tabeller i DirectQuery når du bruker sammensatte modeller.
  • Relasjonsfiltrering: For mer informasjon om toveis filtrering se Toveis kryssfiltrering. Tavlen representerer eksempler i konteksten av SQL Server Analysis Services. De grunnleggende poengene gjelder likt for Power BI.
  • Ingen klynging: Ved bruk av DirectQuery er det ikke mulig å bruke Klynger-funksjonen til automatisk å finne grupper.

Begrensninger for rapportering

Nesten alle rapporteringsfunksjoner støttes for DirectQuery-modeller. Følgelig kan det samme settet med visualiseringer brukes så lenge den underliggende datakilden tilbyr et passende ytelsesnivå. Det er noen viktige begrensinger i noen av de andre funksjonene i Power BI-tjenesten etter en rapport publiseres:

  • Hurtiginnsikter støttes ikke: Hurtiginnsikter i Power BI søker gjennom ulike delsett av datasettet og bruker et sett med avanserte algoritmer til å oppdage potensielt interessante innsikter. Gitt behovet for svært høytytende spørringer er ikke denne funksjonen tilgjengelig på datasett ved bruk av DirectQuery.
  • Bruk av Utforsk i Excel vil sannsynligvis resultere i dårligere ytelse: Du kan utforske dataene dine ved bruk av Utforsk i Excel-funksjonen på et datasett. Tilnærmingen tillater at Pivottabeller og Pivotdiagrammer opprettes i Excel. Selv om funksjonen støttes på datasett ved bruk av DirectQuery er ytelsen generelt tregere enn å opprette visualobjekter i Power BI, hvis Excel er viktig for scenarioene burde dette tas med i vurderingen når du skal avgjøre om du vil bruke DirectQuery.
  • Hierarkier vises ikke i Excel: Når du kobler til ved hjelp av DirectQuery fra Excel til en Azure Analysis Services modell eller Et Power BI-datasett, for eksempel ved hjelp av Analyser i Excel, vises ikke alle hierarkier som er definert i modellen eller datasettet.
  • Maksimal lengde for tekstkolonner: Den maksimale lengden på dataene i en tekstkolonne for datasett som bruker DirectQuery, er 32 764 tegn. Rapportering om lengre tekster enn dette vil føre til en feil.

Sikkerhet

Som beskrevet tidligere i denne artikkelen, med mindre du bruker enkel pålogging for datakilden, bruker en rapport i DirectQuery alltid den samme faste legitimasjonen til å koble til den underliggende datakilden, etter at den er publisert til Power Bi-tjeneste. Det er nødvendig å konfigurere legitimasjonen for brukeren som skal brukes umiddelbart etter publiseringen av en DirectQuery-rapport. Til du konfigurerer legitimasjonen vil åpning av rapporten i Power BI-tjenesten resultere i en feil.

Når du kobler til Power BI-datasett og Analysis Services i DirectQuery-modus, brukes enkel pålogging alltid, så sikkerheten ligner på live-tilkoblinger til Analysis Services.

Når brukerlegitimasjonen er gitt vil legitimasjonen brukes uavhengig av hvilken bruker som åpner rapporten. På denne måten er det akkurat som med importert data. Hver bruker ser de samme dataene, med mindre sikkerheten for radnivå er definert som del av rapporten. Samme oppmerksomhet må rettes til deling av rapporten hvis det er sikkerhetsregler definert i den underliggende kilden.

I tillegg støttes ikke «alternativ legitimasjon» når du oppretter DirectQuery-tilkoblinger til SQL Server fra Power BI Desktop. Du kan bruke gjeldende Windows-legitimasjon eller legitimasjonen for databasen.

Virkemåte i Power BI-tjenesten

Dette avsnittet beskriver oppførselen til en DirectQuery-rapport i Power BI-tjenesten for å beskrive belastningsgraden som vil bli plassert på back-end datakilden, gitt antallet brukere som rapporten og instrumentbordet vil bli delt med, kompleksiteten av rapporten, og om sikkerhetsnivået på radnivå er definert i rapporten.

Rapporter – åpne, samhandle med, redigere

Når en rapport åpnes oppdateres alle visualobjektene på siden som vises. Hvert visualobjekt krever generelt minst én spørring til den underliggende datakilden. Noen visualobjekter kan kreve mer enn én spørring. Hvis et visualobjekt for eksempel viser aggregeringsverdier fra to ulike faktatabeller, inneholder en mer kompleks måling, eller inneholder totaler av en ikke-additiv måling som Antall distinkt. Flytting til ny side oppdaterer visualobjektene. Oppdatering sender et nyt sett med spørringer til den underliggende kilden.

Hver brukerhandling i rapporten kan resultere i at visualobjekter oppdateres. Eksempel: Å velge en annen verdi på et utsnitt krever at et nytt sett spørringer sendes for å oppdatere alle påvirkede visualobjekter. Det samme gjelder hvis du klikker på et visualobjekt for å kryssutheve andre visualobjekter eller endrer et filter.

Tilsvarende krever redigering av en ny rapport at spørringer sendes for hvert steg på veien for å produsere det endelige visualobjektet.

Det er noe hurtigbufring av resultater. Oppdateringen av et visualobjekt er øyeblikkelig hvis nøyaktig de samme resultatene nylig er oppnådd. Hvis sikkerheten på radnivå er definert, deles ikke slike hurtigbufre på tvers av brukere.

Oppdatering av instrumentbord

Individuelle visualobjekter, eller hele sider, kan være festet til instrumentbordet som fliser. Fliser basert på datasett i DirectQuery oppdateres automatisk i henhold til en plan. Fliser sender spørringer til back-end datakilden. Som standard oppdateres datasett hver time, men kan konfigureres som del av datasettinnstillinger til mellom ukentlig og hvert 15 minutt.

Hvis ingen sikkerhet for radnivå er definert i modellen oppdateres hver flis én gang, og resultatet deles med alle brukere. Ellers kan det bli en stor multiplikatoreffekt. Hver flis krever separate spørringer per bruker for å sende til den underliggende kilden.

Et instrumentbord med ti fliser, delt med 100 brukere, opprettet på et datasett ved hjelp av DirectQuery med sikkerhet på radnivå, og konfigurert til å oppdatere seg hvert 15 minutt, vil resultere i minst 1000 spørringer sendt hvert 15 minutt til back-end kilden.

Vær spesielt oppmerksom på bruken av sikkerhet på radnivå, og konfigurasjonen av oppdateringsplanen.

Tidsavbrudd

Et tidsavbrudd på fire minutter anvendes for individuelle spørringer i Power BI-tjenesten. Spørringer som bruker lenger tid enn det mislykkes. Som nevnt tidligere anbefaler vi at du bruker DirectQuery for kilder som gir nær interaktiv spørringsytelse. Grensen er ment å forhindre problemer fra overlange utførelsestimer.

Andre implikasjoner

Noen andre generelle implikasjoner ved bruk av DirectQuery er som følgende:

  • Hvis data endrer seg er det nødvendig å oppdagere for å sikre at de nyeste dataene vises: Gitt bruken av mellomlagre er det ingen garanti for at visualobjektet alltid viser de nyeste dataene. Et visualobjektet kan for eksempel vise transaksjonene for den siste dagen. Den kan oppdatere seg for å vise transaksjoner for de siste to dagene hvis et utsnitt endres. Transaksjonene kan inkludere nylige ankomne transaksjoner. Ved å returnere utsnittet til sin originale verdi vil den på nytt vise den mellomlagrede verdien som oppnådd tidligere.

    Ved å velge Oppdater ryddes alle mellomlager og alle visualobjektene på siden oppdateres til å vise nyeste data.

  • Hvis data endrer seg er det ingen garanti for konsistens mellom visualobjekter: Forskjellige visualobjekter, enten på samme side eller på forskjellige sider, kan oppdateres på forskjellige tidspunkt. Hvis dataene i den underliggende kilden endres er det ingen garanti for at hvert visualobjekt viser dataene på eksakt samme tidspunkt. Gitt at det noen ganger kreves mer enn én spørring for et enkelt visualobjekt, for eksempel for å oppnå detaljene og totalene, da er ikke konsistensen selv i et enkelt visualobjekt garantert. For å garantere konsistensen vil det kreve at alle visualobjekter oppdateres når ethvert visualobjekt oppdateres, sammen med bruk av kostbare funksjoner som Snapshot Isolation i den underliggende datakilden.

    Problemet kan i stor grad reduseres ved å velge Oppdater for å oppdatere alle visualobjektene på siden. Selv om du bruker importmodus er det et lignende problem med å garantere konsistens mens du importerer data fra mer enn én tabell.

  • Oppdatering i Power BI Desktop er nødvendig for å gjenspeile metadataendringer:Oppdatere vil oppdatere visualobjektene i rapporten etter at en rapport er publisert. Hvis skjemaet for den underliggende kilden er endret vil ikke endringene automatisk anvendes for å endre tilgjengelige felt i feltlisten. Hvis tabeller eller kolonner er fjernet fra den underliggende kilden kan det resultere i en spørringsfeil ved oppdatering. Ved å åpne rapporten i Power BI Desktop og velge Oppdater vil feltene i modellen oppdateres og vise endringene.

  • Grense på en million rader returnert for alle spørringer: Det er satt en grense på én million rader plassert på antall rader som kan returneres i alle enkelte spørringer for den underliggende kilden. Grensen har generelt ingen praktiske implikasjoner og visualobjekter kommer ikke til å vise så mange poeng. Men grensen kan forekomme i tilfeller hvor Power BI ikke fullt ut optimaliserer de sendte spørringene, og når mellomliggende resultater som overskrider grensen etterspørres. Det kan også forekomme når et visualobjekt bygges, på veien til en mer fornuftig, endelig tilstand. Eksempel: Inkludering av Customer og TotalSalesQuantity vil nå grensen hvis det er over en million kunder, til filtre anvendes.

    Feilen returnert ville være: «Resultatet av en spørring til ekstern datakilde har oversteget maksimal tillatt størrelse på 1 000 000 rader.»

    Obs!

    Radgrensen på én million kan overskrides i Premium-kapasiteter. Hvis du vil ha mer informasjon, kan du se maksimalt antall rader på mellomnivå.

  • Kan ikke bytte modus fra import til DirectQuery: All nødvendig data må importeres når du bytter en modell fra DirectQuery-modus til importmodus. Det er ikke mulig å bytte tilbake, primært fordi settet med funksjoner som ikke støttes i DirectQuery-modus. DirectQuery-modeller over multidimensjonale kiler, som SAP BW, kan ikke byttes fra DirectQuery til import på grunn av de forskjellige behandlingene av eksterne målinger.

DirectQuery i Power BI-tjenesten

Alle kilder støttes fra Power BI Desktop. Noen kilder er også tilgjengelige direkte i Power BI-tjenesten. Det er for eksempel mulig for en bedriftsbruker å bruke Power BI for å koble til data i Salesforce og umiddelbart få et instrumentbord, uten bruk av Power BI Desktop.

Bare to av de DirectQuery-aktiverte kildene er tilgjengelige direkte i tjenesten:

  • Spark
  • Azure Synapse Analytics (tidligere SQL Data Warehouse)

Vi anbefaler at all bruk av DirectQuery over de to kildene starter i Power BI Desktop. Grunnen til dette er at når tilkoblingen opprinnelig er opprettet i Power BI-tjenesten, mange viktige begrensninger vil gjelde. Selv om startpunktet var enkel, i Power BI-tjenesten, er det begrensninger for å forbedre den resulterende rapporten ytterligere. Det er for eksempel ikke mulig å opprette beregninger, bruke mange av analysefunksjonene, eller til og med oppdatere metadataene for å reflektere endringer for det underliggende skjemaet.

Retningslinjer for vellykket bruk av DirectQuery

Hvis du skal bruke DirectQuery gir denne seksjonen deg veiledning på høyt nivå for hvordan du sikrer deg suksess. Veiledningen i denne delen er basert på implikasjonene ved bruk av DirectQuery som er beskrevet i denne artikkelen.

Back-end datakildeytelse

Bekrefte at enkle visualobjekter oppdateres innen fornuftig tid. Oppdateringstid burde være innen fem sekunder for å ha en fornuftig interaktiv opplevelse. Hvis visualobjekter bruker lenger tid enn 30 sekunder er det svært sannsynlig at ytterligere problemer vil oppstå etter publikasjon av rapporten. Problemene kan gjøre løsningen ubrukelig.

Hvis spørringer er trege kan du undersøke spørringene som sendes til den underliggende kilden, og grunnen til spørringsytelsen. Artikkelen dekker ikke det brede spekteret av beste praksis for databaseoptimalisering i hele settet med potensielle underliggende kilder. Artikkelen dekker standard databasepraksiser som gjelder de fleste situasjoner:

  • Forhold basert på heltallkolonner yter generelt bedre enn sammenføyninger på kolonner med andre datatyper.
  • Aktuelle indekser bør opprettes. Indeksopprettelse betyr generelt bruken av butikkindekser i kolonner i kildene som støtter dem, for eksempel SQL Server.
  • All nødvendig statistikk i kilden burde oppdateres.

Veiledning for modellutforming

Vurder følgende veiledning når du definerer modellen:

  • Unngå komplekse spørringer i Power Query-redigering. Power Query-redigering oversetter en kompleks spørring til én sql-spørring. Den enkle spørringen vises i merkingen til hver spørring som sendes til tabellen. Hvis spørringen er kompleks, kan det føre til ytelsesproblemer på hver spørring som sendes. Den faktiske SQL-spørringen for et sett med trinn kan hentes ved å velge det siste trinnet i Power Query-redigering, og velge Vis opprinnelig spørring fra hurtigmenyen.

  • Bruk enkle målinger. Det anbefales å begrense målingene til enkle aggregater, i det minste i starten. Hvis målingene yter tilstrekkelig kan du definere mer komplekse målinger, men du må følge med på ytelsen for hver av dem.

  • Unngå relasjoner på beregnede kolonner. Veiledningen er relevant for databaser hvor du må gjøre sammenføyninger av flere kolonner. Power BI tillater ikke for øyeblikket at et forhold er basert på flere kolonner som FK/PK. Den vanligste måten å løse dette på er ved å slå sammen kolonnene ved å bruke en beregnet kolonne, og basere sammenføyningen på kolonnen. Dette er fornuftig for importert data, men i DirectQuery vil resultatet være en sammenføyning på et uttrykk. Resultatet vil vanligvis forhindre bruk av alle indekser og føre til dårlig ytelse. Den eneste midlertidige løsningen er faktisk å materialisere flere kolonner i en enkelt kolonne i den underliggende databasen.

  • Unngå relasjoner på kolonner av typen uniqueidentifier. Power BI støtter ikke en datatype på uniqueidentifier. Definering av en relasjon mellom kolonner av type kolonne uniqueidentifier resulterer i en spørring med en sammenføyning som omfatter en rolle. Nok en gang, tilnærmingen kan føre til dårlig ytelse. Før dette tilfellet er spesielt optimalisert, er den eneste midlertidige løsningen å materialisere kolonner for en alternativ type i den underliggende databasen.

  • Gjem til-kolonnen på forhold. Kolonnen til på forhold er vanligvis den primære nøkkelen i tabellen til. Kolonnen burde være gjemt. Hvis den er gjemt vil den ikke vises i feltlisten og kan ikke brukes i visualobjekter. Ofte er kolonnene som forhold er basert på egentlig systemkolonner, for eksempel surrogatnøkler i et datalager. Det er uansett god praksis å gjemme kolonnene. Hvis kolonnen har mening kan du introdusere en beregnet kolonne som er synlig og som har et enkelt uttrykk for å være lik den primære nøkkelen, som i følgende eksempel:

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • Undersøk all bruk av beregnede kolonner og datatypeendringer. Bruk av disse kapasitetene er ikke nødvendigvis skadelig. De resulterer i at spørringene som sendes til den underliggende datakilden inneholder uttrykk heller enn enkle referanser til kolonner. Det kan igjen resultere i at indekser ikke brukes.

  • Unngå bruk av toveis kryssfiltrering på relasjonene. Bruk av toveis kryssfiltrering kan føre til spørringssetninger som ikke fungerer bra.

  • Eksperimenter med innstillingen Anta referanseintegritet. Innstilingen Anta referanseintegritet på forhold gjør at spørringer kan bruke erklæringene INNER JOIN heller enn OUTER JOIN. Veiledningen forbedrer generelt spørringsytelsen, men det avhenger av detaljene i datakilden.

  • Ikke bruk den relative datafiltreringen i Power Query-redigering. Det er mulig å definere relativ datofiltrering i Power Query-redigering. for eksempel for å filtrere radene der datoen er innenfor de siste 14 dagene.

    Filterrader de siste 14 dagene

    Men filteret er oversatt til et filter som er basert på den faste datoen, som på tidspunktet spørringen ble skrevet. Resultatet kan du se på den opprinnelige spørringen.

    Filterrader i opprinnelig SQL-spørring

    Resultatet er sannsynligvis ikke det du ønsket. For å sikre at filteret er basert på datoen når rapporten kjøres bruker du i stedet filteret i rapporten som et rapportfilter. Tilnærmingen gjennomføres for øyeblikket ved å lage en beregnet kolonne som beregner antall dager siden, ved å bruke funksjonen DAX DATE(), og deretter bruke den beregnede kolonnen i et filter.

Veiledning for rapportutforming

Følg denne veiledningen når du oppretter en rapport ved hjelp av DirectQuery-tilkobling:

  • Vurder bruk av alternativer for spørringsreduksjon: Power BI tilbyr alternativer i rapporten for å sende færre spørringer, og for å deaktivere visse interaksjoner som vil resultere i en dårlig opplevelse hvis de resulterende spørringene tar lang tid å kjøre. For tilgang til alternativene går du i Power BI Desktop til Fil>Alternativer og Innstillinger>Alternativer og velger Spørringsreduksjon.

    Alternativer for spørringsreduksjon

    Hvis du merker av i boksene for Spørringsreduksjon, kan du deaktivere kryssutheving i hele rapporten. Du kan også vise en knapp Bruk til utsnitt- eller filteralternativer. Tilnærmingen lar deg lage mange utsnitt- og filteralternativer før du bruker dem. Ingen spørringer sendes før du velger knappen Bruk i utsnittet. Valgene dine kan deretter brukes til å filtrere dataene.

    Alternativene anvendes på rapporten din når du samhandler med den i Power BI Desktop. Alternativene anvendes også når brukerne dine bruker rapporten i Power BI-tjenesten.

  • Bruk filtre først: Bruk alltid eventuelle gjeldende filtre når du begynner å bygge et visualobjekt. Du kan for eksempel i stedet for å dra inn TotalSalesAmount og ProductName, filtrere til et bestemt år, bruk filteret på År fra starten av. Hvert steg av byggingen av et visualobjekt sender en spørring. Selv om det er mulig å gjøre en annen endring før den første spørringen er fullført fører det til en unødvendig belastning på den underliggende datakilden. Ved å bruke filtre tidlig vil det vanligvis gjøre disse mellomliggende spørringene mindre kostbare. Hvis du ikke bruker filtre tidlig kan det føre til at du overskrider grensen på én million rader.

  • Begrens antallet visualobjekter per side: Når du åpner en side, eller endrer utsnitt eller filter for sidenivå, oppdateres alle visualobjektene på siden. Det er også en grense for antall spørringer som sendes i parallell. Når antall visualobjekter øker oppdateres noen av visualobjektene på en seriell måte, noe som øker tiden det tar å oppdatere hele siden. Det er derfor anbefalt å begrense antall visualobjekter per side og i stedet ha flere enklere sider.

  • Vurder å deaktivere samhandling mellom visualobjekter: Visualiseringer på en rapportside kan som standard brukes til å kryssfiltrere og kryssutheve de andre visualiseringene på siden. Har du for eksempel valgt 1999 på kakediagrammet utheves kolonnediagrammet for å vise salg etter kategori for 1999.

    Flere visualobjekter med kryssfiltrering og kryssutheving

    Kryssutheving og kryssfiltrering i DirectQuery krever at spørringer sendes til den underliggende kilden. Samhandlingene burde slås av hvis tiden det tar å svare på brukernes valg blir urimelig lang. Du kan deaktivere samhandlingen. Deaktiver samhandlingene for enten hele rapporten, som beskrevet ovenfor for alternativer for spørringsreduksjon, eller basert på hvert enkelt tilfelle. Hvis du vil ha mer informasjon, kan du se Slik kryssfiltreres visualobjekter i en Power BI-rapport.

I tillegg til de nevnte forslagene kan hver av de følgende funksjonene for rapportering bidra til ytelsesproblemer:

  • Målingsfiltre: Visualobjekter som inneholder målinger, eller aggregeringer av kolonner, kan inneholde filtre i målingene. Følgende grafikk viser for eksempel SalesAmount etter Category, men bare for kategorier med mer enn USD 20 millioner i salg.

    Visualobjekt viser målinger som inneholder filtre

    Tilnærmingen fører til at det sendes to spørringer til den underliggende datakilden:

    • Den første spørringen henter kategoriene som møter betingelsen SalesAmount som er høyere enn USD 20 millioner.
    • Den andre spørringen henter deretter de nødvendige dataene for visualobjektet, inkludert kategoriene som oppfyller vilkåret i klausul WHERE.

    Tilnærmingen utføres vanligvis problemfritt hvis det finnes hundrevis eller tusenvis av kategorier, som i dette eksemplet. Ytelsen kan reduseres hvis antall kategorier er mye større. Spørringen mislykkes for mer enn en million kategorier som møter forholdet. Radgrensen på én million ble diskutert tidligere.

  • TopN-filtre: Avanserte filtre kan defineres til å filtrere på bare topp eller bunn N-verdiene rangert etter noen mål. Filtre kan for eksempel inkludere topp ti kategorier i forrige visualobjekt. Tilnærmingen fører til at det sendes to spørringer til den underliggende datakilden. Den første spørringen vil imidlertid returnere alle kategorier fra den underliggende datakilden, og deretter vil TopN fastsettes basert på de returnerte resultatene. Avhengig av kardinaliteten for kolonnen som er involvert kan dette føre til ytelsesproblemer eller spørringsfeil på grunn av grensen på én million rader.

  • Median: Generelt skyves alle aggregeringer, som Sum eller Count Distinct, til den underliggende kilden. Dette er imidlertid ikke tilfellet for median, fordi dette aggregatet generelt ikke støttes av den underliggende kilden. I slike tilfeller hentes detaljerte data fra den underliggende datakilden, og medianen beregnet fra de returnerte resultatene. Dette er greit når medianen skal beregnes over et relativt lite antall resultater. Ytelsesproblemer eller spørringsfeil på grunn av grensen på én million rader oppstår hvis kardinaliteten er stor. Median for land/område befolkning kan for eksempel være rimelig, men median salgspris er kanskje ikke det.

  • Avanserte tekstfiltre (inneholder og lignende): Når du filtrerer på en tekstkolonne, vil den avanserte filtreringen tillate filtre som inneholder og begynner med og så videre. Disse filtrene kan selvfølgelig resultere i dårligere ytelse for noen datakilder. Spesielt standardfilteret inneholder burde ikke brukes hvis det kreves en nøyaktig match. Selv om resultatene kanskje blir de samme, avhengig av de faktiske dataene, kan ytelsen være drastisk annerledes på grunn av indekser.

  • Flervalg av slicere: Som standard tillater slicere bare enkeltvalg. Tillatelse av flervalg i filtre kan føre til noen ytelsesproblemer fordi brukeren velger et sett med elementer i utsnittet. Hvis brukeren for eksempel velger de ti produktene de er interessert i resulterer hvert nye valg i en ny spørring som sendes til den underliggende kilden. Brukeren kan velge det neste elementet før spørringen er fullført, noe som medfører ekstra belastning på den underliggende datakilden.

  • Vurder å deaktivere totaler på visualobjekter: Som standard viser tabeller og matriser totalsummer og delsummer. I mange tilfeller må separate spørringer sendes til den underliggende datakilden for å hente verdier for slike totalsummer. Dette gjelder når du bruker aggregater DistinctCount, og i alle tilfeller der du bruker DirectQuery over SAP HANA eller SAP HANA. Slike totaler skal slås av ved hjelp av ruten Format.

Alternativet maksimalt antall tilkoblinger for DirectQuery

Du kan angi det maksimale antallet DirectQuery-tilkoblinger som åpnes for hver underliggende datakilde, som styrer antallet spørringer som sendes til hver datakilde.

DirectQuery åpner et standard maksimum antall på ti tilkoblinger. Du kan endre maksimum antall nummer for den gjeldende filen i Power BI Desktop. Gå til Fil>Alternativer og innstillinger>Alternativer. Velg DirectQuery i venstre navigasjonsrute i delen Gjeldende fil.

Angi maksimalt antall DirectQuery-tilkoblinger

Innstillingen er aktivert bare når det er minst én DirectQuery-kilde i den gjeldende rapporten. Verdien gjelder for alle DirectQuery-kilder, og for eventuelle nye DirectQuery-kilder som er lagt til i den samme rapporten.

Hvis du øker verdien for maksimalt antall tilkoblinger per datakilde sikrer du at flere spørringer, opptil det maksimale antallet som er angitt, kan sendes til den underliggende datakilden. Dette er nyttig når det er mange visualobjekter på én side, eller mange brukere åpner en rapport samtidig. Når maksimalt antall tilkoblinger er nådd, settes ytterligere spørringer i kø inntil en tilkobling blir tilgjengelig. Å øke denne grensen resulterer i mer belastning på den underliggende kilden, så innstillingen garanterer ikke forbedring av den generelle ytelsen.

Når en rapport publiseres er det maksimale antallet samtidige spørringer som sendes til den underliggende datakilden også avhengig av faste grenser. Grensene er avhengige av målmiljøet hvor rapporten publiseres. Forskjellige miljøer, som Power BI, Power BI Premium eller rapportserver for Power BI, kan alle ilegge forskjellige begrensninger. Tabellen nedenfor viser de øvre grensene for de aktive tilkoblingene per datakilde for hvert Power BI-miljø. Disse grensene gjelder for skydatakilder og lokale datakilder, for eksempel SQL Server, Oracle og Teradata.

Miljø Øvre grense
Power BI Pro 10 aktive tilkoblinger per datakilde
Power BI Premium 30 aktive tilkoblinger per datakilde
Power BI Report Server 10 aktive tilkoblinger per datakilde

Obs!

Maksimalt antall DirectQuery-tilkoblingsinnstillinger gjelder for alle DirectQuery-kilder når forbedrede metadata er aktivert, som er standardinnstillingen for alle modeller som er opprettet i Power BI Desktop.

Diagnostisering av ytelsesproblemer

Denne delen beskriver hvordan du diagnostiserer problemer med ytelsen, eller hvordan du får mer detaljert informasjon for å tillate at rapportene skal optimaliseres.

Vi anbefaler at du starter diagnostisering av ytelsesproblemer i Power BI Desktop i stedet for i Power BI-tjenesten. Ytelsesproblemer er ofte basert på ytelsen til den underliggende kilden. Du enklere identifisere og diagnostisere problemer i det mer isolerte miljøet til Power BI Desktop. Tilnærmingen eliminerer innledningsvis visse komponenter, for eksempel Power BI-inngangen. Du bør fokusere undersøkelsene på de spesifikke delene av rapporten i Power BI-tjenesten, hvis du oppdager at ytelsesproblemene ikke er til stede med Power BI Desktop. Ytelsesanalyse er et nyttig verktøy for identifisering av problemer i denne prosessen.

På samme måte anbefales vi først å prøve å isolere eventuelle problemer til et enkelt visualobjekt, i stedet for mange visualobjekter på en side.

La oss si at trinnene i forrige paragraf i dette avsnittet er tatt. Vi har nå et enkelt visualobjekt på en side i Power BI Desktop som fortsatt er treg. For å fastslå hvilke spørringer som sendes til den underliggende kilden av Power BI Desktop, kan du bruke Performance Analyzer. Det er også mulig å se informasjon om sporing og diagnostikk som kan sendes av den underliggende datakilden. Sporinger kan også inneholde nyttig informasjon om detaljene for hvordan spørringen ble utført, og hvordan den kan forbedres.

Selv i mangel av slike sporinger fra kilden er det mulig å vise spørringer som sendes av Power BI, sammen med utførelsestidene, som blir beskrevet i neste avsnitt.

Fastslå spørringer som sendes av Power BI Desktop

Som standard logger Power BI Desktop hendelser i en gitt økt til en sporingsfil kalt FlightRecorderCurrent.trc.

For noen DirectQuery-kilder inneholder denne loggen alle spørringer som ble sendt til den underliggende datakilden. Gjenværende DirectQuery-kilder inkluderes i fremtiden. Følgende kilder sender spørringer til loggen:

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

Du finner sporingsfilen i AppData-mappen for gjeldende bruker:

<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

For å komme til denne mappen, velger du I Power BI Desktop Fil>Alternativer og innstillinger>Alternativer, og velger deretter Diagnostikk. Følgende dialog vises:

En kobling til mappen Sporinger

Når du velger Åpne krasjdump-/sporingsmappe, åpnes følgende mappe under Diagnosealternativer: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Hvis du går til denne mappens overordnede mappe vil det vise mappen som inneholder AnalysisServicesWorkspaces. Denne inneholder en undermappe for arbeidsområde for hver åpen forekomst av Power BI Desktop. Navnene på disse mappene slutter på et heltall, som AnalysisServicesWorkspace2058279583.

I denne mappen finner du en \Data-mappe . Den inneholder sporingsfilen FlightRecorderCurrent.trc for den gjeldende Power BI-økten. Den tilsvarende arbeidsområdemappen slettes når den tilknyttede Power BI Desktop-økten avsluttes.

Sporingsfilene kan leses ved hjelp av verktøyet SQL Server Profiler. Få det som del av den gratis nedlastningen SQL Server Management Studio.

Når du har lastet ned og installert SQL Server Management Studio, kjører du SQL Server Profiler.

SQL Server Profiler

Hvis du vil åpne sporingsfilen, gjør du følgende:

  1. I SQL Server Profiler, velger du Fil>Åpne>Spor fil.

  2. Skriv inn banen til sporingsfilen for den åpne Power BI-økten, for eksempel: C:\Brukere<bruker>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

  3. Åpne FlightRecorderCurrent.trc.

Alle hendelser fra den gjeldende økten vises. Et kommentert eksempel som uthever grupper av hendelser vises her. Hver gruppe har følgende hendelser:

  • En hendelse for Query Begin og Query End som representerer starten og slutten på en DAX-spørring som er generert av brukergrensesnittet, for eksempel fra et visualobjekt eller fra å fylle ut en liste over verdier i filterets brukergrensesnitt.
  • En eller flere par med hendelser for DirectQuery Begin og DirectQuery End, som representerer at en spørring sendes til den underliggende datakilden som del av evalueringen for DAX-spørringen.

Flere DAX-spørringer kan kjøres parallelt, slik at hendelser fra forskjellige grupper kan bli innfelt. Verdien for ActivityID kan brukes til å fastslå hvilke hendelser som tilhører samme gruppe.

SQL Server Profiler med hendelser for Forespørselstart og Forespørselslutt

Andre interessante kolonner er følgende:

  • Tekstdata: Detaljene for hendelsen i tekstformat. For Query Begin/End-hendelser er detaljen DAX-spørringen. For DirectQuery Begin/End-hendelser er detaljen SQL-spørringen sendt til den underliggende kilden. TextData for den merkede hendelsen vises også i området nederst.
  • Sluttid: Klokkeslettet hendelsen ble fullført.
  • Varighet: Varigheten i millisekunder for å utføre DAX- eller SQL-spørringen.
  • Feil: Angir om det oppstod en feil. I dette tilfellet vil hendelsen også vises i rødt.

Noen av de mindre interessante kolonnene i bildet over har blitt smalere, slik at de andre kolonnene er mer synlige.

Vi anbefaler følgende fremgangsmåte for å registrere en sporing, for å diagnostisere et potensielt ytelsesproblem:

  • Åpne en enkelt Power BI Desktop-økt, for å unngå forvirring fra flere arbeidsområdemapper.
  • Utfør settet med handlinger som er av interesse i Power BI Desktop. Inkluder noen flere handlinger, for å sikre at de interessante hendelsene tømmes til sporingsfilen.
  • Åpne SQL Server Profiler og undersøk sporingen som beskrevet tidligere. Husk at sporingsfilen slettes når du lukker Power BI Desktop. Videre handlinger i Power BI Desktop vises ikke umiddelbart. Du bør lukke sporingsfilen og åpne den på nytt for å se de nye hendelsene.
  • Hold individuelle sesjoner forholdsvis korte, kanskje ti sekunder med handlinger, ikke hundrevis. Tilnærming gjør det lettere å tolke sporingsfilen. Det er også en grense for størrelsen på sporingsfilen. For lange sesjoner er det en mulighet for at tidlige hendelser droppes.

Forstå spørringsformen som sendes av Power BI Desktop

Det generelle formatet for spørringer som genereres og sendes av Power BI Desktop bruker merking for hver av modelltabellene som det refereres til. Spørringen Power Query-redigering definerer merkingen. Anta for eksempel følgende TPC DS-tabeller i SQL Server:

TPC-DS-tabeller i SQL Server

Vurder følgende spørring:

En eksempelspørring

Denne spørringen resulterer i følgende bilde:

Visualobjekt for en spørring

Oppdatering av visualobjektet vil resultere i at T-SQL-spørringen vises her. Som du ser er det tre merkinger for Web Sales, Item og Date_dim. Hver av disse returnerer alle kolonnene i den respektive tabellen, selv om bare fire kolonner faktisk refereres til av visualobjektet. Disse spørringene i merkingene som er skyggelagt, er nøyaktig resultatet av spørringene som er definert i Power Query-redigering. Vi har ikke opplevd at bruk av merking på denne måten påvirker ytelsen til datakildene som så langt støttes for DirectQuery. Datakilder som SQL Server optimaliserer unna referansene til de andre kolonnene.

Power BI bruker dette mønsteret fordi SQL-spørringen som brukes kan gis direkte av analytikeren. Det brukes «som gitt», uten at det ble gjort forsøk på å skrive det på nytt.

SQL-spørring brukt som gitt

Neste trinn

Artikkelen beskriver aspekter ved DirectQuery som er vanlige for alle datakilder. Det finnes enkelte opplysninger som er spesifikke for individuelle kilder. Se disse artiklene som dekker spesifikke kilder:

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