Feilsøk XMLA-endepunkttilkobling
XMLA-endepunkter i Power BI er avhengige av den opprinnelige kommunikasjonsprotokollen for Analysis Services for tilgang til Semantiske Modeller for Power BI. På grunn av dette er feilsøking av XMLA-endepunkt omtrent det samme som feilsøking av en vanlig Analysis Services-tilkobling. Noen forskjeller rundt Power BI-spesifikke avhengigheter gjelder imidlertid.
Før du starter
Før du feilsøker et XMLA-endepunktscenario, må du passe på å se gjennom det grunnleggende som dekkes av semantisk modelltilkobling med XMLA-endepunktet. De vanligste brukstilfellene for XMLA-endepunkt dekkes der. Andre feilsøkingsveiledninger for Power BI, for eksempel Feilsøking av gatewayer – Power BI og Feilsøkingsanalyse i Excel, kan også være nyttige.
Aktivere XMLA-endepunktet
XMLA-endepunktet kan aktiveres på både Power BI Premium-, Premium per bruker- og Power BI Embedded-kapasiteter. På mindre kapasiteter, for eksempel en A1-kapasitet med bare 2,5 GB minne, kan det oppstå en feil i kapasitetsinnstillingene når du prøver å angi XMLA-endepunktet til Lese/skrive og deretter velge Bruk. Feilen sier «Det oppstod et problem med arbeidsbelastningsinnstillingene. Prøv på nytt om en liten stund.".
Her er et par ting du kan prøve:
- Begrens minneforbruket for andre tjenester på kapasiteten, for eksempel dataflyter, til 40 % eller mindre, eller deaktiver en unødvendig tjeneste fullstendig.
- Oppgrader kapasiteten til en større SKU. Hvis du for eksempel oppgraderer fra en A1 til en A3-kapasitet, løses dette konfigurasjonsproblemet uten å måtte deaktivere dataflyter.
Husk at du også må aktivere innstillingen eksportdata på leiernivå i administrasjonsportalen for Power BI. Denne innstillingen kreves også for funksjonen Analyser i Excel.
Opprette en klienttilkobling
Når du har aktivert XMLA-endepunktet, er det lurt å teste tilkoblingen til et arbeidsområde på kapasiteten. Hvis du vil ha mer informasjon, kan du se Koble til et Premium-arbeidsområde. Pass også på å lese delen Tilkoblingskrav for nyttige tips og informasjon om gjeldende begrensninger for XMLA-tilkobling.
Koble til en tjenestekontohaver
Hvis du har aktivert leierinnstillinger for å tillate tjenestekontohavere å bruke Power BI-API, som beskrevet i Aktiver tjenestekontohavere, kan du koble til et XMLA-endepunkt ved hjelp av en tjenestekontohaver. Husk at tjenestekontohaveren krever samme tilgangsnivå på arbeidsområde- eller semantisk modellnivå som vanlige brukere.
Hvis du vil bruke en tjenestekontohaver, må du angi programidentitetsinformasjonen i tilkoblingsstreng som:
Bruker-ID-app - :appid@tenantid
Passord
sertifikat:avtrykk (anbefales for sikkerhet)
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;programhemmelighet
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;
Hvis du får følgende feil:
"Vi kan ikke koble til den semantiske modellen på grunn av ufullstendig kontoinformasjon. For tjenestekontohavere må du sørge for at du angir leier-ID-en sammen med app-ID-en ved hjelp av formatappen:<appId>@<tenantId>, og prøv deretter på nytt.»
Kontroller at du angir leier-ID-en sammen med app-ID-en ved hjelp av riktig format.
Det er også gyldig å angi app-ID-en uten leier-ID-en. I dette tilfellet må du imidlertid erstatte aliaset myorg i nettadressen for datakilden med den faktiske leier-ID-en. Power BI kan deretter finne tjenestekontohaveren i riktig leier. Men som anbefalt fremgangsmåte kan du bruke aliaset myorg og angi leier-ID-en sammen med app-ID-en i bruker-ID-parameteren.
Koble til Microsoft Entra B2B
Med støtte for Microsoft Entra business-to-business (B2B) i Power BI kan du gi eksterne gjestebrukere tilgang til semantiske modeller over XMLA-endepunktet. Kontroller at innstillingen Del innhold med eksterne brukere er aktivert i administrasjonsportalen for Power BI. Hvis du vil ha mer informasjon, kan du se Distribuere Power BI-innhold til eksterne gjestebrukere med Microsoft Entra B2B.
Distribuere en semantisk modell
Du kan distribuere et tabellmodellprosjekt i Visual Studio (SSDT) til et arbeidsområde som er tilordnet en Premium-kapasitet, omtrent det samme som til en serverressurs i Azure Analysis Services. Når du distribuerer, er det imidlertid noen ekstra hensyn. Pass på å se gjennom delen Distribuer modellprosjekter fra Visual Studio (SSDT) i semantisk modelltilkobling med XMLA-endepunktartikkelen.
Distribuere en ny modell
I standardkonfigurasjonen forsøker Visual Studio å behandle modellen som en del av distribusjonsoperasjonen for å laste inn data i den semantiske modellen fra datakildene. Som beskrevet i Distribuer modellprosjekter fra Visual Studio (SSDT) kan denne operasjonen mislykkes fordi legitimasjon for datakilder ikke kan angis som en del av distribusjonsoperasjonen. Hvis legitimasjonen for datakilden ikke allerede er definert for noen av de eksisterende semantiske modellene, må du i stedet angi legitimasjonen for datakilden i innstillingene for semantisk modell ved hjelp av brukergrensesnittet for Power BI (semantiske modeller>Innstillinger>datakildelegitimasjon>Rediger legitimasjon). Etter å ha definert legitimasjonen for datakilden, kan Power BI deretter bruke legitimasjonen på denne datakilden automatisk for en ny semantisk modell, etter at metadatadistribusjonen er fullført og den semantiske modellen er opprettet.
Hvis Power BI ikke kan binde den nye semantiske modellen til datakildelegitimasjon, får du en feilmelding om at «Kan ikke behandle databasen. Årsak: Kan ikke lagre endringer på serveren. Med feilkoden «DMTS_DatasourceHasNoCredentialError», som vist nedenfor:
Hvis du vil unngå behandlingsfeilen, angir du behandlingsalternativene for distribusjonsalternativer>til Do not Process, som vist i illustrasjonen nedenfor. Visual Studio distribuerer deretter bare metadata. Deretter kan du konfigurere legitimasjonen for datakilden og klikke oppdater nå for semantisk modell i Power BI-brukergrensesnittet.
Nytt prosjekt fra en eksisterende semantisk modell
Oppretting av et nytt tabellprosjekt i Visual Studio ved å importere metadata fra en eksisterende semantisk modell støttes ikke. Du kan imidlertid koble til den semantiske modellen ved hjelp av SQL Server Management Studio, skripte ut metadataene og bruke den på nytt i andre tabellprosjekter.
Overføre en semantisk modell til Power BI
Det anbefales at du angir kompatibilitetsnivået 1500 (eller høyere) for tabellmodeller. Dette kompatibilitetsnivået støtter de fleste funksjonene og datakildetypene. Senere kompatibilitetsnivåer er bakoverkompatible med tidligere nivåer.
Støttede dataleverandører
På kompatibilitetsnivå 1500 støtter Power BI følgende datakildetyper:
- Leverandørdatakilder (eldre med en tilkoblingsstreng i modellmetadataene).
- Strukturerte datakilder (introdusert med kompatibilitetsnivået 1400).
- Innebygde M-deklarasjoner for datakilder (som Power BI Desktop erklærer dem).
Det anbefales at du bruker strukturerte datakilder, som Visual Studio oppretter som standard når du går gjennom importdataflyten. Hvis du imidlertid planlegger å overføre en eksisterende modell til Power BI som bruker en leverandørdatakilde, må du kontrollere at leverandørdatakilden er avhengig av en støttet dataleverandør. Spesielt Microsoft OLE DB-driveren for SQL Server og eventuelle tredjeparts ODBC-drivere. For OLE DB-driver for SQL Server må du bytte datakildedefinisjonen til .NET Framework-dataleverandøren for SQL Server. For tredjeparts ODBC-drivere som kan være utilgjengelige i Power Bi-tjeneste, må du bytte til en strukturert datakildedefinisjon i stedet.
Det anbefales også at du erstatter den utdaterte Microsoft OLE DB-driveren for SQL Server (SQLNCLI11) i SQL Server-datakildedefinisjonene med .NET Framework-dataleverandøren for SQL Server.
Tabellen nedenfor inneholder et eksempel på en .NET Framework-dataleverandør for SQL Server tilkoblingsstreng erstatte en tilsvarende tilkoblingsstreng for OLE DB-driveren for SQL Server.
| OLE DB-driver for SQL Server | .NET Framework-dataleverandør for 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 |
Kryssrefererende partisjonskilder
Akkurat som det finnes flere datakildetyper, finnes det også flere partisjonskildetyper som en tabellmodell kan inkludere for å importere data til en tabell. Spesielt kan en partisjon bruke en spørringspartisjonskilde eller en M-partisjonskilde. Disse partisjonskildetypene kan i sin tur referere til leverandørdatakilder eller strukturerte datakilder. Mens tabellmodeller i Azure Analysis Services støtter kryssreferering av disse ulike datakilde- og partisjonstypene, håndhever Power BI en strengere relasjon. Spørringspartisjonskilder må referere til leverandørdatakilder, og M-partisjonskilder må referere til strukturerte datakilder. Andre kombinasjoner støttes ikke i Power BI. Hvis du vil overføre en semantisk modell med kryssreferanser, beskriver tabellen nedenfor støttede konfigurasjoner:
| Datakilde | Partisjonskilde | Kommentarer | Støttes med XMLA-endepunkt |
|---|---|---|---|
| Leverandørdatakilde | Spørringspartisjonskilde | AS-motoren bruker den patronbaserte tilkoblingsstakken til å få tilgang til datakilden. | Ja |
| Leverandørdatakilde | M-partisjonskilde | AS-motoren oversetter leverandørdatakilden til en generisk strukturert datakilde og bruker deretter Mashup-motoren til å importere dataene. | No |
| Strukturert datakilde | Spørringspartisjonskilde | AS-motoren pakker den opprinnelige spørringen på partisjonskilden inn i et M-uttrykk og bruker deretter Mashup-motoren til å importere dataene. | No |
| Strukturert datakilde | M-partisjonskilde | AS-motoren bruker Mashup-motoren til å importere dataene. | Ja |
Datakilder og representasjon
Representasjonsinnstillinger du kan definere for leverandørdatakilder, er ikke relevante for Power BI. Power BI bruker en annen mekanisme basert på semantiske modellinnstillinger for å administrere legitimasjon for datakilder. Av denne grunn må du kontrollere at du velger Tjenestekonto hvis du oppretter en leverandørdatakilde.
Finkornet behandling
Når du utløser en planlagt oppdatering eller behovsbetinget oppdatering i Power BI, oppdaterer Power BI vanligvis hele semantiske modellen. I mange tilfeller er det mer effektivt å utføre oppdateringer mer selektivt. Du kan utføre finjusterte behandlingsoppgaver i SQL Server Management Studio (SSMS) som vist nedenfor, eller ved hjelp av tredjepartsverktøy eller skript.
Overstyrer kommandoen Oppdater TMSL
Overstyringer i Oppdater-kommandoen (TMSL) gjør det mulig for brukere å velge en annen partisjonsspørringsdefinisjon eller datakildedefinisjon for oppdateringsoperasjonen.
E-postabonnementer
Semantiske modeller som oppdateres ved hjelp av et XMLA-endepunkt, utløser ikke et e-postabonnement.
Feil på Premium-kapasitet
Koble til serverfeil i SSMS
Når du kobler til et Power BI-arbeidsområde med SQL Server Management Studio (SSMS), kan følgende feil 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 kobler til et Power BI-arbeidsområde med SSMS, må du kontrollere følgende:
- Innstillingen for XMLA-endepunkt er aktivert for leierens kapasitet. Hvis du vil ha mer informasjon, kan du se Aktiver skrivetilgang for XMLA.
- Innstillingen Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller er aktivert i leierinnstillinger.
- Du bruker den nyeste versjonen av SSMS. Last ned det nyeste.
Kjøring av spørring i SSMS
Når du er koblet til et arbeidsområde i en Power BI Premium - eller Power BI Embedded-kapasitet , kan SQL Server Management Studio vise følgende feil:
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 informasjonsmelding som kan ignoreres i SSMS 18.8 og nyere fordi klientbibliotekene kobles til på nytt automatisk. Vær oppmerksom på at klientbiblioteker som er installert med SSMS v18.7.1 eller lavere, ikke støtter øktsporing. Last ned den nyeste SSMS.
Kjøre en stor kommando ved hjelp av XMLA-endepunktet
Når du kjører en stor kommando ved hjelp av XMLA-endepunktet, kan det oppstå følgende feil:
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
Når du bruker SSMS v18.7.1 eller lavere til å utføre en langvarig (>1 min) oppdateringsoperasjon på en semantisk modell i en Power BI Premium- eller Power BI Embedded-kapasitet , kan SSMS vise denne feilen selv om oppdateringsoperasjonen lykkes. Dette skyldes et kjent problem i klientbibliotekene der statusen for oppdateringsforespørselen spores feil. Dette løses i SSMS 18.8 og nyere. Last ned den nyeste SSMS.
Denne feilen kan også oppstå når en svært stor forespørsel må omdirigeres til en annen node i Premium-klyngen. Det vises ofte når du prøver å opprette eller endre en semantisk modell ved hjelp av et stort TMSL-skript. I slike tilfeller kan feilen vanligvis unngås ved å angi den opprinnelige katalogen til navnet på databasen før du kjører kommandoen.
Når du oppretter en ny database, kan du for eksempel opprette en tom semantisk modell:
{
"create": {
"database": {
"name": "DatabaseName"
}
}
}
Når du har opprettet den nye semantiske modellen, angir du den første katalogen og gjør deretter endringer i den semantiske modellen.
Andre klientprogrammer og -verktøy
Klientprogrammer og verktøy som Excel, Power BI Desktop, SSMS eller eksterne verktøy som kobler til og arbeider med semantiske modeller i Power BI Premium-kapasiteter, kan forårsake følgende feil: Den eksterne serveren returnerte en feil: (400) Ugyldig forespørsel.. Feilen kan forårsakes spesielt hvis en underliggende DAX-spørring eller XMLA-kommando kjører lenge. Hvis du vil redusere potensielle feil, må du passe på å bruke de nyeste programmene og verktøyene som installerer nylige versjoner av Analysis Services-klientbibliotekene med regelmessige oppdateringer. Uavhengig av program eller verktøy, er minimum nødvendige klientbibliotekversjoner for å koble til og arbeide med semantiske modeller i en Premium-kapasitet gjennom XMLA-endepunktet:
| Klientbibliotek | Versjon |
|---|---|
| MSOLAP | 15.1.65.22 |
| AMO | 19.12.7.0 |
| ADOMD | 19.12.7.0 |
Redigere rollemedlemskap i SSMS
Når du bruker SQL Server Management Studio (SSMS) v18.8 til å redigere et rollemedlemskap på en semantisk modell, kan SSMS vise følgende feil:
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.’
Dette skyldes et kjent problem i REST-API-en for apptjenestene. Dette vil bli løst i en kommende utgivelse. I mellomtiden klikker du Skript i rolleegenskaper for å finne denne feilen, og deretter skriver du inn og utfører følgende TMSL-kommando:
{
"createOrReplace": {
"object": {
"database": "AdventureWorks",
"role": "Role"
},
"role": {
"name": "Role",
"modelPermission": "read",
"members": [
{
"memberName": "xxxx",
"identityProvider": "AzureAD"
},
{
"memberName": “xxxx”
"identityProvider": "AzureAD"
}
]
}
}
}
Publiser feil – direkte tilkoblet semantisk modell
Når du publiserer en live-tilkoblet semantisk modell på nytt ved hjelp av Analysis Services-koblingen, er følgende feil: «Det finnes en eksisterende rapport-/semantisk modell med samme navn. Slett eller gi nytt navn til den eksisterende semantiske modellen, og prøv på nytt." kan vises.
Dette skyldes at den semantiske modellen publiseres med en annen tilkoblingsstreng men har samme navn som den eksisterende semantiske modellen. Hvis du vil løse dette problemet, kan du enten slette eller gi nytt navn til den eksisterende semantiske modellen. Pass også på å publisere alle apper som er avhengige av rapporten på nytt. Hvis det er nødvendig, bør nedstrømsbrukere informeres om å oppdatere eventuelle bokmerker med den nye rapportadressen for å sikre at de får tilgang til den nyeste rapporten.
Direkte tilkoblet semantisk modell kan ikke lastes inn
Brukere som prøver å opprette en ny Live Connected-modell eller åpner en eksisterende Live Connected-modell, ved hjelp av mars 2024 eller senere versjoner av Power BI Desktop, kan støte på en feil som ligner på følgende: «Vi kunne ikke koble til modellen i Power Bi-tjeneste. Datasettet kan ha blitt slettet, fått nytt navn, flyttet, eller det er mulig at du ikke har tillatelse til å få tilgang til det."
Feilen kan oppstå når en proxy er konfigurert i brukerens miljø, og proxyen hindrer tilgang til Power Bi-tjeneste. Fra og med mars 2024-versjonen av Power BI Desktop må brukerens miljø tillate tilkoblinger til Power Bi-tjeneste på endepunktet *.pbidedicated.windows.net eller tilsvarende Power Bi-tjeneste endepunkter for nasjonale skyer.
Hvis du vil validere om problemet er et resultat av proxy-innstillinger, kan du prøve SQL Server Analysis Services-koblingen i Power BI Desktop eller et hvilket som helst førsteparts- eller tredjeparts eksternt verktøy, for eksempel SQL Server Management Studio, for å koble til et premium-arbeidsområde.
Se delen om oppretting av en klienttilkobling i denne artikkelen for mer informasjon om testing av generell XML/A-tilkobling.
Excel-arbeidsboken kan ikke åpnes
Excel-arbeidsboken kan ikke åpnes med feilmeldingen Initialisering av datakilden mislyktes. Kontroller databaseserveren, eller kontakt databaseadministratoren.". Hvis arbeidsboken inneholder en tilkobling til en semantisk Power BI-modell, kontrollerer du om tilkoblingsstreng inneholder egenskapen Catalog Rebound=True. Hvis egenskapen blir funnet, fjerner du den, lagrer arbeidsboken og prøver å åpne den på nytt.
Egenskapen Catalog Rebound=True legges automatisk til av Analysis Services OLE DB Provider (MSOLAP) i nyere versjoner av Excel når tilkoblingen til Semantisk Power BI-modell optimaliseres av leverandøren. Fordi egenskapen beholdes i arbeidsboken når den samme arbeidsboken åpnes i Excel som bruker en eldre versjon av leverandøren som ikke støtter optimaliseringen, vil Ikke Excel åpne arbeidsboken.
Katalogretur er bare ment for intern bruk.
Arbeidsområde-/serveralias
I motsetning til Azure Analysis Services støttes ikke servernavnaliaser for Premium-arbeidsområder.
DISCOVER_M_EXPRESSIONS
DMV-DISCOVER_M_EXPRESSIONS databehandlingsvisning (DMV) støttes for øyeblikket ikke i Power BI ved hjelp av XMLA-endepunktet. Programmer kan bruke tabellobjektmodellen (TOM) til å hente M-uttrykk som brukes av datamodellen.
Minnegrense for ressursstyrende kommando i Premium
Premium-kapasiteter bruker ressursstyrende for å sikre at ingen enkelt semantisk modelloperasjon kan overskride mengden tilgjengelige minneressurser for kapasiteten – bestemt av SKU. Et P1-abonnement har for eksempel en effektiv minnegrense per element på 25 GB, for et P2-abonnement er grensen 50 GB, og for et P3-abonnement er grensen 100 GB. I tillegg til semantisk modellstørrelse (database) gjelder også den effektive minnegrensen for underliggende semantiske modellkommandooperasjoner som Opprett, Endre og Oppdater.
Den effektive minnegrensen for en kommando er basert på den minste av kapasitetens minnegrense (bestemt av SKU) eller verdien for DbpropMsmdRequestMemoryLimit XMLA-egenskapen.
For eksempel for en P1-kapasitet, hvis:
DbpropMsmdRequestMemoryLimit = 0 (eller uspesifisert), den effektive minnegrensen for kommandoen er 25 GB.
DbpropMsmdRequestMemoryLimit = 5 GB, den effektive minnegrensen for kommandoen er 5 GB.
DbpropMsmdRequestMemoryLimit = 50 GB, den effektive minnegrensen for kommandoen er 25 GB.
Vanligvis beregnes den effektive minnegrensen for en kommando på minnet som tillates for semantisk modell av kapasiteten (25 GB, 50 GB, 100 GB) og hvor mye minne den semantiske modellen allerede bruker når kommandoen starter kjøringen. En semantisk modell som bruker 12 GB på en P1-kapasitet, gir for eksempel en effektiv minnegrense for en ny kommando på 13 GB. Den effektive minnegrensen kan imidlertid begrenses ytterligere av DbPropMsmdRequestMemoryLimit XMLA-egenskapen når det er valgfritt angitt av et program. Hvis det forrige eksemplet er angitt i DbPropMsmdRequestMemoryLimit-egenskapen, reduseres den effektive grensen for kommandoen ytterligere til 10 GB.
Hvis kommandooperasjonen prøver å bruke mer minne enn tillatt av grensen, kan operasjonen mislykkes, og en feil returneres. Følgende feil beskriver for eksempel at en effektiv minnegrense på 25 GB (P1-kapasitet) er overskredet fordi den semantiske modellen allerede brukte 12 GB (12288 MB) da kommandoen startet kjøring, og en effektiv grense på 13 GB (13312 MB) ble brukt for kommandooperasjonen:
"Ressursstyrende: Denne operasjonen ble avbrutt fordi det ikke var nok minne til å fullføre kjøringen. Øk minnet til Premium-kapasiteten der denne semantiske modellen driftes, eller reduser minneavtrykket til den semantiske modellen ved å gjøre ting som å begrense mengden importerte data. Flere detaljer: forbrukt minne 13312 MB, minnegrense 13312 MB, databasestørrelse før kommandokjøring 12288 MB. Mer informasjon: https://go.microsoft.com/fwlink/?linkid=2159753."
I noen tilfeller, som vist i følgende feil, er «brukt minne» 0, men mengden som vises for «databasestørrelse før kjøring av kommando» allerede er større enn den effektive minnegrensen. Dette betyr at operasjonen ikke startet kjøring fordi mengden minne som allerede brukes av den semantiske modellen, er større enn minnegrensen for SKU-en.
"Ressursstyrende: Denne operasjonen ble avbrutt fordi det ikke var nok minne til å fullføre kjøringen. Øk minnet til Premium-kapasiteten der denne semantiske modellen driftes, eller reduser minneavtrykket til den semantiske modellen ved å gjøre ting som å begrense mengden importerte data. Flere detaljer: forbrukt minne 0 MB, minnegrense 25600 MB, databasestørrelse før kommandokjøring 26000 MB. Mer informasjon: https://go.microsoft.com/fwlink/?linkid=2159753."
Slik unngår du potensielt å overskride den effektive minnegrensen:
- Oppgrader til en større Premium-kapasitetsstørrelse (SKU) for semantisk modell.
- Reduser minneavtrykket til den semantiske modellen ved å begrense mengden data som lastes inn med hver oppdatering.
- For oppdateringsoperasjoner gjennom XMLA-endepunktet reduserer du antall partisjoner som behandles parallelt. For mange partisjoner som behandles parallelt med én enkelt kommando, kan overskride den effektive minnegrensen.