Foretag fejlfinding af XMLA-slutpunktsforbindelse
XMLA-slutpunkter i Power BI afhænger af den Analysis Services kommunikationsprotokol for at få adgang Power BI datasæt. Derfor er fejlfinding af XMLA-slutpunkter stort set det samme som fejlfinding af en normal Analysis Services-forbindelse. Der er dog nogle forskelle, hvad angår Power BI-specifikke afhængigheder.
Inden du starter
Før du foretager fejlfinding af et scenarie med XMLA-slutpunkter, skal du gennemgå de grundlæggende principper, der er beskrevet under Netværksmulighed for datasæt med XMLA-slutpunktet. De mest almindelige brugseksempler med XMLA-slutpunkter beskrives der. Andre Power BI-fejlfindingsvejledninger, f. eks. Foretag fejlfinding af gateways – Power BI og Fejlfinding af Analysér i Excel, kan også være nyttige.
Aktivering af XMLA-slutpunktet
XMLA-slutpunktet kan aktiveres både i forbindelse med Power BI Premium, Premium Pr. bruger Power BI Embedded kapaciteter. I mindre kapaciteter, f. eks. en A1-kapacitet med kun 2,5 GB hukommelse, kan der opstå en fejl i kapacitetsindstillingerne, når du forsøger at angive XMLA-slutpunktet til at Læs/skriv og derefter vælge Anvend. I fejlmeddelelsen angives følgende: "Der opstod et problem med arbejdsbelastningsindstillingerne. Prøv igen om et øjeblik.".
Her er et par ting, du kan prøve:
- Begræns hukommelsesforbruget for andre tjenester i kapaciteten, f. eks. dataflows, til 40 % eller mindre, eller deaktiver en unødvendig tjeneste helt.
- Opgrader kapaciteten til en større SKU. Hvis du f. eks. opgraderer fra en A1- til en A3-kapacitet, løser dette konfigurationsproblemet, uden at du skal deaktivere dataflow.
Vær opmærksom på, at du også skal aktivere indstillingen Eksportér data på lejerniveau i Power BI-administrationsportalen. Denne indstilling er også påkrævet til funktionen Analysér i Excel.
Oprettelse af en klientforbindelse
Når du har aktiveret XMLA-slutpunktet, er det en god idé at teste forbindelsen til et arbejdsområde i kapaciteten. Du kan finde flere oplysninger under Opret forbindelse til et Premium-arbejdsområde. Du kan også læse afsnittet Forbindelses krav for at få nyttige tip og oplysninger om aktuelle begrænsninger for XMLA-forbindelser.
Oprettelse af forbindelse til en tjenesteprincipal
Hvis du har aktiveret lejerindstillinger for at tillade, at tjenesteprincipaler bruger Power BI-API'er som beskrevet i Aktivér tjenesteprincipaler, kan du oprette forbindelse til et XMLA-slutpunkt ved hjælp af en tjenesteprincipal. Vær opmærksom på, at tjenesteprincipalen kræver det samme niveau af adgangsrettigheder på arbejdsområde- eller datasætniveau som almindelige brugere.
Hvis du vil bruge en tjenesteprincipal, skal du sørge for at angive oplysningerne om applikationsidentitet i forbindelsesstrengen som:
User ID=<app:appid@tenantid>Password=<application secret>
Eksempel:
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:91ab91bb-6b32-4f6d-8bbc-97a0f9f8906b@19373176-316e-4dc7-834c-328902628ad4;Password=6drX...;
Hvis du får vist følgende fejl:
"Vi kan ikke oprette forbindelse til datasættet på grund af ufuldstændige kontooplysninger. For tjenesteprincipaler skal du angive lejer-id'et sammen med app-id'et ved hjælp af formatappen: <appId>@<tenantId> og derefter prøve igen. "
Sørg for, at du angiver lejer-id'et sammen med app-id'et i det korrekte format.
Det er også gyldigt at angive app-id'et uden lejer-id'et. I dette tilfælde skal du dog erstatte alisasset myorg i datakildens URL-adresse med det faktiske lejer-ID. Power BI kan derefter finde tjenesteprincipalen i den korrekte lejer. Men bedste praksis er at bruge aliasset myorg og angive lejer-id'et sammen med app-id'et i bruger-id-parameteren.
Oprettelse af forbindelse til Microsoft Azure Active Directory B2B
Med understøttelse af Microsoft Azure Active Directory (Azure AD) Business-to-business (B2B) i Power BI kan du give eksterne gæstebrugere adgang til datasæt via XMLA-slutpunktet. Kontrollér, at funktionen Del indhold med eksterne brugere er aktiveret i Power BI-administrationsportalen. Se Distribuer Power BI-indhold til eksterne gæstebrugere med Azure AD B2B.
Udrulning af et datasæt
Du kan udrulle et tabelmodelprojekt i Visual Studio (SSDT) til et arbejdsområde, der er knyttet til en Premium-kapacitet, og på stort set samme måde som en serverressource i Azure Analysis Services. Når du udruller, er der dog nogle yderligere overvejelser. Sørg for at gennemse afsnittet Udrul modelprojekter fra Visual Studio (SSDT) i artiklen Netværksmulighed for datasæt med XMLA-slutpunktet.
Udrulning af en ny model
I standardkonfigurationen forsøger Visual Studio at behandle modellen som en del af udrulningen for at indlæse data i datasættet fra datakilderne. Som beskrevet i Udrul modelprojekter fra Visual Studio (SSDT) kan denne handling muligvis ikke udføres, fordi legitimationsoplysningerne for datakilden ikke kan angives som en del af udrulningen. Hvis legitimationsoplysningerne for datakilden ikke allerede er defineret for nogen af dine eksisterende datasæt, skal du i stedet angive legitimationsoplysningerne for datakilden i indstillingerne for datasættet ved hjælp af Power BI-brugergrænsefladen (Datasæt > Indstillinger > Legitimationsoplysninger for datakilde > Rediger legitimationsoplysninger). Når du har defineret legitimationsoplysningerne for datakilden, kan Power BI automatisk anvende legitimationsoplysningerne på denne datakilde for ethvert nyt datasæt, efter at udrulningen af metadata er fuldført, og datasættet er blevet oprettet.
Hvis Power BI ikke kan binde dit nye datasæt til legitimationsoplysningerne for datakilden, får du vist fejlmeddelelsen: "Databasen kan ikke behandles. Årsag: Ændringerne blev ikke gemt på serveren." med fejlkoden "DMTS_DatasourceHasNoCredentialError" som vist nedenfor:
Hvis du vil undgå behandlingsfejl, skal du angive Installationsindstillinger > Behandlingsmuligheder til Behandl ikke som vist på følgende billede. Visual Studio udruller derefter kun metadata. Du kan derefter konfigurere legitimationsoplysningerne for datakilden og klikke på Opdater nu for datasættet i Power BI-brugergrænsefladen.
Nyt projekt ud fra et eksisterende datasæt
Oprettelse af et nyt tabelprojekt i Visual Studio ved at importere metadataene fra et eksisterende datasæt understøttes ikke. Du kan dog oprette forbindelse til datasættet ved hjælp af SQL Server Management Studio, scripte metadataene og genbruge dem i andre tabellariske projekter.
Overførsel af et datasæt til Power BI
Det anbefales, at du angiver kompatibilitetsniveauet 1500 (eller højere) for tabellariske modeller. Dette kompatibilitetsniveau understøtter de fleste egenskaber og datakildetyper. Nyere kompatibilitetsniveauer er bagudkompatible med tidligere niveauer.
Understøttede dataprovidere
På kompatibilitetsniveauet 1500 understøtter Power BI følgende datakildetyper:
- Providerdatakilder (ældre med en forbindelsesstreng i modellens metadata).
- Strukturerede datakilder (introduceret med kompatibilitetsniveauet 1400).
- Indbyggede M-erklæringer om datakilder (som Power BI Desktop deklarerer dem).
Det anbefales, at du bruger strukturerede datakilder, som Visual Studio opretter som standard, når du gennemgår importdataflowet. Men hvis du planlægger at overføre en eksisterende model til Power BI, der bruger en providerdatakilde, skal du sørge for, at providerdatakilde er baseret på en understøttet dataprovider. Specifikt Microsoft OLE DB-driveren til SQL Server og alle ODBC-drivere fra tredjepart. Hvad angår OLE DB-driveren til SQL Server, skal du ændre datakildedefinitionen til .NET Framework-dataprovider til SQL Server. Hvad angår ODBC-drivere fra tredjepart, der muligvis er utilgængelige i Power BI-tjenesten, skal du i skifte til en struktureret datakildedefinition.
Det anbefales også, at du erstatter den forældede Microsoft OLE DB-driver til SQL Server (SQLNCLI11) i dine SQL Server-datakildedefinitioner med .NET Framework-dataprovideren til SQL Server.
Følgende tabel indeholder et eksempel på en forbindelsesstreng for .NET Framework-dataprovideren til SQL Server, der erstatter en tilsvarende forbindelsesstreng til OLE DB-driveren til SQL Server.
| OLE DB-driver til SQL Server | .Net Framework-dataprovider til SQL Server |
|---|---|
Provider=SQLNCLI11;Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW;Trusted_Connection=yes; |
Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW2016;Integrated Security=SSPI;Encrypt=true;TrustServerCertificate=false |
Krydsreferencer til partitionskilder
På samme måde som der er flere datakildetyper, er der også flere partitionskildetyper, som kan medtages i en tabellarisk model for at importere data i en tabel. En partition kan især bruge en forespørgselspartitions kilde eller en M-partitionskilde. Disse partitionskildetyper kan f. eks. henvise til providerdatakilder eller strukturerede datakilder. Selvom tabellariske modeller i Azure Analysis Services understøtter krydsreferencer til disse forskellige datakilder og partitionstyper gennemtvinger Power BI en strengere relation. Forespørgselspartitionskilder skal referere til providerdatakilder, og M-partitionskilder skal referere til strukturerede datakilder. Ander kombinationer understøttes ikke i Power BI. Hvis du vil overføre et dataset med krydsreferencer, beskrives de understøttede konfigurationer i følgende tabel:
| Datakilde | Partitionskilde | Kommentarer | Understøttes med XMLA-slutpunkt |
|---|---|---|---|
| Providerdatakilde | Forespørgselspartitionskilde | AS-programmet bruger den cartridgebaserede forbindelsesstak til at oprette adgang til datakilden. | Ja |
| Providerdatakilde | M-partitionskilde | AS-programmet oversætter providerdatakilden til en generisk struktureret datakilde og bruger derefter miksprogrammet til at importere dataene. | Nej |
| Struktureret datakilde | Forespørgselspartitionskilde | AS-programmet ombryder den oprindelige forespørgsel i partitionskilden til et M-udtryk og bruger derefter miksprogrammet til at importere dataene. | Nej |
| Struktureret datakilde | M-partitionskilde | AS-programmet bruger miksprogrammet til at importere dataene. | Ja |
Datakilder og repræsentation
Repræsentationsindstillinger, du kan definere for providerdatakilder, er ikke relevante for Power BI. I Power BI bruges der en anden mekanisme, der er baseret på datasætindstillinger, til administration af legitimationsoplysningerne for datakilden. Derfor skal du sikre dig, at du vælger Tjenestekonto, hvis du opretter en providerdatakilde.
Detaljeret behandling
Når der udløses en planlagt opdatering eller en opdatering efter behov i Power BI, opdateres hele datasættet normalt i Power BI. I mange tilfælde er det mere effektivt at udføre opdateringer mere selektivt. Du kan udføre detaljerede behandlingsopgaver i SQL Server Management Studio (SSMS) som vist nedenfor eller ved hjælp af værktøjer eller scripts fra tredjepart.
Tilsidesættelser i TMSL-kommandoen Opdater
Tilsidesættelser i kommandoen Opdater (TMSL) giver brugere mulighed for at vælge en anden definition af partitionsforespørgsel eller en anden definition af datakilde for opdateringshandlingen.
Fejl i SQL Server Management Studio – Premium Gen 2
Udførelse af forespørgsler
Når der er oprettet forbindelse til et arbejdsområde i Premium Gen2 eller en Embedded Gen2-kapacitet, SQL Server Management Studio følgende fejl:
Executing the query ...
Error -1052311437: We had to move the session with ID '<Session ID>' to another Power BI Premium node. Moving the session temporarily interrupted this trace - tracing will resume automatically as soon as the session has been fully moved to the new node.
Dette er en meddelelse til orientering, som kan ignoreres i SSMS 18.8 og nyere, fordi klientbibliotekerne automatisk opretter forbindelse igen. Bemærk, at klientbiblioteker, der er installeret sammen med SSMS v18.7.1 eller lavere, ikke understøtter sporing af sessioner. Download det nyeste SSMS.
Opdateringshandlinger
Når du bruger SSMS v18.7.1 eller lavere til at udføre en langvarig opdateringshandling (>1 min.) på et datasæt i en Premium Gen2- eller en Embedded Gen2-kapacitet, vises der muligvis en fejl som følgende, selvom opdateringshandlingen lykkes:
Executing the query ...
Error -1052311437:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId: 3716c0f7-3d01-4595-8061-e6b2bd9f3428
Date (UTC): 11/13/2020 7:57:16 PM
Run complete
Dette skyldes et kendt problem i de klientbiblioteker, hvor statussen for opdateringsanmodningen er sporet forkert. Dette er løst i SSMS 18.8 og nyere. Download det nyeste SSMS.
Forbind på serverfejl i SSMS
Når du opretter forbindelse til Power BI arbejdsområde med SQL Server Management Studio (SSMS), kan følgende fejl vises:
TITLE: Connect to Server
------------------------------
Cannot connect to powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
------------------------------
ADDITIONAL INFORMATION:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId:
Date (UTC): 10/6/2021 1:03:25 AM (Microsoft.AnalysisServices.AdomdClient)
------------------------------
The remote server returned an error: (400) Bad Request. (System)
Når du opretter forbindelse til Power BI arbejdsområde med SSMS, skal du sørge for følgende:
- Indstillingen for XMLA-slutpunktet er aktiveret for din lejers kapacitet. Du kan få mere at vide under Aktivér læse-/skrive-adgang til XMLA.
- Indstillingen Tillad XMLA-slutpunkter og Analysér i et Excel datasæt i det lokale miljø er aktiveret under Lejerindstillinger.
- Du bruger den nyeste version af SSMS. Download den nyeste.
Redigering af rollemedlemskaber i SSMS
Når du bruger SSMS (SQL Server Management Studio) version 18.8 til at redigere et rollemedlemskab for et datasæt, kan SSMS vise følgende fejl:
Failed to save modifications to the server.
Error returned: ‘Metadata change of current operation cannot be resolved, please check the command or try again later.’
Det skyldes et kendt problem i apptjenesternes REST API. Problemet løses i en kommende version. Du løser denne fejl ved at indtaste og udføre følgende TMSL-kommando ved at klikke på Script i Rolleegenskaber:
{
"createOrReplace": {
"object": {
"database": "AdventureWorks",
"role": "Role"
},
"role": {
"name": "Role",
"modelPermission": "read",
"members": [
{
"memberName": "xxxx",
"identityProvider": "AzureAD"
},
{
"memberName": “xxxx”
"identityProvider": "AzureAD"
}
]
}
}
}
Publicer fejl – datasæt med direkte forbindelse
Når du genudgiver et datasæt med direkte forbindelse ved hjælp af Analysis Services Connector, kan følgende fejl blive vist:
Som angivet i fejlmeddelelsen kan du løse problemet ved enten at slette eller omdøbe det eksisterende datasæt. Sørg også for at publicere alle de apps, der er afhængige af rapporten, igen. Hvis det er nødvendigt, skal brugerne også have besked om at opdatere bogmærker med den nye rapportadresse for at sikre, at de har adgang til den nyeste rapport.
Alias for arbejdsområde/server
I Azure Analysis Services understøttes aliasser for servernavne ikke for Premium arbejdsområder.
DISCOVER_M_EXPRESSIONS
DMV'DISCOVER_M_EXPRESSIONS understøttes ikke i øjeblikket i forbindelse med brug Power BI XMLA-slutpunktet. Programmer kan bruge TOM (Tabular Object Model) til at hente M-udtryk, der bruges af datamodellen.
Ressource, der styrer kommandoens hukommelsesgrænse i Premium Gen 2
Premium Gen2-kapaciteter bruger ressourcestyring til at sikre, at ingen handling for et enkelt datasæt overstiger mængden af tilgængelige hukommelsesressourcer for kapaciteten – bestemmes af SKU. Et P1-abonnement har f.eks. en effektiv hukommelsesgrænse pr. artefakt på 25 GB. For et P2-abonnement er grænsen 50 GB, og for et P3-abonnement er grænsen 100 GB. Ud over størrelsen på datasæt (database) gælder den effektive hukommelsesgrænse også for underliggende kommandohandlinger for datasæt, f.eks. Opret, Tilpasog Opdater.
Den effektive hukommelsesgrænse for en kommando er baseret på mindre af kapacitetens hukommelsesgrænse (bestemmes af SKU'en) eller værdien af egenskaben DbpropMsmdRequestMemoryLimit XMLA.
For en P1-kapacitet gælder f.eks., hvis:
DbpropMsmdRequestMemoryLimit = 0 (eller ikke angivet), er den effektive hukommelsesgrænse for kommandoen 25 GB.
DbpropMsmdRequestMemoryLimit = 5 GB, den effektive hukommelsesgrænse for kommandoen er 5 GB.
DbpropMsmdRequestMemoryLimit = 50 GB, den effektive hukommelsesgrænse for kommandoen er 25 GB.
Den effektive hukommelsesgrænse for en kommando beregnes typisk i den hukommelse, der er tilladt for datasættet af kapaciteten (25 GB, 50 GB, 100 GB), og hvor meget hukommelse datasættet allerede bruger, når kommandoen starter udførelsen. Et datasæt med 12 GB på en P1-kapacitet giver f.eks. en effektiv hukommelsesgrænse for en ny kommando på 13 GB. Den effektive hukommelsesgrænse kan dog begrænses yderligere af egenskaben DbPropMsmdRequestMemoryLimit XMLA, når et program eventuelt har angivet det. Hvis der i det forrige eksempel er angivet 10 GB i egenskaben DbPropMsmdRequestMemoryLimit, så reduceres kommandoens effektive grænse yderligere til 10 GB.
Hvis kommandohandlingen forsøger at forbruge mere hukommelse, end der er tilladt af grænsen, kan handlingen mislykkes, og der returneres en fejl. Følgende fejl beskriver f.eks. en effektiv hukommelsesgrænse på 25 GB (P1-kapacitet) er blevet overskredet, fordi datasættet allerede har brugt 12 GB (12288 MB), når kommandoen startede udførelsen, og der blev anvendt en effektiv grænse på 13 GB (13312 MB) for kommandohandlingen:
"Ressourcestyring: Denne handling blev annulleret, fordi der ikke var tilstrækkelig hukommelse til at køre den. Du kan øge hukommelsen i den Premium kapacitet, hvor dette datasæt hostes, eller reducere hukommelsesfodaftrykket for dit datasæt ved at gøre ting som at begrænse mængden af importerede data. Flere detaljer: Forbrugt hukommelse 13312 MB, hukommelsesgrænse 13312 MB, databasestørrelse før kommandoudførelse 12288 MB. Få mere at vide: https://go.microsoft.com/fwlink/?linkid=2159753 ."
I nogle tilfælde, som vist i følgende fejl, er "forbrugt hukommelse" 0, men det antal, der vises for "databasestørrelse før udførelse af kommandoer", er allerede større end den effektive hukommelsesgrænse. Det betyder, at handlingen ikke kunne udføres, fordi mængden af hukommelse, der allerede bruges af datasættet, er større end hukommelsesgrænsen for SKU'en.
"Ressourcestyring: Denne handling blev annulleret, fordi der ikke var tilstrækkelig hukommelse til at køre den. Du kan enten øge hukommelsen i den Premium kapacitet, hvor dette datasæt hostes, eller reducere hukommelsesfodaftrykket for dit datasæt ved at gøre ting som at begrænse mængden af importerede data. Flere oplysninger: Forbrugt hukommelse 0 MB, hukommelsesgrænse 25600 MB, databasestørrelse før kommandoudførelse 26000 MB. Få mere at vide: https://go.microsoft.com/fwlink/?linkid=2159753 ."
Sådan kan du potentielt reducere grænsen for den effektive hukommelsesgrænse:
- Opgrader til en Premium kapacitet (SKU) for datasættet.
- Reducer hukommelsesfodaftrykket for dit datasæt ved at begrænse mængden af data, der indlæses ved hver opdatering.
- Ved opdateringshandlinger via XMLA-slutpunktet skal du reducere antallet af partitioner, der behandles parallelt. For mange partitioner, der behandles parallelt med en enkelt kommando, kan overskride den effektive hukommelsesgrænse.
Se også
Netværksmuligheder for datasæt med XMLA-slutpunktet
Automatiser opgaver for arbejdsområder og datasæt i Premium med tjenesteprincipaler
Fejlfinding af Analysér i Excel
Udrulning af løsning med tabellarisk model