Felsöka anslutning för XMLA-slutpunkt

XMLA-slutpunkter i Power BI det interna Analysis Services kommunikationsprotokollet för åtkomst till Power BI datauppsättningar. På grund av detta är felsökning av XMLA-slutpunkter ungefär likadant som vid felsökning av en typisk Analysis Services-anslutning. Vissa skillnader kring Power BI-specifika beroenden gäller dock.

Innan du börjar

Innan du felsöker ett XMLA-slutpunktsscenario bör du se igenom grunderna i Datauppsättningsanslutning med XMLA-slutpunkt. De vanligaste användningsfallen för XMLA-slutpunkter beskrivs där. Andra Power BI-felsökningsguider, till exempel Felsöka gatewayer – Power BI och Felsökningsanalys i Excel, kan också vara till hjälp.

Aktivera XMLA-slutpunkten

XMLA-slutpunkten kan aktiveras på både Power BI Premium, Premium per användare och Power BI Embedded kapaciteter. På mindre kapaciteter, till exempel en a1-kapacitet med bara 2,5 GB minne, kan du stöta på ett fel i kapacitetsinställningarna när du försöker ställa in XMLA-slutpunkten för att läsa/skriva och sedan välja Tillämpa. Felet säger ”Det uppstod ett problem med dina arbetsbelastningsinställningar. Försök igen om en liten stund.”.

Här är några saker du kan prova:

• Begränsa minnesförbrukningen för andra tjänster på kapaciteten, till exempel dataflöden till 40 % eller mindre, eller inaktivera en onödig tjänst helt.
• Uppgradera kapaciteten till en större SKU. Om du till exempel uppgraderar från en A1- till en A3-kapacitet löser det konfigurationsproblemet utan att du behöver inaktivera dataflöden.

Kom ihåg att du även måste aktivera Exportera datainställningen på klientnivå på Power BI Admin-portalen. Den här inställningen krävs också för funktionen Analysera i Excel.

Upprätta en klientanslutning

När du har aktiverat XMLA-slutpunkten är det en bra idé att testa anslutningen till en arbetsyta på kapaciteten. Läs mer i Ansluta till en Premium-arbetsyta. Se också till att läsa avsnittet Anslutningskrav för användbara tips och information om aktuella begränsningar för XMLA-anslutningen.

Logga in med ett huvudnamn för tjänsten

Om du har aktiverat klientinställningar för att tillåta att tjänstens huvudnamn använder Power BI API:er, som det beskrivs i Aktivera tjänstens huvudnamn så kan du ansluta till en XMLA-slutpunkt genom att använda ett huvudnamn för tjänsten. Tänk på att tjänstens huvudnamn kräver samma behörighetsnivå på arbetsytan eller datauppsättningsnivån som vanliga användare.

Om du vill använda ett huvudnamn för tjänsten måste du ange programmets identitetsinformation i anslutningssträngen som:

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

Till exempel:

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

Om du får följande fel:

”Det går inte att ansluta till datauppsättningen på grund av ofullständig kontoinformation. För tjänstens huvudnamn, se till att du anger klient-ID tillsammans med app-ID med hjälp av formatappen:<appId>@<tenantId> och försök igen. "

Se till att du anger klient-ID tillsammans med app-ID med rätt format.

Det är också giltigt att ange app-ID utan klient-ID. I detta fall måste du dock ersätta myorg-aliaset i datakällans URL med faktiskt klient-ID. Power BI kan sedan hitta tjänstens huvudnamn i rätt klientorganisation. Men vi rekommenderar att du använder myorg-aliaset och anger klient-ID tillsammans med app-ID i User ID-parametern.

Ansluta med Azure Active Directory B2B

Med stöd för Azure Active Directory (Azure AD) Business-to-Business (B2B) i Power BI kan du ge externa gästanvändare åtkomst till datauppsättningar via XMLA-slutpunkten. Se till att inställningen Dela innehåll med externa användare är aktiverad på Power BI-administratörsportalen. Läs mer i Distribuera Power BI-innehåll till externa gästanvändare med Azure Active Directory B2B.

Distribuera en datauppsättning

Du kan distribuera ett tabellmodellprojekt i Visual Studio (SSDT) till en arbetsyta som tilldelats till en Premium-kapacitet, ungefär på samma sätt som till en serverresurs i Azure Analysis Services. Men när du distribuerar finns det några ytterligare överväganden. Se till att granska avsnittet Distribuera modellprojekt från Visual Studio (SSDT) i artikeln Datauppsättningsanslutning med XMLA-slutpunkt.

Distribuera en ny modell

I standardkonfigurationen försöker Visual Studio bearbeta modellen som en del av distributionsåtgärden för att läsa in data till datauppsättningen från datakällorna. Som det beskrivs i Distribuera modellprojekt från Visual Studio (SSDT), kan den här åtgärden misslyckas eftersom autentiseringsuppgifter för datakällan inte kan anges som en del av distributionsåtgärden. Om autentiseringsuppgifterna för datakällan inte redan har definierats för någon av dina befintliga datauppsättningar, måste du i stället ange autentiseringsuppgifter för datakällan i datauppsättningens inställningar med hjälp av Power BI-användargränssnittet (Datauppsättningar > Inställningar > Autentiseringsuppgifter för datakälla > Redigera autentiseringsuppgifter). När du har definierat autentiseringsuppgifterna för datakällan kan Power BI sedan använda autentiseringsuppgifterna för datakällan automatiskt för nya datauppsättningar, efter att metadatadistributionen har slutförts och datauppsättningen har skapats.

Om Power BI inte kan binda din nya datauppsättning till autentiseringsuppgifter för datakällan så får du felmeddelandet ”Det går inte att bearbeta databasen. Orsak: Det gick inte att spara ändringarna på servern.” med felkoden DMTS_DatasourceHasNoCredentialError, som du ser nedan:

Du undviker bearbetningsfelet genom att ange Distributionsalternativ > Bearbetningsalternativ till Bearbeta inte, som du ser i följande bild. Visual Studio distribuerar därefter bara metadata. Du kan sedan konfigurera autentiseringsuppgifterna för datakällan och klicka på Uppdatera nu för datauppsättningen i Power BI-användargränssnittet.

Nytt projekt från en befintlig datauppsättning

Att skapa ett nytt tabellprojekt i Visual Studio genom att importera metadata från en befintlig datauppsättning stöds inte. Du kan dock ansluta till datauppsättningen genom att använda SQL Server Management Studio, skripta ut metadata och återanvänd det i andra tabellprojekt.

Migrera en datauppsättning till Power BI

Vi rekommenderar att du anger kompatibilitetsnivån på 1500 (eller högre) för tabellmodeller. Den här kompatibilitetsnivån stöder de flesta kompatibiliteter och typer av datakällor. Senare kompatibilitetsnivåer är bakåtkompatibla med tidigare nivåer.

Dataleverantörer som stöds

Vid kompatibilitetsnivå 1500 stöder Power BI följande datakällstyper:

• Leverantörsdatakällor (äldre med en anslutningssträng i modellens metadata).
• Strukturerade datakällor (som introducerades med kompatibilitetsnivå 1400).
• Infogade M-deklarationer för datakällor (som Power BI Desktop deklarerar dem).

Vi rekommenderar att du använder strukturerade datakällor som Visual Studio skapar som standard när du går igenom Importera data-flödet. Men om du planerar att migrera en befintlig modell till Power BI som använder en providers datakälla, kontrollerar du att providerns datakälla förlitar sig på en dataleverantör som stöds. Mer specifikt OLE DB-drivrutinen för SQL Server och eventuella ODBC-drivrutiner från tredje part. För OLE DB-drivrutiner för SQL Server så måste du byta datakällans definition till .NET Framework Data Provider för SQL Server. För ODBC-drivrutiner från tredje part som kanske inte är tillgängliga i Power BI-tjänsten så måste du växla till en strukturerad datakällsdefinition i stället.

Det rekommenderas även att du byter ut den utdaterade Microsoft OLE DB-drivrutinen för SQL Server (SQLNCLI11) i dina SQL Server-datakällsdefinitioner mot .NET Framework Data Provider för SQL Server.

Följande tabell ger ett exempel där en .NET Framework Data Provider för SQL Server-anslutningssträng ersätter en motsvarande anslutningssträng för OLE DB-drivrutinen för SQL Server.

Korsreferera partitionskällor

Precis som det finns flera typer av datakällor så finns det också flera olika partitionskälltyper som en tabellmodell kan innehålla för att importera data till en tabell. Mer specifikt kan en partition använda en frågepartitionskälla eller en M-partitionskälla. De här partitionstyperna kan i sin tur referera till providerdatakällor eller strukturerade datakällor. Medan tabellmodeller i Azure Analysis Services stöder korsreferenser till dessa olika datakäll- och partitionstyper, framtvingar Power BI en mer strikt relation. Frågepartitionskällor måste referera till providerns datakällor och M-partitionens källor måste referera till strukturerade datakällor. Andra kombinationer stöds inte i Power BI. Om du vill migrera en korsrefererande datauppsättning beskriver följande tabell de konfigurationer som stöds:

Datakällor och personifiering

Personifieringsinställningarna som du kan definiera för providerdatakällorna är inte relevanta för Power BI. Power BI använder en annan mekanism baserat på datauppsättningsinställningarna för att hantera autentiseringsuppgifter för datakällan. Därför bör du kontrollera att du väljer Tjänstkonto om du skapar en providerdatakälla.

Detaljerad bearbetning

När du utlöser en schemalagd uppdatering eller uppdatering på begäran i Power BI så uppdaterar Power BI vanligtvis hela datauppsättningen. I många fall är det mer effektivt att utföra uppdateringar mer selektivt. Du kan utföra detaljerade bearbetningsuppgifter i SQL Server Management Studio (SSMS) som visas nedan eller med hjälp av verktyg eller skript från tredje part.

Åsidosättningar i uppdatera-kommandot för TMSL

Med åsidosättningar i uppdatera-kommandot (TMSL) kan användare välja en annan partitionsfrågedefinition eller datakälldefinition för uppdateringsåtgärden.

Fel i SSMS – Premium Gen 2

Frågekörning

När du är ansluten till en arbetsyta Premium Gen2 eller en Embedded Gen2-SQL Server Management Studio kan följande fel visas:

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.

Det här är ett informationsmeddelande som kan ignoreras i SSMS 18.8 och senare eftersom klientbiblioteken återansluts automatiskt. Observera att klientbibliotek som installeras med SSMS v18.7.1 eller lägre inte stöder sessionsspårning. Ladda ned den senaste SSMS:en.

Uppdateringsåtgärder

När du använder SSMS v18.7.1 eller lägre för att utföra en långvarig uppdateringsåtgärd (>1 min) på en datauppsättning i en Premium Gen2- eller embedded Gen2-kapacitet, kan SSMS visa ett fel som liknar följande även om uppdateringsåtgärden lyckas:

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

Detta beror på ett känt problem i klientbiblioteken där status för uppdateringsförfrågan är felaktigt spårad. Detta löses i SSMS 18.8 och senare. Ladda ned den senaste SSMS:en.

Anslut till serverfel i SSMS

När du ansluter till Power BI en arbetsyta med SQL Server Management Studio (SSMS) kan följande fel visas:

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 ansluter till Power BI med SSMS ser du till följande:

• Inställningen för XMLA-slutpunkten är aktiverad för din klients kapacitet. Mer information finns i Enable XMLA read-write.
• Inställningen Tillåt XMLA-slutpunkter och Analysera i Excel med lokala datauppsättningar är aktiverad i Klientinställningar.
• Du använder den senaste versionen av SSMS. Ladda ned den senaste.

Redigera rollmedlemskap i SSMS

När du använder SQL Server Management Studio (SSMS) v-18.8 för att redigera ett rollmedlemskap i en datauppsättning kan SSMS visa följande fel:

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

Detta beror på ett känt problem i REST API för App Services. Detta kommer att lösas i en kommande version. Under tiden kan du komma runt felet genom att klicka på Skript i Rollegenskaper och sedan ange och köra följande TMSL-kommando:

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

Publicera fel – Live-ansluten datauppsättning

När du publicerar en live-ansluten datauppsättning med hjälp av Analysis Services-anslutningen kan följande fel visas:

Du kan lösa problemet genom att ta bort eller byta namn på den befintliga datauppsättningen i felmeddelandet. Se även till att publicera om alla appar som är beroende av rapporten. Vid behov bör underordnade användare också informeras om att uppdatera eventuella bokmärken med den nya rapportadressen så att de får åtkomst till den senaste rapporten.

Alias för arbetsyta/server

Till Azure Analysis Services stöds inte servernamnalias för Premium arbetsytor.

DISCOVER_M_EXPRESSIONS

DMV-DISCOVER_M_EXPRESSIONS datahanteringsvyn (DMV) stöds för närvarande inte i Power BI använder XMLA-slutpunkten. Program kan använda tabellobjektsmodellen (TOM) för att hämta M-uttryck som används av datamodellen.

Minnesgräns för resursstyrningskommandon i Premium Gen 2

Premium Gen2-kapaciteter använder resurshantering för att se till att ingen enskild datauppsättningsåtgärd kan överskrida mängden tillgängliga minnesresurser för kapaciteten , som bestäms av SKU. Till exempel har en P1-prenumeration en effektiv minnesgräns per artefakt på 25 GB, för en P2-prenumeration är gränsen 50 GB och för en P3-prenumeration är gränsen 100 GB. Förutom datauppsättningens (databasens) storlek gäller den effektiva minnesgränsen även för underliggande kommandoåtgärder för datauppsättningen som Skapa, Ändraoch Uppdatera.

Den effektiva minnesgränsen för ett kommando baseras på den mindre av kapacitetens minnesgräns (bestäms av SKU) eller värdet för XMLA-egenskapen DbpropMsmdRequestMemoryLimit.

Till exempel för en P1-kapacitet, om:

• DbpropMsmdRequestMemoryLimit = 0 (eller ospecificerad), den effektiva minnesgränsen för kommandot är 25 GB.

• DbpropMsmdRequestMemoryLimit = 5 GB, den effektiva minnesgränsen för kommandot är 5 GB.

• DbpropMsmdRequestMemoryLimit = 50 GB, den effektiva minnesgränsen för kommandot är 25 GB.

Normalt beräknas den effektiva minnesgränsen för ett kommando på det minne som tillåts för datauppsättningen av kapaciteten (25 GB, 50 GB, 100 GB) och hur mycket minne datauppsättningen redan använder när kommandot börjar köras. Till exempel tillåter en datauppsättning som använder 12 GB på en P1-kapacitet en effektiv minnesgräns för ett nytt kommando på 13 GB. Den effektiva minnesgränsen kan dock begränsas ytterligare av XMLA-egenskapen DbPropMsmdRequestMemoryLimit när det eventuellt anges av ett program. Om 10 GB anges i egenskapen DbPropMsmdRequestMemoryLimit i föregående exempel minskas kommandots effektiva gräns ytterligare till 10 GB.

Om kommandoåtgärden försöker förbruka mer minne än vad som tillåts av gränsen kan åtgärden misslyckas och ett fel returneras. Följande fel beskriver till exempel att en effektiv minnesgräns på 25 GB (P1-kapacitet) har överskridits eftersom datauppsättningen redan förbrukade 12 GB (12288 MB) när kommandot startades och en effektiv gräns på 13 GB (13312 MB) tillämpades för kommandoåtgärden:

"Resurshantering: Den här åtgärden avbröts eftersom det inte fanns tillräckligt med minne för att slutföra körningen. Öka antingen minnet för Premium kapacitet där datauppsättningen finns eller minska minnesfotavtrycket för din datauppsättning genom att göra saker som att begränsa mängden importerade data. Mer information: förbrukat minne 13312 MB, minnesgräns 13312 MB, databasstorlek före kommandokörning 12288 MB. Läs mer: https://go.microsoft.com/fwlink/?linkid=2159753 ."

I vissa fall, som du ser i följande fel, är "förbrukat minne" 0, men mängden som visas för "databasstorlek före kommandokörning" är redan större än den effektiva minnesgränsen. Det innebär att åtgärden inte kunde starta körningen eftersom mängden minne som redan används av datauppsättningen är större än minnesgränsen för SKU:n.

"Resurshantering: Den här åtgärden avbröts eftersom det inte fanns tillräckligt med minne för att slutföra körningen. Öka antingen minnet för Premium kapacitet där datauppsättningen finns eller minska minnesfotavtrycket för din datauppsättning genom att göra saker som att begränsa mängden importerade data. Mer information: förbrukat minne 0 MB, minnesgräns 25 600 MB, databasstorlek före kommandokörning 26 000 MB. Läs mer: https://go.microsoft.com/fwlink/?linkid=2159753 ."

Så här minskar du eventuellt den effektiva minnesgränsen:

• Uppgradera till en större Premium kapacitet (SKU) för datauppsättningen.
• Minska minnesfotavtrycket för din datauppsättning genom att begränsa mängden data som läses in vid varje uppdatering.
• För uppdateringsåtgärder via XMLA-slutpunkten minskar du antalet partitioner som bearbetas parallellt. För många partitioner som bearbetas parallellt med ett enda kommando kan överskrida den effektiva minnesgränsen.

Se även

Anslutning av datauppsättning med XMLA-slutpunkten
Automatisera arbetsyte- och datauppsättningsåtgärder i Premium med hjälp av tjänstens huvudnamn
Felsöka Analysera i Excel
Distribution av lösning för tabellmodell