Problembehandlung bei der XMLA-Endpunktkonnektivität

XMLA-Endpunkte in Power BI basieren auf dem systemeigenen Analysis Services-Kommunikationsprotokoll für den Zugriff auf Power BI-Semantikmodelle. Aus diesem Grund ist die Problembehandlung bei XMLA-Endpunkten ähnlich wie bei der Problembehandlung bei einer typischen Analysis Services-Verbindung. Einige Unterschiede in Bezug auf Power BI-spezifische Abhängigkeiten gelten jedoch.

Bevor Sie anfangen

Bevor Sie ein XMLA-Endpunktszenario behandeln, überprüfen Sie unbedingt die Grundlagen, die in der Semantikmodellkonnektivität mit dem XMLA-Endpunkt behandelt werden. Die häufigsten XMLA-Endpunkt-Anwendungsfälle werden dort behandelt. Andere Power BI-Anleitungen zur Problembehandlung, z. B. Problembehandlung für Gateways – Power BI und Problembehandlungsanalyse in Excel, können ebenfalls hilfreich sein.

Aktivieren des XMLA-Endpunkts

Der XMLA-Endpunkt kann sowohl in Power BI Premium, Premium Per User als auch in Power BI Embedded-Kapazitäten aktiviert werden. Bei kleineren Kapazitäten, z. B. einer A1-Kapazität mit nur 2,5 GB Arbeitsspeicher, tritt möglicherweise ein Fehler in den Kapazitätseinstellungen auf, wenn Sie versuchen, den XMLA-Endpunkt auf "Lesen/Schreiben " festzulegen und dann "Übernehmen" auszuwählen. Der Fehler gibt an: "Es gab ein Problem mit Ihren Workloadeinstellungen. Versuchen Sie es in einer weilen Zeit erneut.".

Hier sind ein paar Dinge, die Sie ausprobieren können:

• Beschränken Sie den Speicherverbrauch anderer Dienste für die Kapazität, z. B. Dataflows, auf 40% oder weniger, oder deaktivieren Sie einen unnötigen Dienst vollständig.
• Erhöhen Sie die Kapazität auf eine größere SKU. Beispielsweise löst das Upgrade von A1 auf eine A3-Kapazität dieses Konfigurationsproblems, ohne Dataflows deaktivieren zu müssen.

Denken Sie daran, dass Sie auch die Exportdateneinstellung auf Mandantenebene im Power BI-Verwaltungsportal aktivieren müssen. Diese Einstellung ist auch für das Feature "In Excel analysieren" erforderlich.

Einrichten einer Clientverbindung

Nach dem Aktivieren des XMLA-Endpunkts sollten Sie die Konnektivität mit einem Arbeitsbereich mit der Kapazität testen. Weitere Informationen finden Sie unter "Herstellen einer Verbindung mit einem Premium-Arbeitsbereich". Lesen Sie außerdem unbedingt den Abschnitt "Verbindungsanforderungen " für hilfreiche Tipps und Informationen zu den aktuellen EINSCHRÄNKUNGEN der XMLA-Konnektivität.

Herstellen einer Verbindung mit einem Dienstprinzipal

Wenn Sie Mandanteneinstellungen aktiviert haben, damit Dienstprinzipale Power BI-APIs verwenden können, wie in "Dienstprinzipale aktivieren" beschrieben, können Sie mithilfe eines Dienstprinzipals eine Verbindung mit einem XMLA-Endpunkt herstellen. Denken Sie daran, dass der Service Principal dieselbe Berechtigungsstufe auf Arbeitsbereichs- oder Semantikmodellebene wie normale Benutzer benötigt.

Um einen Dienstprinzipal zu verwenden, sollten Sie die Anwendungsidentitätsinformationen unbedingt in der Verbindungszeichenfolge angeben, indem Sie vorgehen wie:

• Benutzer-ID - app:appid@tenantid
• Passwort

  • cert:thumbprint (empfohlen für Sicherheit) Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;

    • Anwendungsgeheimnis

    Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;

Wenn Sie den folgenden Fehler erhalten:

"Wir können aufgrund unvollständiger Kontoinformationen keine Verbindung mit dem semantischen Modell herstellen. Stellen Sie für Dienstprinzipale sicher, dass Sie die Mandanten-ID zusammen mit der App-ID mit dem Format "appId<>@<tenantId"> angeben, und versuchen Sie es dann erneut."

Stellen Sie sicher, dass Sie die Mandanten-ID zusammen mit der App-ID mit dem richtigen Format angeben.

Es ist auch gültig, die App-ID ohne die Mandanten-ID anzugeben. In diesem Fall müssen Sie jedoch den myorg Alias in der Datenquellen-URL durch die tatsächliche Mandanten-ID ersetzen. Power BI kann dann den Dienstprinzipal im richtigen Mandanten finden. Verwenden Sie als bewährte Methode jedoch den myorg Alias, und geben Sie die Mandanten-ID zusammen mit der App-ID im Parameter "Benutzer-ID" an.

Herstellen einer Verbindung mit Microsoft Entra B2B

Mit Unterstützung für Microsoft Entra Business-to-Business (B2B) in Power BI können Sie externen Gastbenutzern Zugriff auf semantische Modelle über den XMLA-Endpunkt bieten. Stellen Sie sicher, dass die Einstellung " Inhalte für externe Benutzer freigeben " im Power BI-Verwaltungsportal aktiviert ist. Weitere Informationen finden Sie unter Verteilen von Power BI-Inhalten an externe Gastbenutzer mit Microsoft Entra B2B.

Bereitstellen eines semantischen Modells

Sie können ein Tabellarisches Modellprojekt in Visual Studio (SSDT) in einem Arbeitsbereich bereitstellen, der einer Premium-Kapazität zugewiesen ist, ähnlich wie bei einer Serverressource in Azure Analysis Services. Bei der Bereitstellung gibt es jedoch einige zusätzliche Überlegungen. Lesen Sie unbedingt den Abschnitt Bereitstellen von Modellprojekten aus Visual Studio (SSDT) in der Semantikmodellkonnektivität mit dem XMLA-Endpunktartikel.

Bereitstellen eines neuen Modells

In der Standardkonfiguration versucht Visual Studio, das Modell als Teil des Bereitstellungsvorgangs zu verarbeiten, um Daten aus den Datenquellen in das semantische Modell zu laden. Wie in "Deploy model projects from Visual Studio (SSDT)" beschrieben, kann dieser Vorgang fehlschlagen, da Datenquellenanmeldeinformationen nicht als Teil des Bereitstellungsvorgangs angegeben werden können. Wenn die Anmeldeinformationen für Ihre Datenquelle nicht bereits für ihre vorhandenen semantischen Modelle definiert sind, müssen Sie stattdessen die Datenquellenanmeldeinformationen in den Semantikmodelleinstellungen mithilfe der Power BI-Benutzeroberfläche angeben (Semantikmodelle>Einstellungen>Für Datenquellenanmeldeinformationen>). Nachdem sie die Datenquellenanmeldeinformationen definiert haben, kann Power BI die Anmeldeinformationen automatisch für jedes neue semantische Modell auf diese Datenquelle anwenden, nachdem die Metadatenbereitstellung erfolgreich war und das semantische Modell erstellt wurde.

Wenn Power BI Ihr neues Semantikmodell nicht an Datenquellenanmeldeinformationen binden kann, wird eine Fehlermeldung angezeigt: "Datenbank kann nicht verarbeitet werden. Grund: Fehler beim Speichern von Änderungen am Server." mit dem Fehlercode "DMTS_DatasourceHasNoCredentialError":

Um den Verarbeitungsfehler zu vermeiden, stellen Sie die Bereitstellungsoptionen> und die Verarbeitungsoptionen auf „Nicht verarbeiten“ ein, wie in der folgenden Abbildung dargestellt. Visual Studio stellt dann nur Metadaten bereit. Anschließend können Sie die Datenquellenanmeldeinformationen konfigurieren und auf "Jetzt aktualisieren" für das semantische Modell auf der Power BI-Benutzeroberfläche klicken.

Neues Projekt aus einem vorhandenen semantischen Modell

Das Erstellen eines neuen tabellarischen Projekts in Visual Studio durch Importieren der Metadaten aus einem vorhandenen Semantikmodell wird nicht unterstützt. Sie können jedoch eine Verbindung mit dem semantischen Modell herstellen, indem Sie SQL Server Management Studio verwenden, die Metadaten ausskripten und in anderen tabellarischen Projekten wiederverwenden.

Migrieren eines semantischen Modells zu Power BI

Es wird empfohlen, die Kompatibilitätsstufe 1500 (oder höher) für tabellarische Modelle anzugeben. Diese Kompatibilitätsstufe unterstützt die meisten Funktionen und Datenquellentypen. Spätere Kompatibilitätsstufen sind abwärtskompatibel mit früheren Ebenen.

Unterstützte Datenanbieter

Auf der Kompatibilitätsebene von 1500 unterstützt Power BI die folgenden Datenquellentypen:

• Anbieterdatenquellen (veraltet, mit einer Verbindungszeichenfolge in den Modellmetadaten).
• Strukturierte Datenquellen (eingeführt mit der Kompatibilitätsstufe 1400).
• Inline M-Deklarationen von Datenquellen (wie Power BI Desktop sie deklariert).

Es wird empfohlen, strukturierte Datenquellen zu verwenden, die von Visual Studio standardmäßig beim Durchlaufen des Datenflusses "Importieren" erstellt werden. Wenn Sie jedoch planen, ein vorhandenes Modell zu Power BI zu migrieren, das eine Anbieterdatenquelle verwendet, stellen Sie sicher, dass die Anbieterdatenquelle auf einem unterstützten Datenanbieter basiert. Insbesondere der Microsoft OLE DB-Treiber für SQL Server und alle ODBC-Treiber von Drittanbietern. Für OLE DB-Treiber für SQL Server müssen Sie die Datenquellendefinition in den .NET Framework-Datenanbieter für SQL Server wechseln. Für ODBC-Treiber von Drittanbietern, die im Power BI-Dienst möglicherweise nicht verfügbar sind, müssen Sie stattdessen zu einer strukturierten Datenquellendefinition wechseln.

Außerdem wird empfohlen, den veralteten Microsoft OLE DB-Treiber für SQL Server (SQLNCLI11) in Ihren SQL Server-Datenquellendefinitionen durch den .NET Framework-Datenanbieter für SQL Server zu ersetzen.

Die folgende Tabelle enthält ein Beispiel für einen .NET Framework-Datenanbieter für SQL Server-Verbindungszeichenfolge, der eine entsprechende Verbindungszeichenfolge für den OLE DB-Treiber für SQL Server ersetzt.

Querverweisen von Partitionsquellen

Ebenso wie es mehrere Datenquellentypen gibt, gibt es auch mehrere Partitionsquelltypen, die ein tabellarisches Modell enthalten kann, um Daten in eine Tabelle zu importieren. Insbesondere kann eine Partition eine Abfragepartitionsquelle oder eine M-Partitionsquelle verwenden. Diese Partitionsquelltypen können wiederum auf Anbieterdatenquellen oder strukturierte Datenquellen verweisen. Tabellarische Modelle in Azure Analysis Services unterstützen zwar Verweise auf verschiedene Datenquellen- und Partitionstypen; Power BI erzwingt jedoch eine strengere Beziehungsstruktur. Abfragepartitionsquellen müssen auf Anbieterdatenquellen verweisen, und M-Partitionsquellen müssen auf strukturierte Datenquellen verweisen. Andere Kombinationen werden in Power BI nicht unterstützt. Wenn Sie ein querverweisendes semantisches Modell migrieren möchten, werden in der folgenden Tabelle unterstützte Konfigurationen beschrieben:

Datenquellen und Identitätswechsel

Identitätswechseleinstellungen, die Sie für Anbieterdatenquellen definieren können, sind für Power BI nicht relevant. Power BI verwendet einen anderen Mechanismus basierend auf den Semantikmodelleinstellungen zum Verwalten von Datenquellenanmeldeinformationen. Stellen Sie daher sicher, dass Sie "Dienstkonto " auswählen, wenn Sie eine Anbieterdatenquelle erstellen.

Feinkörnige Verarbeitung

Beim Auslösen einer geplanten Aktualisierung oder Bei Bedarfsaktualisierung in Power BI aktualisiert Power BI in der Regel das gesamte Semantikmodell. In vielen Fällen ist es effizienter, Aktualisierungen selektiver durchzuführen. Sie können fein abgestimmte Verarbeitungsaufgaben in SQL Server Management Studio (SSMS) ausführen, wie in der folgenden Abbildung dargestellt, oder mithilfe von Tools oder Skripts von Drittanbietern.

Außerkraftsetzungen im Befehl "TMSL aktualisieren"

Außerkraftsetzungen im Aktualisierungsbefehl (TMSL) ermöglichen Benutzern die Auswahl einer anderen Partitionsabfragedefinition oder Datenquellendefinition für den Aktualisierungsvorgang.

E-Mail-Abonnements

Semantische Modelle, die mit einem XMLA-Endpunkt aktualisiert werden, lösen kein E-Mail-Abonnement aus.

Fehler bei Premium-Kapazität

Fehler beim Herstellen einer Verbindung mit dem Server in SSMS

Beim Herstellen einer Verbindung mit einem Power BI-Arbeitsbereich mit SQL Server Management Studio (SSMS) wird möglicherweise der folgende Fehler angezeigt:

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)

Stellen Sie beim Herstellen einer Verbindung mit einem Power BI-Arbeitsbereich mit SSMS Folgendes sicher:

• Die XMLA-Endpunkteinstellung ist für die Kapazität Ihres Mandanten aktiviert. Weitere Informationen finden Sie unter Aktivieren von XMLA-Lese-/Schreibzugriff.
• Die Einstellung "XMLA-Endpunkte zulassen" und "Analysieren" in Excel mit lokalen semantischen Modellen ist in den Mandanteneinstellungen aktiviert.
• Sie verwenden die neueste Version von SSMS. Laden Sie die neuesten Herunter.

Abfrageausführung in SSMS

Wenn eine Verbindung mit einem Arbeitsbereich in einer Power BI Premium - oder power BI Embedded-Kapazität hergestellt wird, zeigt SQL Server Management Studio möglicherweise den folgenden Fehler an:

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.

Dies ist eine Informationsmeldung, die in SSMS 18.8 und höher ignoriert werden kann, da die Clientbibliotheken automatisch wieder verbunden werden. Beachten Sie, dass clientbibliotheken, die mit SSMS v18.7.1 oder niedriger installiert sind, die Sitzungsablaufverfolgung nicht unterstützen. Laden Sie die neuesten SSMS herunter.

Ausführen eines großen Befehls mithilfe des XMLA-Endpunkts

Wenn Sie einen großen Befehl mit dem XMLA-Endpunkt ausführen, tritt möglicherweise der folgende Fehler auf:

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

Wenn Sie SSMS v18.7.1 oder niedriger verwenden, um einen langen Aktualisierungsvorgang (>1 Min.) für ein semantisches Modell in einer Power BI Premium- oder Power BI Embedded-Kapazität auszuführen, zeigt SSMS diesen Fehler möglicherweise an, obwohl der Aktualisierungsvorgang erfolgreich war. Dies ist auf ein bekanntes Problem in den Clientbibliotheken zurückzuführen, bei dem der Status der Aktualisierungsanforderung fälschlicherweise nachverfolgt wird. Dies wird in SSMS 18.8 und höher behoben. Laden Sie die neuesten SSMS herunter.

Dieser Fehler kann auch auftreten, wenn eine sehr große Anforderung an einen anderen Knoten im Premium-Cluster umgeleitet werden muss. Es wird häufig gesehen, wenn Sie versuchen, ein semantisches Modell mithilfe eines großen TMSL-Skripts zu erstellen oder zu ändern. In solchen Fällen kann der Fehler in der Regel vermieden werden, indem der Ursprüngliche Katalog auf den Namen der Datenbank festgelegt wird, bevor der Befehl ausgeführt wird.

Beim Erstellen einer neuen Datenbank können Sie beispielsweise ein leeres Semantikmodell erstellen:

{   
  "create": {   
    "database": {   
      "name": "DatabaseName"
    }   
  }   
} 

Nachdem Sie das neue semantische Modell erstellt haben, geben Sie den Anfänglichen Katalog an, und nehmen Sie dann Änderungen am Semantikmodell vor.

Andere Clientanwendungen und -tools

Clientanwendungen und -tools wie Excel, Power BI Desktop, SSMS oder externe Tools, die mit semantischen Modellen in Power BI Premium-Kapazitäten verbunden sind, können den folgenden Fehler verursachen : Der Remoteserver hat einen Fehler zurückgegeben: (400) Ungültige Anforderung.. Der Fehler kann insbesondere dann verursacht werden, wenn eine zugrunde liegende DAX-Abfrage oder ein XMLA-Befehl lange dauert. Um potenzielle Fehler zu vermeiden, müssen Sie unbedingt die neuesten Anwendungen und Tools verwenden, die die neuesten Versionen der Analysis Services-Clientbibliotheken mit regelmäßigen Updates installieren. Unabhängig von Anwendung oder Tool sind die mindestens erforderlichen Clientbibliotheksversionen, um eine Verbindung mit semantischen Modellen in einer Premium-Kapazität über den XMLA-Endpunkt herzustellen und mit diesen zu arbeiten:

Bearbeiten von Rollenmitgliedschaften in SSMS

Wenn Sie sql Server Management Studio (SSMS) v18.8 zum Bearbeiten einer Rollenmitgliedschaft in einem semantischen Modell verwenden, zeigt SSMS möglicherweise den folgenden Fehler an:

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

Dies ist auf ein bekanntes Problem in der REST-API der App-Dienste zurückzuführen. Bis diese Fehlermeldung behoben wurde, klicken Sie in den Rolleneigenschaften auf "Skript", und geben Sie dann den folgenden TMSL-Befehl ein, und führen Sie ihn aus:

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

Veröffentlichungsfehler – Live connected semantic model

Beim erneuten Veröffentlichen eines live verbundenen Semantikmodells, das den Analysis Services-Connector verwendet, wird möglicherweise der folgende Fehler angezeigt: "Es gibt ein vorhandenes Berichts-/Semantikmodell mit demselben Namen. Löschen oder umbenennen Sie das vorhandene semantische Modell, und versuchen Sie es erneut.""

Dies liegt daran, dass das semantische Modell veröffentlicht wird, das eine andere Verbindungszeichenfolge aufweist, aber denselben Namen wie das vorhandene Semantikmodell aufweist. Um dieses Problem zu beheben, löschen oder benennen Sie das vorhandene Semantikmodell um. Achten Sie außerdem darauf, alle Apps, die vom Bericht abhängig sind, erneut zu veröffentlichen. Bei Bedarf sollten nachfolgende Benutzer informiert werden, die Lesezeichen mit der neuen Berichtsadresse zu aktualisieren, damit sie auf den neuesten Bericht zugreifen können.

Das live verbundene semantische Modell kann nicht geladen werden.

Benutzer, die versuchen, ein neues Live Connected-Modell zu erstellen oder ein vorhandenes Live Connected-Modell zu öffnen, können unter Verwendung der Versionen vom März 2024 oder höher von Power BI Desktop einen Fehler wie folgt feststellen: "Wir konnten keine Verbindung mit Ihrem Modell im Power BI-Dienst herstellen. Das Dataset wurde möglicherweise gelöscht, umbenannt, verschoben oder ist möglicherweise nicht berechtigt, darauf zuzugreifen.""

Der Fehler kann auftreten, wenn ein Proxy in der Umgebung des Benutzers konfiguriert ist und der Proxy den Zugriff auf den Power BI-Dienst verhindert. Ab der Version von März 2024 von Power BI Desktop muss die Umgebung des Benutzers Verbindungen mit dem Power BI-Dienst unter dem Endpunkt *.pbidedicated.windows.net oder den entsprechenden Power BI-Dienstendpunkten für souveräne Clouds zulassen.

Um zu überprüfen, ob das Problem das Ergebnis von Proxyeinstellungen ist, probieren Sie den SQL Server Analysis Services-Connector in Power BI Desktop oder ein beliebiges externes Tool eines Drittanbieters, z. B. SQL Server Management Studio, aus, um eine Verbindung mit einem beliebigen Premium-Arbeitsbereich herzustellen.

Weitere Informationen zum Testen allgemeiner XML/A-Konnektivität finden Sie im Abschnitt zum Einrichten einer Clientverbindung in diesem Artikel.

Excel-Arbeitsmappe kann nicht geöffnet werden

Die Excel-Arbeitsmappe kann möglicherweise nicht geöffnet werden, und fehler: "Fehler bei der Initialisierung der Datenquelle. Überprüfen Sie den Datenbankserver, oder wenden Sie sich an ihren Datenbankadministrator." Wenn die Arbeitsmappe eine Verbindung mit einem Power BI-Semantikmodell enthält, überprüfen Sie, ob die Verbindungszeichenfolge die Eigenschaft "Catalog Rebound=True" enthält. Wenn die Eigenschaft gefunden wird, entfernen Sie sie, speichern Sie die Arbeitsmappe und versuchen Sie erneut, sie zu öffnen.

Die Eigenschaft "Catalog Rebound=True" wird automatisch vom OLE DB-Anbieter (MSOLAP) von Analysis Services in neueren Versionen von Excel hinzugefügt, wenn die Verbindung mit dem Power BI-Semantikmodell vom Anbieter optimiert wird. Da die Eigenschaft in der Arbeitsmappe beibehalten wird, wenn dieselbe Arbeitsmappe in Excel geöffnet wird, die eine ältere Version des Anbieters verwendet, die die Optimierung nicht unterstützt, wird die Arbeitsmappe von Excel nicht geöffnet.

"Katalog Rebound" ist nur für die interne Nutzung vorgesehen.

Arbeitsbereich/Serveralias

Im Gegensatz zu Azure Analysis Services werden Servernamen-Aliase für Premium-Arbeitsbereiche nicht unterstützt.

ERKUNDEN_M_AUSDRÜCKE

Die DMV DISCOVER_M_EXPRESSIONS Data Management View (DMV) wird derzeit nicht in Power BI über den XMLA-Endpoint unterstützt. Anwendungen können das Tabellarische Objektmodell (TOM) verwenden, um M-Ausdrücke abzurufen, die vom Datenmodell verwendet werden.

Ressourcenverwaltungsgrenzwert für Befehlsspeicher in Premium

Premium-Kapazitäten verwenden ein Ressourcenmanagement, um sicherzustellen, dass kein einzelner Vorgang des Semantikmodells die verfügbaren Speicherressourcen der Kapazität überschreiten kann, die durch die SKU bestimmt werden. Ein P1-Abonnement hat z. B. ein effektives Speicherlimit pro Element von 25 GB, für ein P2-Abonnement beträgt der Grenzwert 50 GB, und für ein P3-Abonnement beträgt der Grenzwert 100 GB. Neben der Größe des semantischen Modells (Datenbank) gilt auch die effektive Speichergrenze für zugrunde liegende Semantikmodellbefehlsvorgänge wie Create, Alter und Refresh.

Der effektive Speichergrenzwert für einen Befehl basiert auf dem geringeren Speicherlimit der Kapazität (bestimmt durch SKU) oder dem Wert der DbpropMsmdRequestMemoryLimit-XMLA-Eigenschaft .

Zum Beispiel, für eine P1-Kapazität, wenn:

• DbpropMsmdRequestMemoryLimit = 0 (oder nicht angegeben), der effektive Speichergrenzwert für den Befehl beträgt 25 GB.
• DbpropMsmdRequestMemoryLimit = 5 GB, der effektive Speichergrenzwert für den Befehl beträgt 5 GB.
• DbpropMsmdRequestMemoryLimit = 50 GB, der effektive Speichergrenzwert für den Befehl beträgt 25 GB.

Normalerweise wird der effektive Speichergrenzwert für einen Befehl auf der Grundlage des für das Semantikmodell zulässigen Speichers berechnet. Dies erfolgt basierend auf der Kapazität (25 GB, 50 GB, 100 GB) und darauf, wie viel Arbeitsspeicher das Semantikmodell bereits verbraucht, wenn der Befehl ausgeführt wird. Beispielsweise ermöglicht ein semantisches Modell, das 12 GB auf einer P1-Kapazität verwendet, eine effektive Speichergrenze für einen neuen Befehl von 13 GB. Die effektive Speichergrenze kann jedoch durch die DbPropMsmdRequestMemoryLimit-XMLA-Eigenschaft weiter eingeschränkt werden, wenn sie optional von einer Anwendung angegeben wird. Wenn im vorherigen Beispiel 10 GB in der DbPropMsmdRequestMemoryLimit-Eigenschaft angegeben werden, wird der effektive Grenzwert des Befehls weiter auf 10 GB reduziert.

Wenn der Befehlsvorgang versucht, mehr Arbeitsspeicher zu verbrauchen als durch den Grenzwert zulässig, kann der Vorgang fehlschlagen, und ein Fehler wird zurückgegeben. Der folgende Fehler beschreibt z. B. einen effektiven Speichergrenzwert von 25 GB (P1-Kapazität) wurde überschritten, da das semantische Modell bereits 12 GB (12288 MB) beim Starten der Ausführung des Befehls verbraucht hat und ein effektives Limit von 13 GB (13312 MB) für den Befehlsvorgang angewendet wurde:

Resource governing: This operation was canceled because there wasn’t enough memory to finish running it. Either increase the memory of the Premium capacity where this semantic model is hosted or reduce the memory footprint of your semantic model by doing things like limiting the amount of imported data. More details: consumed memory 13312 MB, memory limit 13312 MB, database size before command execution 12288 MB. Learn more: https://go.microsoft.com/fwlink/?linkid=2159753.

In einigen Fällen, wie im folgenden Fehler gezeigt, ist "verbrauchter Speicher" 0, aber der für "Datenbankgröße vor der Befehlsausführung" angezeigte Betrag ist bereits größer als der effektive Speichergrenzwert. Dies bedeutet, dass der Vorgang nicht mit der Ausführung beginnen konnte, da die vom Semantikmodell bereits verwendete Arbeitsspeichermenge größer als die Speichergrenze für die SKU ist.

Resource governing: This operation was canceled because there wasn't enough memory to finish running it. Either increase the memory of the Premium capacity where this semantic model is hosted or reduce the memory footprint of your semantic model by doing things like limiting the amount of imported data. More details: consumed memory 0 MB, memory limit 25600 MB, database size before command execution 26000 MB. Learn more: https://go.microsoft.com/fwlink/?linkid=2159753.

Grundlegendes zu Speicherfehlern und Wiederherstellung

Lastenausgleich über semantische Modelle hinweg wird automatisch vom System verwaltet. Speicherfehler wie die hier beschriebenen können vorübergehend in Zeiträumen mit hohem Bedarf an Ihrer Kapazität auftreten. In den meisten Fällen wird das System schnell wiederhergestellt, wenn Speicherressourcen verfügbar sind. Wenn ein Speicherfehler auftritt, warten Sie einen Moment, und wiederholen Sie den Vorgang.

Wenn Speicherfehler weiterhin bestehen oder häufig auftreten, weist dies darauf hin, dass ihre Kapazität möglicherweise zusätzliche Ressourcen oder Optimierungen erfordert. Berücksichtigen Sie in solchen Fällen die folgenden Entschärfungsstrategien, oder wenden Sie sich an den Microsoft-Support, um Unterstützung bei der Kapazitätsanpassung und Workloadoptimierung zu erhalten.

Verwandte Inhalte

• Semantische Modellkonnektivität mit dem XMLA-Endpunkt
• Automatisierung von Aufgaben im Premium-Arbeitsbereich und dem semantischen Modell mit Dienstprinzipalen
• Problembehandlung bei der Analyse in Excel
• Bereitstellung von Tabellarmodelllösungen