In diesem Artikel werden einige häufige Probleme erläutert, die beim Verwenden des lokalen Datengateways auftreten können.

Hinweis: Wenn bei Ihnen ein Fehler auftritt, der hier nicht aufgelistet ist, können Sie an den folgenden Orten nach weiterer Unterstützung fragen.

  • Für Power BI können Sie die Community-Website verwenden oder ein Support-Ticket erstellen.
  • Für PowerApps können Sie die Community-Website verwenden oder ein Support-Ticket erstellen.
  • Für Microsoft Flow können Sie die Community-Website verwenden oder ein Support-Ticket erstellen.
  • Für Logic Apps können Sie ein Support-Ticket über das Azure-Portal senden.

Aktualisieren auf die neueste Version

Viele Probleme können auftreten, wenn die Gatewayversion veraltet ist. Es ist ratsam sicherzustellen, dass Sie immer die aktuelle Version verwenden. Wenn Sie das Gateway einen Monat oder länger nicht mehr aktualisiert haben, sollten Sie die aktuelle Version des Gateways installieren und prüfen, ob Sie das Problem reproduzieren können.

Häufige Probleme

Im Folgenden werden einige häufig auftretenden Probleme und Lösungen aufgeführt, die von Kunden in Umgebungen mit eingeschränktem Zugriff auf das Internet erfolgreich eingesetzt wurden.

Authentifizierung beim Proxyserver

Für Ihren Proxyserver ist möglicherweise eine Authentifizierung über ein Domänenbenutzerkonto erforderlich. Standardmäßig verwendet das Gateway eine Dienst-SID für den Anmeldebenutzer im Windows-Dienst. Dieses Problem kann durch das Ändern des Anmeldebenutzers in einen Domänenbenutzer behoben werden. Weitere Informationen finden Sie unter Ändern des Gateway-Dienstkontos in einen Domänenbenutzer.

Der Proxy lässt nur Datenverkehr über die Ports 80 und 443 zu.

Einige Proxys beschränken den Datenverkehr auf die Ports 80 und 443. Standardmäßig erfolgt die Kommunikation mit dem Azure Service Bus über andere Ports als 443.

Sie können erzwingen, dass das Gateway zur Kommunikation mit Azure Service Bus anstelle von TCP das HTTPS-Protokoll verwendet. Dadurch wird allerdings die Leistung erheblich beeinträchtigt. Hierzu muss an der Datei Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config eine Änderung vorgenommen werden. Ändern Sie den Wert von AutoDetect in Https. Standardmäßig befindet sich diese Datei unter C:\Programme\Lokales Datengateway.

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

Installation

Fehler: Fehler beim Hinzufügen des Benutzers zur Gruppe. (-2147463168 PBIEgwService Benutzer des Leistungsprotokolls)

Dieser Fehler wird möglicherweise angezeigt, wenn Sie versuchen, das Gateway auf einem Domänencontroller zu installieren. Das Bereitstellen auf einem Domänencontroller wird nicht unterstützt. Sie müssen das Gateway auf einem Computer bereitstellen, der kein Domänencontroller ist.

Konfiguration

So starten Sie das Gateway neu

Das Gateway wird als Windows-Dienst ausgeführt, Sie haben daher mehrere Möglichkeiten zum Starten und Beenden. Sie können z. B. eine Eingabeaufforderung mit erhöhten Berechtigungen auf dem Computer öffnen, auf dem das Gateway ausgeführt wird, und dann einen der folgenden Befehle eingeben:

  • Führen Sie diesen Befehl aus, um den Dienst zu beenden:

    ''' net stop PBIEgwService '''

  • Führen Sie diesen Befehl aus, um den Dienst zu starten:

    ''' net start PBIEgwService '''

Fehler: Fehler beim Erstellen des Gateways. Versuchen Sie es erneut.

Alle Details sind verfügbar, aber der Aufruf des Power BI-Diensts gab eine Fehlermeldung zurück. Die Fehlermeldung und eine Aktivitäts-ID werden angezeigt. Dies kann aus unterschiedlichen Gründen eintreten. Die unten genannten Protokolle lassen sich zusammenstellen und prüfen, um weitere Details zu erhalten.

Der Fehler kann auch auf eine fehlerhafte Proxykonfiguration zurückzuführen sein. Die Benutzeroberfläche unterstützt jetzt die Konfiguration eines Proxys. Hier erhalten Sie weitere Informationen zum Ändern der Proxykonfiguration

Fehler: Fehler beim Aktualisieren des Gateways. Versuchen Sie es erneut.

Informationen wurden vom Power BI-Dienst an das Gateway empfangen. Die Informationen wurden dem lokalen Windows-Dienst übergeben, aber nicht zurückgeliefert. Möglicherweise ist die Erstellung eines symmetrischen Schlüssels fehlgeschlagen. Die innere Ausnahme wird unter Details anzeigenangezeigt. Die unten genannten Protokolle lassen sich zusammenstellen und prüfen, um weitere Details zu erhalten.

Fehler: Der Power BI-Dienst hat gemeldet, dass das lokale Gateway nicht erreichbar ist. Bitte starten Sie das Gateway neu, und versuchen Sie es erneut.

Am Ende der Konfiguration wird Power BI-Dienst erneut aufgerufen, um das Gateway zu validieren. Der Power BI-Dienst hat dabei das Gateway nicht als live gemeldet. Das Neustarten des Windows-Diensts könnte bewirken, dass die Kommunikation anschließend erfolgreich ist. Die unten genannten Protokolle lassen sich zusammenstellen und prüfen, um weitere Details zu erhalten.

Skriptfehler bei der Anmeldung bei Power BI

Sie erhalten möglicherweise einen Skriptfehler, wenn Sie sich im Rahmen der Konfiguration des lokalen Datengateways bei Power BI anmelden. Das Problem sollte gelöst werden, wenn Sie das folgende Sicherheitsupdate installieren. Die Installation kann über Windows Update durchgeführt werden.

MS16-051: Sicherheitsupdate für Internet Explorer: 10. Mai 2016 (KB 3154070)

Gateway configuration failed with a null reference exception (Fehler bei der Gatewaykonfiguration mit einer Nullverweisausnahme)

Es könnte ein Fehler ähnlich dem folgenden auftreten:

    Failed to update gateway details.  Please try again.
    Error updating gateway configuration.

Dazu gehört eine Stapelüberwachung, die Folgendes enthalten kann:

    Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.CouldNotUpdateGatewayConfigurationException: Error updating gateway configuration. ----> System.ArgumentNullException: Value cannot be null.
    Parameter name: serviceSection

Wenn Sie von einem älteren Gateway aktualisieren, bleibt die Konfigurationsdatei erhalten. Möglicherweise fehlt ein Abschnitt. Wenn das Gateway versucht, diesen zu lesen, erhalten wir die oben genannte Nullverweisausnahme.

Führen Sie die folgenden Schritte aus, um den Fehler zu beheben.

  1. Deinstallieren Sie das Gateway.

  2. Löschen Sie den folgenden Ordner:

    c:\Program Files\on-premises data gateway
    
  3. Installieren Sie das Gateway erneut.

  4. Wenden Sie bei Bedarf den Wiederherstellungsschlüssel an, um ein vorhandenes Gateway wiederherzustellen.

Datenquellen

Fehler: Es konnte keine Verbindung hergestellt werden. Details: „Ungültige Anmeldeinformationen für die Verbindung.“

In Details anzeigensollte die von der Datenquelle empfangene Fehlermeldung angezeigt werden. Für SQL Server sollte etwa Folgendes angezeigt werden:

Login failed for user 'username'.

Achten Sie darauf, dass Benutzername und Kennwort richtig sind. Überprüfen Sie auch, ob anhand dieser Anmeldeinformationen eine Verbindung mit der Datenquelle hergestellt werden kann. Achten Sie auch darauf, dass das verwendete Konto der ausgewählten Authentifizierungsmethodeentspricht.

Fehler: Es konnte keine Verbindung hergestellt werden. Details: „Es konnte keine Verbindung mit der Datenbank hergestellt werden.“

Wir konnten die Verbindung mit dem Server, jedoch nicht mit der angeforderten Datenbank herstellen. Überprüfen Sie den Namen der Datenbank sowie die erforderliche Berechtigung des Benutzers für den Zugriff auf die Datenbank.

In Details anzeigensollte die von der Datenquelle empfangene Fehlermeldung angezeigt werden. Für SQL Server sollte etwa Folgendes angezeigt werden:

Cannot open database "AdventureWorks" requested by the login. The login failed. Login failed for user 'username'.

Fehler: Es konnte keine Verbindung hergestellt werden. Details: „Unbekannter Fehler in Datengateway“

Dieser Fehler kann aus verschiedenen Gründen auftreten. Achten Sie darauf, dass Sie von dem Computer, auf dem das Gateway ausgeführt wird, eine Verbindung mit der Datenquelle herstellen können. Es könnte auch an einem nicht erreichbaren DHCP-Server liegen.

In Details anzeigenwird der Fehlercode DM_GWPipeline_UnknownErrorangezeigt.

Sie können auch in den Ereignisprotokollen nach weiteren Details suchen: „Ereignisprotokolle“ > Anwendungs- und Dienstprotokolle > Dienst Lokales Datengateway.

Fehler: Fehler beim Herstellen einer Verbindung mit. Details: „Das Datengateway wurde erreicht, aber das Gateway kann nicht auf die lokale Datenquelle zugreifen.“

Wir konnten keine Verbindung mit der angegebenen Datenquelle herstellen. Überprüfen Sie die für diese Datenquelle angegebenen Informationen.

In Details anzeigenwird der Fehlercode DM_GWPipeline_Gateway_DataSourceAccessErrorangezeigt.

Wenn die zugrunde liegende Fehlermeldung ähnlich wie die folgende ist, bedeutet dies, dass das Konto, das Sie für die Datenquelle verwenden, keinem Serveradministrator für diese Analysis Services-Instanz gehört. Weitere Informationen

The 'CONTOSO\account' value of the 'EffectiveUserName' XML for Analysis property is not valid.

Wenn die zugrunde liegende Fehlermeldung der folgenden ähnelt, könnte dies bedeuten, dass das Verzeichnisattribut token-groups-global-and-universal (TGGAU) womöglich nicht im Servicekonto für Analysis Services vorhanden ist:

The user name or password is incorrect.

Bei Domänen, die mit Windows-Versionen vor Windows 2000 kompatibel sind, ist das TGGAU-Attribut aktiviert. Allerdings aktivieren die meisten neu erstellten Domänen dieses Attribut nicht standardmäßig. Weitere Informationen zu diesem Thema finden Sie hier.

Sie können dies wie folgt überprüfen.

  1. Verbinden Sie sich mit dem Analysis Services-Computer in SQL Server Management Studio. Schließen Sie in den erweiterten Verbindungseigenschaften EffectiveUserName für den betreffenden Benutzer ein, und prüfen Sie, ob der Fehler erneut auftritt.

  2. Sie können das Active Directory-Tool „Dsacls“ verwenden, um zu überprüfen, ob das Attribut aufgeführt ist. Dieses Tool befindet sich normalerweise auf einem Domänencontroller. Sie müssen wissen, wie der spezifische Domänenname für das Konto lautet und ihn an das Tool weitergeben.

    dsacls "CN=John Doe,CN=UserAccounts,DC=contoso,DC=com"
    

    Das Ergebnis wird in etwa das folgende sein:

        Allow BUILTIN\Windows Authorization Access Group
                                      SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
                                      READ PROPERTY
    

Um dieses Problem zu beheben, müssen Sie das TGGAU-Attribut auf dem Konto aktivieren, das für den Analysis Services-Windows-Dienst verwendet wird.

Eine weitere mögliche Ursache für die Meldung „User name or password incorrect“ (Benutzername oder Kennwort falsch).

Dieser Fehler kann auch dadurch verursacht werden, dass sich der Analysis Services-Server in einer anderen Domäne als die Benutzer befindet und keine bidirektionale Vertrauensstellung eingerichtet ist.

In diesem Fall müssen Sie mit Ihren Domänenadministratoren zusammenarbeiten, um die Vertrauensstellung zwischen den Domänen zu überprüfen.

Datengateway-Datenquellen können nicht in der Datenabrufumgebung aus dem Power BI-Dienst für Analysis Services angezeigt werden

Stellen Sie sicher, dass Ihr Konto auf der Registerkarte Benutzer der Datenquelle in der Gateway-Konfiguration aufgelistet ist. Wenn Sie keinen Zugriff auf das Gateway haben, wenden Sie sich an den Administrator des Gateways und bitten Sie ihn um die Überprüfung. Die in der Analysis Services-Liste aufgeführte Datenquelle ist nur für Konten in der Liste Benutzer sichtbar.

Datasets

Fehler: Für diese Zeile ist nicht ausreichend Platz vorhanden.

Dieser Fehler tritt auf, wenn eine einzelne Zeile größer als 4 MB ist. Finden Sie in diesem Fall heraus, um welche Zeile in der Datenquelle es sich handelt, und versuchen Sie, die Zeile herauszufiltern oder deren Größe zu verringern.

Fehler: Der angegebene Servername stimmt nicht mit dem Servernamen auf dem SQL Server-SSL-Zertifikat überein.

Dieser Fehler kann auftreten, wenn der allgemeine Name des Zertifikats für den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers gilt, Sie jedoch nur den NetBIOS-Namen des Servers angegeben haben. Dies verursacht eine Nichtübereinstimmung für das Zertifikat. Um dieses Problem zu beheben, muss in der Gatewaydatenquelle und in der PBIX-Datei der FQDN des Servers als Servername verwendet werden.

Beim Konfigurieren der geplanten Aktualisierung wird das lokale Datengateway nicht angezeigt.

Dies kann durch unterschiedliche Szenarien verursacht werden.

  1. In Power BI Desktop wurden andere Server- und Datenbanknamen als in der für das Gateway konfigurierten Datenquelle eingegeben. Sie müssen die gleichen Werte aufweisen. Dabei wird die Groß-/Kleinschreibung nicht beachtet.

  2. Ihr Konto ist nicht auf der Registerkarte Benutzer der Datenquelle in der Gatewaykonfiguration aufgelistet. Sie müssen den Administrator des Gateways bitten, Ihr Konto dieser Liste hinzuzufügen.

  3. Die Power BI Desktop-Datei verfügt über mehrere Datenquellen, und nicht alle dieser Datenquellen sind für das Gateway konfiguriert. Jede Datenquelle muss für das Gateway definiert sein, damit das Gateway in der geplanten Aktualisierung angezeigt wird.

Warnung:

Wenn eine der Datenquellen OAuth-Authentifizierung erfordert, können Sie sie nicht für das lokale Datengateway konfigurieren. OAuth-Authentifizierung wird für das lokale Datengateway derzeit nicht unterstützt. Sie müssen die Datenquelle, die OAuth-Authentifizierung erfordert, aus Power BI Desktop entfernen, um die geplante Aktualisierung zu konfigurieren.

Berichte

Bericht konnte nicht auf die Datenquelle zugreifen, weil Sie nicht über ein lokales Datengateway auf Ihre Datenquelle zugreifen können.

Hierfür gibt es meist eine der folgenden Ursachen.

  1. Die Datenquelleninformationen stimmen nicht mit dem Inhalt des zugrunde liegenden Datasets überein. Der Server- und der Datenbankname der Datenquelle, die für On-premises data gateway definiert ist, müssen mit Ihren Angaben in Power BI Desktop übereinstimmen. Wenn Sie in Power BI Desktop eine IP-Adresse verwenden, müssen Sie für die On-premises data gateway-Quelle, ebenfalls eine IP-Adresse verwenden.

  2. Auf den Gateways Ihrer Organisation sind keine Datenquellen verfügbar. Sie können die Datenquelle auf einem neuen oder vorhandenen lokalen Gateway konfigurieren.

Fehler: Fehler beim Zugriff auf die Datenquelle. Bitte wenden Sie sich an den Gatewayadministrator.

Wenn dieser Bericht eine Liveverbindung mit Analysis Services verwendet, könnte ein Problem mit einem an EffectiveUserName übergebenen Wert auftreten, der entweder nicht gültig ist oder über keine Berechtigungen auf dem Analysis Services-Computer verfügt. Ein Authentifizierungsproblem ist normalerweise darauf zurückzuführen, dass der Wert, der an EffectiveUserName übergeben wird, mit keinem lokalen Benutzerprinzipalnamen (user principal name; UPN) übereinstimmt.

Sie können Folgendes tun, um dies zu bestätigen.

  1. Suchen Sie den effektiven Benutzernamen innerhalb der Gatewayprotokolle.

  2. Wenn Sie den zu übergebenden Wert ermittelt haben, überprüfen Sie, ob er korrekt ist. Falls es sich um Ihren Benutzer handelt, können Sie den folgenden Befehl in einer Eingabeaufforderung ausführen, um den UPN herauszufinden. Der Benutzerprinzipalname sieht wie eine E-Mail-Adresse aus.

    whoami /upn
    

Sie können optional anzeigen, was Power BI von Azure Active Directory erhält.

  1. Navigieren Sie zu https://graphexplorer.cloudapp.net.

  2. Wählen Sie Sign in (Anmelden) in der rechten oberen Ecke aus.

  3. Führen Sie die folgende Abfrage aus. Ihnen wird eine ziemlich große JSON-Antwort angezeigt.

    https://graph.windows.net/me?api-version=1.5
    
  4. Suchen Sie nach userPrincipalName.

Wenn Ihr Azure Active Directory-UPN nicht mit Ihrem lokalen Active Directory-UPN übereinstimmt, können Sie die Funktion Benutzernamen zuordnen verwenden, um ihn durch einen gültigen Wert zu ersetzen. Alternativ können Sie sich entweder an Ihren Mandantenadministrator oder an Ihren lokalen Active Directory-Administrator wenden, damit er Ihren UPN ändert.

Firewall oder Proxy

Informationen zum Bereitstellen von Proxyinformationen für Ihr Gateway finden Sie unter Konfigurieren von Proxyeinstellungen für Power BI Gateways.

Sie können mit dem Befehl Test-NetConnection in einer PowerShell-Eingabeaufforderung testen, ob Ihre Firewall oder Ihr Proxy Verbindungen blockiert. Damit wird die Verbindung zum Azure Service Bus getestet. Es wird dadurch nur die Netzwerkverbindung getestet. Dies hat nichts mit dem Cloudserverdienst oder dem Gateway zu tun. Der Test hilft Ihnen dabei, zu bestimmen, ob Ihr Computer wirklich eine Verbindung mit dem Internet herstellen kann.

Test-NetConnection -ComputerName watchdog.servicebus.windows.net -Port 9350
Hinweis:

„Test-NetConnection“ ist nur unter Windows Server 2012 R2 und höher sowie unter Windows 8.1 und höher verfügbar. Bei früheren Betriebssystemversionen können Sie „Telnet“ verwenden, um die Konnektivität von Ports zu überprüfen.

Sie sollten in etwa folgende Ergebnisse erhalten. „TcpTestSucceeded“ wird vermutlich abweichen. Wenn TcpTestSucceeded nicht true ist, wird der Zugriff möglicherweise durch eine Firewall blockiert.

ComputerName           : watchdog.servicebus.windows.net
RemoteAddress          : 70.37.104.240
RemotePort             : 5672
InterfaceAlias         : vEthernet (Broadcom NetXtreme Gigabit Ethernet - Virtual Switch)
SourceAddress          : 10.120.60.105
PingSucceeded          : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded       : True

Für ein umfassendes Ergebnis können Sie die Werte ComputerName und Port durch die Angaben für Ports ersetzen.

Die Firewall blockiert möglicherweise auch die Verbindungen, die vom Azure Service Bus zu den Azure-Rechenzentren hergestellt werden. In diesem Fall müssen Sie die Blockierung der IP-Adressen Ihrer Region für diese Rechenzentren aufheben (freigeben). Hier finden Sie eine Liste der Azure IP-Adressen.

Sie können die Rechenzentrumsregion, in der Sie sich befinden, wie folgt herausfinden:

  1. Wählen Sie das ? in der oberen rechten Ecke des Power BI-Diensts.

  2. Wählen Sie Info aus.

  3. Ihre Datenregion wird unter Ihre Daten sind gespeichert in aufgelistet.

Wenn Sie noch immer nicht weiterkommen, versuchen Sie mithilfe eines Tools wie Fiddler oder Netsh eine Netzwerkablaufverfolgung durchzuführen. Allerdings handelt es sich bei diesen Tools um fortgeschrittene Erfassungsmethoden, weswegen Sie möglicherweise Unterstützung beim Analysieren der gesammelten Daten benötigen. Sie können den Support um Unterstützung bitten.

Leistung

Leistungsindikatoren

Es gibt eine Reihe von Leistungsindikatoren, die zum Messen der Aktivitäten für das Gateway verwendet werden können. Diese können hilfreich sein, um nachzuvollziehen, ob eine große Auslastung mit Aktivitäten vorhanden ist und möglicherweise ein neues Gateway eingerichtet werden muss. Diese Leistungsindikatoren spiegeln nicht wider, wie lange bestimmte Aktionen dauern.

Sie können über das Tool „Windows-Systemmonitor“ auf diese Leistungsindikatoren zugreifen.

Es gibt drei allgemeine Gruppierungen dieser Leistungsindikatoren.

Indikatortyp Beschreibung
ADO.NET Wird für alle DirectQuery-Verbindungen verwendet.
ADOMD Wird für Analysis Services 2014 und frühere Versionen verwendet.
OLEDB Wird von bestimmten Datenquellen verwendet. Dies schließt SAP HANA und Analysis Services 2016 und höher ein.
Mashup Umfasst alle importierten Datenquellen. Wenn Sie eine Aktualisierung planen oder eine Aktualisierung nach Bedarf ausführen, wird das Mashup-Modul durchlaufen.

Im Folgenden finden Sie eine Liste der verfügbaren Leistungsindikatoren.

Leistungsindikator Beschreibung
# von hergestellten ADO.NET-Verbindungen/s Anzahl der pro Sekunde ausgeführten ADO.NET-Aktionen zum Öffnen einer Verbindung (erfolgreich oder Fehler).
# von ADO.NET-Verbindungen mit Fehlern/s Anzahl der ADO.NET-Aktionen zum Öffnen einer Verbindung mit Fehlern pro Sekunde.
# von ausgeführten ADO.NET-Abfragen/s Anzahl der pro Sekunde ausgeführten ADO.NET-Abfragen (erfolgreich oder Fehler).
# von ADO.NET-Abfragen mit Fehlern/s Anzahl von pro Sekunde ausgeführten ADO.NET-Abfragen mit Fehlern.
# von hergestellten ADOMD-Verbindungen/s Anzahl der pro Sekunde ausgeführten ADOMD-Aktionen zum Öffnen einer Verbindung (erfolgreich oder Fehler).
# von ADOMD-Verbindungen mit Fehlern/s Anzahl der ADOMD-Aktionen zum Öffnen einer Verbindung mit Fehlern pro Sekunde.
# von ausgeführten ADOMD-Abfragen/s Anzahl der pro Sekunde ausgeführten ADOMD-Abfragen (erfolgreich oder Fehler).
# von ADOMD-Abfragen mit Fehlern/s Anzahl von pro Sekunde ausgeführten ADOMD-Abfragen mit Fehlern.
# aller hergestellten Verbindungen/s Anzahl der pro Sekunde ausgeführten Aktionen zum Öffnen einer Verbindung (erfolgreich oder Fehler).
# aller Verbindungen mit Fehlern/s Anzahl der Aktionen zum Öffnen einer Verbindung pro Sekunde mit Fehlern.
# aller ausgeführten Abfragen/s Anzahl der pro Sekunde ausgeführten Abfragen (erfolgreich oder Fehler).
# von Elementen im ADO.NET-Verbindungspool Anzahl der Elemente im ADO.NET-Verbindungspool.
# von Elementen im OLEDB-Verbindungspool Anzahl der Elemente im OLEDB-Verbindungspool.
# von Elementen im Service Bus-Pool Anzahl der Elemente im Service Bus-Pool.
# von hergestellten Mashup-Verbindungen/s Anzahl der pro Sekunde ausgeführten Mashup-Aktionen zum Öffnen einer Verbindung (erfolgreich oder Fehler).
# von Mashup-Verbindungen mit Fehlern/s Anzahl der Mashup-Aktionen zum Öffnen einer Verbindung pro Sekunde mit Fehlern.
# von ausgeführten Mashup-Abfragen/s Anzahl der pro Sekunde ausgeführten Mashup-Abfragen (erfolgreich oder Fehler).
# von Mashup-Abfragen mit Fehlern/s Anzahl von pro Sekunde ausgeführten Mashup-Abfragen mit Fehlern
# von mehreren Resultsets von OLEDB-Abfragen mit Fehlern/s Anzahl von OLEDB-Abfragen mit Fehlern für mehrere Resultsets, die pro Sekunde ausgeführt wurden.
# von ausgeführten OLEDB-Abfragen von mehreren Resultsets mit Fehlern/s Anzahl der pro Sekunde ausgeführten OLEDB-Abfragen mit mehreren Resultsets (erfolgreich oder Fehler).
# von hergestellten OLEDB-Verbindungen/s Anzahl der pro Sekunde ausgeführten OLEDB-open connection-Aktionen (erfolgreich oder Fehler).
# von OLEDB-Verbindungen mit Fehlern/s Anzahl der OLEDB-Aktionen zum Öffnen einer Verbindung pro Sekunde mit Fehlern.
# von ausgeführten OLEDB-Abfragen/s Anzahl der pro Sekunde ausgeführten OLEDB-Abfragen mit mehreren Resultsets (erfolgreich oder Fehler).
# von OLEDB-Abfragen mit Fehlern/s Anzahl von OLEDB-Abfragen mit Fehlern mit mehreren Resultsets, die pro Sekunde ausgeführt wurden.
# von ausgeführten OLEDB-Abfragen mit einem Resultset/s Anzahl der pro Sekunde ausgeführten OLEDB-Abfragen mit einem Resultset (erfolgreich oder Fehler).
# von Abfragen mit Fehlern/s Anzahl von pro Sekunde ausgeführten Abfragen mit Fehlern.
# von OLEDB-Abfragen mit einem Resultset mit Fehlern/s Anzahl von OLEDB-Abfragen mit Fehlern mit einem Resultset, die pro Sekunde ausgeführt wurden.

Überprüfen von Abfragen mit geringer Leistung

Es kann vorkommen, dass die Antwort über das Gateway langsam ist. Dies kann bei DirectQuery-Abfragen oder beim Aktualisieren eines importierten Datasets auftreten. Sie können zusätzliche Protokolle aktivieren, um Abfragen und die entsprechenden Zeitpunkte auszugeben und so den Grund für die geringe Leistung nachzuvollziehen. Wenn Sie eine Abfrage ermitteln, die lange ausgeführt wird, müssen Sie möglicherweise zusätzliche Änderungen an der Datenquelle vornehmen, um die Leistung von Abfragen zu optimieren. Ein Beispiel hierfür ist das Anpassen von Indizes für eine SQL Server-Abfrage.

Sie müssen zwei Konfigurationsdateien ändern, um die Dauer einer Abfrage zu bestimmen.

Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config

Ändern Sie in der Datei Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config den EmitQueryTraces-Wert von False in True. Standardmäßig befindet sich diese Datei unter C:\Programme\Lokales Datengateway. Durch Aktivieren von EmitQueryTraces wird mit dem Protokollieren von Abfragen begonnen, die vom Gateway an eine Datenquelle gesendet werden.

Wichtig:

Das Aktivieren von EmitQueryTraces kann die Größe des Protokolls erheblich erhöhen, abhängig von der Auslastung des Gateways. Wenn Sie die Protokolle überprüft haben, sollten Sie EmitQueryTraces auf „False“ festlegen. Es wird nicht empfohlen, diese Einstellung langfristig aktiviert zu lassen.

<setting name="EmitQueryTraces" serializeAs="String">
    <value>True</value>
</setting>

Beispiel für Abfrageeintrag

DM.EnterpriseGateway Information: 0 : 2016-09-15T16:09:27.2664967Z DM.EnterpriseGateway    4af2c279-1f91-4c33-ae5e-b3c863946c41    d1c77e9e-3858-4b21-3e62-1b6eaf28b176    MGEQ    c32f15e3-699c-4360-9e61-2cc03e8c8f4c    FF59BC20 [DM.GatewayCore] Executing query (timeout=224) "<pi>
SELECT
TOP (1000001) [t0].[ProductCategoryName],[t0].[FiscalYear],SUM([t0].[Amount])
 AS [a0]
FROM
(
(select [$Table].[ProductCategoryName] as [ProductCategoryName],
    [$Table].[ProductSubcategory] as [ProductSubcategory],
    [$Table].[Product] as [Product],
    [$Table].[CustomerKey] as [CustomerKey],
    [$Table].[Region] as [Region],
    [$Table].[Age] as [Age],
    [$Table].[IncomeGroup] as [IncomeGroup],
    [$Table].[CalendarYear] as [CalendarYear],
    [$Table].[FiscalYear] as [FiscalYear],
    [$Table].[Month] as [Month],
    [$Table].[OrderNumber] as [OrderNumber],
    [$Table].[LineNumber] as [LineNumber],
    [$Table].[Quantity] as [Quantity],
    [$Table].[Amount] as [Amount]
from [dbo].[V_CustomerOrders] as [$Table])
)
 AS [t0]
GROUP BY [t0].[ProductCategoryName],[t0].[FiscalYear] </pi>"

Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config

Ändern Sie in der Datei Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.dll.config den TraceVerbosity-Wert von 4 in 5. Standardmäßig befindet sich diese Datei unter C:\Programme\Lokales Datengateway. Durch das Ändern dieser Einstellung wird mit dem Protokollieren von ausführlichen Einträgen im Gateway-Protokoll begonnen. Dazu gehören auch Einträge, die die Dauer anzeigen.

Wichtig:

Das Aktivieren von TraceVerbosity 5 kann das Protokoll erheblich vergrößern, abhängig von der Auslastung des Gateways. Wenn Sie die Protokolle überprüft haben, sollten Sie TraceVerbosity auf 4 festlegen. Es wird nicht empfohlen, diese Einstellung langfristig aktiviert zu lassen.

<setting name="TracingVerbosity" serializeAs="String">
    <value>5</value>
</setting>

Aktivitätstypen

Aktivitätstyp Beschreibung
MGEQ Über ADO.NET ausgeführte Abfragen. Hierzu gehören DirectQuery-Datenquellen.
MGEO Über OLEDB ausgeführte Abfragen. Dies schließt SAP HANA und Analysis Services 2016 ein.
MGEM Über das Mashup-Modul ausgeführte Abfragen. Dies wird mit importierten Datasets verwendet, die geplante Aktualisierungen oder Aktualisierungen bei Bedarf verwenden.

Bestimmen der Dauer einer Abfrage

Sie können wie folgt vorgehen, um zu bestimmen, wie lange die Abfrage der Datenquelle gedauert hat.

  1. Öffnen Sie das Gateway-Protokoll.

  2. Suchen Sie nach einem Aktivitätstyp, um die Abfrage zu finden. Ein Beispiel hierfür wäre MGEQ.

  3. Notieren Sie sich die zweite GUID, da dies die Anforderungs-ID ist.

  4. Suchen Sie weiter nach MGEQ, bis Sie den Eintrag „FireActivityCompletedSuccessfullyEvent“ mit der Dauer gefunden haben. Sie können überprüfen, ob der Eintrag die gleiche Anforderungs-ID aufweist. Die Dauer wird in Millisekunden angegeben.

    DM.EnterpriseGateway Verbose: 0 : 2016-09-26T23:08:56.7940067Z DM.EnterpriseGateway    baf40f21-2eb4-4af1-9c59-0950ef11ec4a    5f99f566-106d-c8ac-c864-c0808c41a606    MGEQ    21f96cc4-7496-bfdd-748c-b4915cb4b70c    B8DFCF12 [DM.Pipeline.Common.TracingTelemetryService] Event: FireActivityCompletedSuccessfullyEvent (duration=5004)
    
    Hinweis:

    FireActivityCompletedSuccessfullyEvent ist ein ausführlicher Eintrag. Dieser Eintrag wird nur protokolliert, wenn TraceVerbosity auf Ebene 5 festgelegt wurde.

Tools zur Problembehandlung

Zusammenstellen von Protokollen über den Gateway-Konfigurator

Sie können verschiedene Protokolle für das Gateway erfassen. Beginnen Sie immer mit den Protokollen!

Installationsprotokolle

%localappdata%\Temp\On-premises_data_gateway_*.log

Konfigurationsprotokolle

%localappdata%\Microsoft\on-premises data gateway\GatewayConfigurator*.log

Dienstprotokolle des lokalen Datengateways

C:\Users\PBIEgwService\AppData\Local\Microsoft\on-premises data gateway\Gateway*.log

Ereignisprotokolle

Die Ereignisprotokolle von On-premises data gateway service befinden sich unter Application and Services Logs (Anwendungs- und Dienstprotokolle).

on-prem-data-gateway-ereignis-protokolle

Ablaufverfolgung mit Fiddler

Fiddler ist ein kostenloses Tool von Telerik, mit dem HTTP-Verkehr überwacht werden kann. Sie können den Datenaustausch zwischen dem Power BI-Dienst und dem Clientcomputer verfolgen. So können Sie Fehler und ähnliche Informationen anzeigen.

Aktualisieren des Verlaufs

Beim Verwenden des Gateways für die planmäßige Aktualisierung können Sie über die Option Verlauf aktualisieren erkennen, welche Fehler aufgetreten sind, und nützliche Daten für eine Supportanfrage abrufen. Sie können sowohl geplante Aktualisierungen als auch Aktualisierungen nach Bedarf anzeigen. Hier ist beschrieben, wie Sie zur Option Verlauf aktualisierengelangen.

  1. Wählen Sie im Power BI-Navigationsbereich in Datasets für das Dataset > Menü öffnen >Aktualisierung planen aus.

  2. Wählen Sie unter Einstellungen für... >Aktualisierung planen die Option Verlauf aktualisieren aus.

Weitere Informationen zur Problembehandlung bei Aktualisierungsszenarien finden Sie im Artikel Problembehandlung bei Aktualisierungsszenarien.

Siehe auch

Konfigurieren von Proxyeinstellungen für Power BI-Gateways
Lokales Datengateway
Ausführliche Informationen zum lokalen Datengateway
Verwalten Ihrer Datenquelle – Analysis Services
Verwalten Ihrer Datenquelle –SAP HANA
Verwalten Ihrer Datenquelle – SQL Server
Verwalten der Datenquelle – Import/Geplante Aktualisierung
Weitere Fragen? Wenden Sie sich an die Power BI-Community