Problemen met connectiviteit van XMLA-eindpunten oplossen

XMLA-eindpunten in Power BI zijn afhankelijk van het Analysis Services communicatieprotocol voor toegang tot Power BI gegevenssets. Daarom is het oplossen van een probleem met een XMLA-eindpunt vrijwel hetzelfde als het oplossen van probleem met een typische Analysis Services-verbinding. Er zijn echter enkele verschillen rond Power BI-specifieke afhankelijkheden van toepassing.

Voordat u begint

Voordat u een probleem met een XMLA-eindpunt oplost, moet u de basisbeginselen in Gegevenssetverbinding met het XMLA-eindpunt lezen. De meestvoorkomende use-cases voor het XMLA-eindpunt worden daarin besproken. Andere Power BI-gidsen voor probleemoplossing, zoals Problemen met gateways oplossen - Power BI en Problemen met Analyseren in Excel oplossen, kunnen ook handig zijn.

Het XMLA-eindpunt inschakelen

Het XMLA-eindpunt kan worden ingeschakeld op Power BI Premium, Premium per gebruiker en Power BI Embedded capaciteit. Op kleinere capaciteiten, zoals een A1-capaciteit met slechts 2,5 GB geheugen, kan er een fout optreden in capaciteitsinstellingen wanneer u het XMLA-eindpunt instelt op Lezen/schrijven en vervolgens Toepassen selecteert. U krijgt de foutmelding 'Er is een probleem met uw workloadinstellingen. Probeer het over enkele minuten opnieuw.'

U kunt de volgende dingen proberen:

• Beperk het geheugengebruik van andere services op de capaciteit, zoals Gegevensstromen, tot 40% of minder, of schakel onnodige services volledig uit.
• Voer een upgrade van de capaciteit uit naar een grotere SKU. Als u bijvoorbeeld een upgrade van een A1-capaciteit naar een A3-capaciteit uitvoert, wordt dit configuratieprobleem opgelost zonder dat u Gegevensstromen hoeft uit te schakelen.

U moet ook de instelling Gegevens exporteren op tenantniveau inschakelen in de Power BI-beheerportal. Deze instelling is ook vereist voor de functie Analyseren in Excel.

Een clientverbinding tot stand brengen

Nadat het XMLA-eindpunt is ingeschakeld, is het een goed idee om de connectiviteit met een werkruimte op de capaciteit te testen. Zie Verbinding maken met een Premium-werkruimte voor meer informatie. Lees ook de sectie Verbindingsvereisten voor nuttige tips en informatie over actuele beperkingen voor XMLA-connectiviteit.

Aanmelden met een service-principal

Als u tenantinstellingen hebt ingeschakeld zodat service-principals Power BI-API's kunnen gebruiken, zoals beschreven in Service-principals inschakelen, kunt u verbinding maken met een XMLA-eindpunt met behulp van een service-principal. Bedenk dat voor de service-principal hetzelfde niveau van toegangsmachtigingen vereist is op het niveau van de werkruimte of gegevensset als voor normale gebruikers.

Als u een service-principal wilt gebruiken, moet u de toepassings-id-informatie in de verbindingsreeks opgeven als:

• User ID=<app:appid@tenantid>
• Password=<application secret>

Bijvoorbeeld:

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...;

Mogelijk wordt de volgende fout weergegeven:

'Er kan geen verbinding worden gemaakt met de gegevensset vanwege onvolledige accountgegevens. Voor service-principals moet u de tenant-id samen met de app-id opgeven met behulp van de indelings-app:<appId>@<tenantId>. Probeer het vervolgens opnieuw.'

Zorg ervoor dat u de tenant-id samen met de app-id opgeeft in de juiste indeling.

U mag ook de app-id opgeven zonder de tenant-id. In dat geval moet u wel de alias myorg in de gegevensbron-URL vervangen door de werkelijke tenant-id. Zo kan Power BI de service-principal vinden in de juiste tenant. Maar als best practice gebruikt u de alias myorg en geeft u de tenant-ID samen met de app-id op in de parameter voor de gebruikers-id.

Verbinding maken met Azure Active Directory B2B

Met ondersteuning voor Azure Active Directory (Azure AD) Business-to-Business (B2B) in Power BI kunt u externe gastgebruikers toegang bieden tot gegevenssets via het XMLA-eindpunt. Zorg ervoor dat de instelling Inhoud delen met externe gebruikers is ingeschakeld in de Power BI-beheerportal. Zie Power BI-inhoud met Azure AD B2B distribueren naar externe gastgebruikers voor meer informatie.

Een gegevensset implementeren

U kunt een tabellaire modelproject in Visual Studio (SSDT) implementeren in een werkruimte die is toegewezen aan een Premium-capaciteit, vrijwel hetzelfde als voor een serverresource in Azure Analysis Services. Bij de implementatie zijn er echter enkele aanvullende overwegingen. Raadpleeg de sectie Modelprojecten implementeren vanuit Visual Studio (SSDT) in het artikel Gegevenssetconnectiviteit met het XMLA-eindpunt.

Een nieuw model implementeren

In de standaardconfiguratie probeert Visual Studio het model te verwerken als onderdeel van de implementatiebewerking om gegevens in de gegevensset van de gegevensbronnen te laden. Zoals beschreven in Modelprojecten implementeren vanuit Visual Studio (SSDT), kan deze bewerking mislukken omdat de gegevensbronreferenties niet kunnen worden opgegeven als onderdeel van de implementatiebewerking. Als de referenties voor uw gegevensbron nog niet zijn gedefinieerd voor een van de bestaande gegevenssets, moet u de gegevensbronreferenties opgeven in de instellingen van de gegevensset met behulp van de Power BI gebruikersinterface (Gegevenssets > Instellingen > Referenties voor gegevensbron > Referenties bewerken). Als u de referenties voor de gegevensbron hebt gedefinieerd, kan Power BI deze automatisch toepassen op elke nieuwe gegevensset nadat de metagegevens zijn geïmplementeerd en de gegevensset is gemaakt.

Als Power BI uw nieuwe gegevensset niet aan de referenties van de gegevensbron kunt binden, ontvangt u het foutbericht 'De database kan niet worden verwerkt. Reden: Kan de aanpassingen niet op de server opslaan.' met de foutcode DMTS_DatasourceHasNoCredentialError, zoals hieronder wordt weergegeven:

Als u de verwerkingsfout wilt voorkomen, stelt u Implementatieopties > Verwerkingsopties in op Niet verwerken, zoals wordt weergegeven in de volgende afbeelding. In Visual Studio worden vervolgens alleen metagegevens geïmplementeerd. U kunt vervolgens de referenties voor de gegevensbron configureren en op Nu vernieuwen klikken voor de gegevensset in de Power BI-gebruikersinterface.

Nieuw project op basis van een bestaande gegevensset

Het maken van een nieuw tabellaire project in Visual Studio importeren van de metagegevens uit een bestaande gegevensset wordt niet ondersteund. U kunt echter verbinding maken met de gegevensset met behulp van SQL Server Management Studio, de metagegevens opnemen in een script en opnieuw gebruiken in andere tabellaire projecten.

Een gegevensset migreren naar Power BI

Het is raadzaam om het compatibiliteitsniveau 1500 (of hoger) voor tabellaire modellen op te geven. Dit compatibiliteitsniveau ondersteunt de meeste mogelijkheden en gegevensbrontypen. Latere compatibiliteitsniveaus zijn achterwaarts compatibel met eerdere niveaus.

Ondersteunde gegevensproviders

Op het compatibiliteitsniveau 1500 worden de volgende typen gegevensbronnen ondersteund in Power BI:

• Gegevensbronnen van providers (verouderd met een verbindingsreeks in de metagegevens van het model).
• Gestructureerde gegevensbronnen (geïntroduceerd met het compatibiliteitsniveau 1400).
• Inline M-declaraties van gegevensbronnen (zoals Power BI Desktop ze declareert).

Het is raadzaam om gestructureerde gegevensbronnen te gebruiken, die door Visual Studio standaard worden gemaakt bij het doorlopen van de gegevensstroom Importeren. Als u echter van plan bent om een bestaand model te migreren naar Power BI waarin gebruik wordt gemaakt van een gegevensbron van een provider, moet u ervoor zorgen dat het een gegevensbron van een ondersteunde gegevensprovider is. Bijvoorbeeld, het Microsoft OLE DB-stuurprogramma voor SQL Server en eventuele externe ODBC-stuurprogramma's. Voor het OLE DB-stuurprogramma voor SQL Server moet u de definitie van de gegevensbron overschakelen naar de .NET Framework-gegevensprovider voor SQL Server. Voor externe ODBC-stuurprogramma's die mogelijk niet beschikbaar zijn in de Power BI-service, moet u overschakelen naar een gestructureerde gegevensbrondefinitie.

U wordt ook aangeraden het verouderde Microsoft OLE DB-stuurprogramma voor SQL Server (SQLNCLI11) in uw SQL Server-gegevensbrondefinities te vervangen door de .NET Framework-gegevensprovider voor SQL Server.

De volgende tabel bevat een voorbeeld van verbindingsreeks voor een .NET Framework-gegevensprovider voor SQL Server ter vervanging van een verbindingsreeks voor het OLE DB-stuurprogramma voor SQL Server.

Kruislings verwijzen naar partitiebronnen

Net zoals er meerdere typen gegevensbronnen zijn, zijn er ook meerdere typen partitiebronnen die in een tabellair model kunnen worden opgenomen om gegevens te importeren in een tabel. Met name een partitie kan een querypartitiebron of een M-partitiebron gebruiken. Deze partitiebrontypen kunnen op hun beurt verwijzen naar gegevensbronnen van providers of gestructureerde gegevensbronnen. Hoewel in tabellaire modellen in Azure Analysis Services kruislingse verwijzingen naar deze verschillende gegevensbronnen en partitietypen worden ondersteund, wordt in Power BI een strengere relatie afgedwongen. Querypartitiebronnen moeten verwijzen naar providergegevensbronnen, en M-partitiebronnen moeten verwijzen naar gestructureerde gegevensbronnen. Anders combinaties worden niet ondersteund in Power BI. In de volgende tabel worden de ondersteunde configuraties beschreven voor het migreren van een gegevensset met kruislingse verwijzingen:

Gegevensbronnen en imitatie

Imitatie-instellingen die u kunt definiëren voor gegevensbronnen van providers zijn niet relevant voor Power BI. Power BI gebruikt een ander mechanisme op basis van de instellingen van de gegevensset om referenties voor gegevensbronnen te beheren. Daarom moet u Serviceaccount selecteren als u een providergegevensbron maakt.

Verfijnde verwerking

Wanneer een geplande vernieuwing of vernieuwing op aanvraag in Power BI wordt geactiveerd, wordt doorgaans de gehele gegevensset vernieuwd. In veel gevallen is het efficiënter om selectieve vernieuwingen uit te voeren. U kunt verfijnde verwerkingstaken uitvoeren in SQL Server Management Studio (SSMS), zoals hieronder wordt weergegeven, of met behulp van hulpprogramma's of scripts van derden.

Onderdrukkingen in de TMSL-opdracht Vernieuwen

Met onderdrukkingen in de opdracht Vernieuwen (TMSL) kunnen gebruikers een andere partitiequerydefinitie of gegevensbrondefinitie voor de vernieuwingsbewerking kiezen.

Fouten in SQL Server Management Studio (SMS)- Premium Gen 2

Queryuitvoering

Wanneer er verbinding wordt gemaakt met een werkruimte in Premium Gen2- of Embedded Gen2-capaciteit, kan SQL Server Management Studio volgende fout weergeven:

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.

Dit is een informatief bericht dat kan worden genegeerd in SSMS 18.8 en hoger omdat de clientbibliotheken automatisch opnieuw verbinding maken. Houd er rekening mee dat clientbibliotheken die zijn geïnstalleerd met SSMS v18.7.1 of lager geen ondersteuning bieden voor sessietraceren. Download de nieuwste SQL Server Management Studio.

Bewerkingen vernieuwen

Wanneer u SSMS v18.7.1 of lager gebruikt om een langlopende vernieuwingsbewerking (>1 min) uit te voeren op een gegevensset in een Premium Gen2- of embedded Gen2-capaciteit, kan SSMS een fout als de volgende weergeven, zelfs als de vernieuwingsbewerking slaagt:

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

Dit wordt veroorzaakt door een bekend probleem in de clientbibliotheken waarbij de status van de vernieuwingsaanvraag onjuist wordt bijgehouden. Dit probleem wordt opgelost in SQL Server Management Studio 18.8 en hoger. Download de nieuwste SQL Server Management Studio.

Verbinding maken naar server in SSMS

Wanneer u verbinding maakt met Power BI werkruimte met SQL Server Management Studio (SSMS), kan de volgende fout worden weergegeven:

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)

Wanneer u verbinding maakt met een Power BI werkruimte met SSMS, controleert u het volgende:

• De instelling voor het XMLA-eindpunt is ingeschakeld voor de capaciteit van uw tenant. Zie XmlA-lees-/schrijfbestand inschakelen voor meer informatie.
• De instelling XMLA-eindpunten toestaan en analyseren in Excel on-premises gegevenssets is ingeschakeld in Tenantinstellingen.
• U gebruikt de nieuwste versie van SSMS. Download de meest recente.

Rollidmaatschappen bewerken in SQL Server Management Studio

Bij gebruik van de SQL Server Management Studio (SSMS) v18.8 voor het bewerken van een rollidmaatschap voor een gegevensset, wordt mogelijk de volgende fout weergegeven in SSMS:

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.’ 

Dit wordt veroorzaakt door een bekend probleem in de REST API van de app-services. Dit probleem wordt opgelost in een volgende versie. In de tussentijd kunt u als tijdelijke oplossing in Eigenschappen van rol klikken op Script en vervolgens de volgende TMSL-opdracht invoeren en uitvoeren:

{ 
  "createOrReplace": { 
    "object": { 
      "database": "AdventureWorks", 
      "role": "Role" 
    }, 
    "role": { 
      "name": "Role", 
      "modelPermission": "read", 
      "members": [ 
        { 
          "memberName": "xxxx", 
          "identityProvider": "AzureAD" 
        }, 
        { 
          "memberName": “xxxx” 
          "identityProvider": "AzureAD" 
        } 
      ] 
    } 
  } 
} 

Publicatiefout - Live verbonden gegevensset

Bij het opnieuw publiceren van een live verbonden gegevensset met behulp van de Analysis Services-connector wordt mogelijk de volgende fout weergegeven:

Zoals vermeld in het foutbericht, moet u de bestaande gegevensset verwijderen of de naam ervan wijzigen om dit probleem op te lossen. Zorg er ook voor dat u alle apps die afhankelijk zijn van het rapport opnieuw publiceert. Als dat nodig is, moeten downstreamgebruikers ook worden geïnformeerd dat ze bladwijzers moeten bijwerken met het nieuwe rapportadres om ervoor te zorgen dat ze toegang hebben tot het nieuwste rapport.

Alias van de werkruimte/server

In Azure Analysis Services worden servernaamaliassen niet ondersteund voor Premium werkruimten.

DISCOVER_M_EXPRESSIONS

De DMV DISCOVER_M_EXPRESSIONS gegevensbeheerweergave (DMV) wordt momenteel niet ondersteund in Power BI het XMLA-eindpunt. Toepassingen kunnen het Tabular Object Model (TOM) gebruiken om M-expressies te verkrijgen die door het gegevensmodel worden gebruikt.

Geheugenlimiet voor resourcebeheer in Premium Gen 2

Premium Gen2-capaciteiten maken gebruik van resourcebeheer om ervoor te zorgen dat geen enkele gegevenssetbewerking de hoeveelheid beschikbare geheugenresources voor de capaciteit kan overschrijden, zoals bepaald door de SKU. Een P1-abonnement heeft bijvoorbeeld een effectieve geheugenlimiet per artefact van 25 GB, voor een P2-abonnement is de limiet 50 GB en voor een P3-abonnement is de limiet 100 GB. Naast de grootte van de gegevensset (database) is de effectieve geheugenlimiet ook van toepassing op onderliggende gegevenssetopdrachtbewerkingen zoals Maken, Wijzigenen Vernieuwen.

De effectieve geheugenlimiet voor een opdracht is gebaseerd op de lagere geheugenlimiet van de capaciteit (bepaald door SKU) of de waarde van de XMLA-eigenschap DbpropMsmdRequestMemoryLimit.

Bijvoorbeeld voor een P1-capaciteit, als:

• DbpropMsmdRequestMemoryLimit = 0 (of niet-gespecificeerd), de effectieve geheugenlimiet voor de opdracht is 25 GB.

• DbpropMsmdRequestMemoryLimit = 5 GB, de effectieve geheugenlimiet voor de opdracht is 5 GB.

• DbpropMsmdRequestMemoryLimit = 50 GB, de effectieve geheugenlimiet voor de opdracht is 25 GB.

Normaal gesproken wordt de effectieve geheugenlimiet voor een opdracht berekend op basis van het geheugen dat is toegestaan voor de gegevensset door de capaciteit (25 GB, 50 GB, 100 GB) en hoeveel geheugen de gegevensset al verbruikt wanneer de opdracht wordt uitgevoerd. Een gegevensset met 12 GB op een P1-capaciteit biedt bijvoorbeeld een effectieve geheugenlimiet voor een nieuwe opdracht van 13 GB. De effectieve geheugenlimiet kan echter verder worden beperkt door de XMLA-eigenschap DbPropMsmdRequestMemoryLimit wanneer dit optioneel is opgegeven door een toepassing. Als in het vorige voorbeeld 10 GB is opgegeven in de eigenschap DbPropMsmdRequestMemoryLimit, wordt de effectieve limiet van de opdracht verder verlaagd tot 10 GB.

Als de opdrachtbewerking meer geheugen probeert te verbruiken dan is toegestaan door de limiet, kan de bewerking mislukken en wordt er een fout geretourneerd. De volgende fout beschrijft bijvoorbeeld een effectieve geheugenlimiet van 25 GB (P1-capaciteit) omdat de gegevensset al 12 GB (12288 MB) heeft verbruikt toen de opdracht werd uitgevoerd en er een effectieve limiet van 13 GB (13312 MB) is toegepast voor de opdrachtbewerking:

Resourcebeheer: Deze bewerking is geannuleerd omdat er onvoldoende geheugen is om de bewerking uit te voeren. Vergroot het geheugen van de Premium capaciteit waarin deze gegevensset wordt gehost of verklein de geheugenvoetafdruk van uw gegevensset door bijvoorbeeld de hoeveelheid geïmporteerde gegevens te beperken. Meer informatie: verbruikt geheugen 13312 MB, geheugenlimiet 13312 MB, databasegrootte voordat de opdracht 12288 MB wordt uitgevoerd. Meer informatie: https://go.microsoft.com/fwlink/?linkid=2159753 ."

In sommige gevallen, zoals wordt weergegeven in de volgende fout, is 'verbruikt geheugen' 0, maar is de hoeveelheid die wordt weergegeven voor 'databasegrootte vóór de uitvoering van de opdracht' al groter dan de effectieve geheugenlimiet. Dit betekent dat de bewerking niet kan worden uitgevoerd omdat de hoeveelheid geheugen die al wordt gebruikt door de gegevensset groter is dan de geheugenlimiet voor de SKU.

Resourcebeheer: Deze bewerking is geannuleerd omdat er onvoldoende geheugen is om de bewerking uit te voeren. Vergroot het geheugen van de Premium capaciteit waarin deze gegevensset wordt gehost of verklein de geheugenvoetafdruk van uw gegevensset door bijvoorbeeld de hoeveelheid geïmporteerde gegevens te beperken. Meer informatie: verbruikt geheugen 0 MB, geheugenlimiet 25600 MB, databasegrootte vóór uitvoering van opdracht 26000 MB. Meer informatie: https://go.microsoft.com/fwlink/?linkid=2159753 ."

U kunt als volgende het overschrijden van de effectieve geheugenlimiet beperken:

• Upgrade naar een grotere Premium capaciteit (SKU) voor de gegevensset.
• Verklein de geheugenvoetafdruk van uw gegevensset door de hoeveelheid gegevens te beperken die bij elke vernieuwing wordt geladen.
• Voor vernieuwingsbewerkingen via het XMLA-eindpunt vermindert u het aantal partities dat parallel wordt verwerkt. Te veel partities die parallel met één opdracht worden verwerkt, kunnen de effectieve geheugenlimiet overschrijden.

Zie ook

Gegevenssetconnectiviteit met het XMLA-eindpunt
Taken voor Premium-werkruimten en -gegevenssets automatiseren met service-principals
Probleemoplossing analyseren in Excel
Tabular model solution deployment (Implementatie van oplossingen met tabellaire modellen)