Auf der Seite Abfragen im Bereich Datenbank des Menüs Verwaltung werden Informationen zu den letzten 50 Abfragen aufgeführt, die von Looker an Ihre Datenbank gesendet wurden. Informationen zu Abfragen, die älter als die letzten 50 Abfragen sind, finden Sie in Looker im Bereich Nutzung.
Grundlegende Informationen zur Abfrage
| Spalte | Definition |
|---|---|
| Zeit | Die Startzeit der Abfrage, die in der Zeitzone Ihrer Anwendung angezeigt wird. |
| Status | Der Status der Anfrage, der Folgendes umfassen kann:
|
| Verbindung | Die Looker-Verbindung, unter der diese Abfrage ausgeführt wurde. |
| Nutzer | Der Nutzer, der diese Abfrage ausgeführt hat, sofern dies ermittelt werden kann. Einige Abfragen werden nicht von einem bestimmten Nutzer ausgeführt, z. B. wenn in Looker eine persistente abgeleitete Tabelle erstellt wird oder ein unbekannter Nutzer auf ein öffentliches Look zugreift. |
| Quelle | Die Quelle der Abfrage in Looker, z. B. die Seite „Explore“ oder „SQL-Runner“. Wenn möglich, wird auch ein Link zum gespeicherten Look oder die Abfrage-ID zusammen mit dem Namen des Modells und des Explores angezeigt. Für einige Abfragen sind keine zusätzlichen Informationen verfügbar, z. B. für Abfragen, die in SQL Runner ausgeführt werden. Abfragen, die über die Open SQL-Schnittstelle ausgegeben werden, haben den Source-Wert Sql_interface. |
| Laufzeit | Die Zeit, die für die Ausführung der Abfrage benötigt wurde. Dazu gehören die Erstellung der Abfrage, die Zeit, die die Abfrage in der Warteschlange verbracht hat, die Übertragung zur und von der Datenbank sowie die Ausführung der Abfrage in der Datenbank.Wenn die Abfrage ausgeführt wird, wird die Laufzeit angezeigt. Bei zuvor ausgeführten Abfragen wird auch eine Schätzung der Zeit angezeigt, die für die Ausführung der Abfrage benötigt wird. Die Schätzung basiert auf der Dauer der letzten Ausführung der Abfrage und lautet beispielsweise „ungefähr 2 Sekunden“. |
| Schaltfläche „Details“ | Weitere Informationen finden Sie auf dieser Seite im Unterabschnitt Schaltfläche „Details“. |
Schaltfläche „Details“
Wenn Sie rechts neben einer Abfrage auf die Schaltfläche Details klicken, werden zusätzliche Informationen zu dieser Abfrage angezeigt. Das Menü Abfragedetails enthält Folgendes:
- Ein Abschnitt Info mit Details zur Abfrage (siehe Tabelle unten).
- Ein SQL-Abschnitt mit dem Roh-SQL, das für die Datenbank ausgeführt wurde. Kontextkommentare werden nicht in den Abfragedetails angezeigt. Damit sich Kommentare nicht auf das Zwischenspeichern von Abfragen auswirken, fügt Looker die Kontextkommentare den ausgehenden SQL-Befehlen direkt vor dem Senden des SQL-Codes an die Datenbank hinzu.
- Ein Bereich SQL Interface query (SQL-Schnittstellenabfrage), der angezeigt wird, wenn eine Abfrage über die Open SQL Interface (Offene SQL-Schnittstelle) gesendet wurde. In diesem Abschnitt wird die SQL-Abfrage angezeigt, die vom externen BI-Tool an Looker gesendet wurde. Das kann bei der Fehlerbehebung und Reproduktion von Problemen hilfreich sein.
- Ein Link In SQL-Runner öffnen, mit dem die Abfrage in SQL-Runner geöffnet wird.
Der Bereich Informationen enthält die folgenden Informationen:
| Bereich | Definition |
|---|---|
| Verlaufs-ID | Die Verlaufs-ID der Abfrage, falls verfügbar. |
| Status | Der Status der Abfrage, wie in der Tabelle mit grundlegenden Abfrageinformationen beschrieben. |
| Nachricht | Wenn die Abfrage eine PDT enthält, wird in diesem Feld der Kommentar zur PDT-Generierung angezeigt. Wenn die Abfrage keinen PDT enthält, wird das Feld nicht angezeigt. |
| Verbindung | Die Looker-Verbindung, unter der diese Abfrage ausgeführt wurde. |
| Nutzer | Der Nutzer, der diese Abfrage ausgeführt hat, sofern dies ermittelt werden kann. Einige Abfragen werden nicht von einem bestimmten Nutzer ausgeführt, z. B. wenn in Looker eine persistente abgeleitete Tabelle erstellt wird oder ein unbekannter Nutzer auf einen öffentlichen Look zugreift. |
| Quelle | Die Quelle der Abfrage in Looker, z. B. die Seite Explore oder SQL Runner. Falls möglich, werden zusätzliche Informationen angezeigt, z. B. ein Link zum gespeicherten Look, die Abfrage-ID, der Modellname, der Explore-Name oder die ausgewählten Felder. |
| Beginn | Die Startzeit der Abfrage, die in der Zeitzone Ihrer Anwendung angezeigt wird. |
| Ende | Die Endzeit der Abfrage, die in Ihrer Anwendungszeitzone angezeigt wird. |
| Laufzeit | Die Zeit, die für die Ausführung der Abfrage benötigt wurde. |
Abfrageeabruch
Bei Dialekten, die das Beenden von Abfragen unterstützen, kann Looker eine laufende Abfrage auf zwei Arten beenden:
- Looker beendet eine Abfrage automatisch, wenn der Nutzer den Browser-Tab schließt, auf dem die Abfrage ausgeführt wird.
- Looker-Administratoren können eine laufende Abfrage auf der Administratorseite Abfragen beenden, indem sie für die Abfrage auf die Schaltfläche Beenden klicken. Nutzer mit der Berechtigung
see_querieskönnen die Seite Abfragen aufrufen, aber nur Looker-Administratoren können eine laufende Abfrage beenden.
Damit Looker Abfragen beenden kann, entweder durch Schließen des Browsertabs, in dem eine Abfrage ausgeführt wird, oder durch Beenden der Abfrage auf der Seite Abfragen, muss Ihr Datenbankdialekt das Beenden von Abfragen unterstützen. In der folgenden Tabelle ist zu sehen, welche Dialekte das Beenden von Abfragen in der aktuellen Version von Looker unterstützen:
| Dialekt | Unterstützt? |
|---|---|
| Actian Avalanche | Ja |
| Amazon Athena | Ja |
| Amazon Aurora MySQL | Ja |
| Amazon Redshift | Ja |
| Amazon Redshift 2.1+ | Ja |
| Amazon Redshift Serverless 2.1+ | Ja |
| Apache Druid | Nein |
| Apache Druid 0.13+ | Nein |
| Apache Druid 0.18+ | Nein |
| Apache Hive 2.3+ | Ja |
| Apache Hive 3.1.2+ | Ja |
| Apache Spark 3+ | Ja |
| ClickHouse | Ja |
| Cloudera Impala 3.1+ | Ja |
| Cloudera Impala 3.1+ with Native Driver | Ja |
| Cloudera Impala with Native Driver | Ja |
| DataVirtuality | Ja |
| Databricks | Ja |
| Denodo 7 | Ja |
| Denodo 8 & 9 | Ja |
| Dremio | Ja |
| Dremio 11+ | Ja |
| Exasol | Ja |
| Google BigQuery Legacy SQL | Ja |
| Google BigQuery Standard SQL | Ja |
| Google Cloud PostgreSQL | Ja |
| Google Cloud SQL | Nein |
| Google Spanner | Ja |
| Greenplum | Ja |
| HyperSQL | Nein |
| IBM Netezza | Ja |
| MariaDB | Ja |
| Microsoft Azure PostgreSQL | Ja |
| Microsoft Azure SQL Database | Ja |
| Microsoft Azure Synapse Analytics | Ja |
| Microsoft SQL Server 2008+ | Ja |
| Microsoft SQL Server 2012+ | Ja |
| Microsoft SQL Server 2016 | Ja |
| Microsoft SQL Server 2017+ | Ja |
| MongoBI | Ja |
| MySQL | Ja |
| MySQL 8.0.12+ | Ja |
| Oracle | Ja |
| Oracle ADWC | Ja |
| PostgreSQL 9.5+ | Ja |
| PostgreSQL pre-9.5 | Ja |
| PrestoDB | Ja |
| PrestoSQL | Ja |
| SAP HANA | Ja |
| SAP HANA 2+ | Ja |
| SingleStore | Ja |
| SingleStore 7+ | Ja |
| Snowflake | Ja |
| Teradata | Ja |
| Trino | Ja |
| Vector | Ja |
| Vertica | Ja |
Zeitüberschreitungen bei Abfragen und Warteschlangen
Looker beendet Abfragen, die zu lange in der Warteschlange gewartet haben. Dieser Vorgang wird als Zeitüberschreitung bezeichnet. Für Ihre Anfrage können mehrere Zeitüberschreitungen gelten:
Zeitüberschreitung des Verbindungspools und maximale Anzahl gleichzeitiger Abfragen: Damit Ihre Datenbank nicht durch gleichzeitige Abfragen überlastet wird, werden überschüssige gleichzeitige Abfragen in der Looker-Abfragewarteschlange gespeichert. Abfragen, die zu lange in der Warteschlange verbleiben, werden beendet. Standardmäßig sind maximal 75 gleichzeitige Abfragen pro Verbindung zulässig. Zusätzliche Abfragen, die das Verbindungs-Limit überschreiten, führen nach 0 Sekunden zu einer Zeitüberschreitung. Wenn Sie diese Standardwerte ändern möchten, konfigurieren Sie die Einstellungen Maximale Anzahl von Verbindungen, Maximale Anzahl gleichzeitiger Abfragen für diese Verbindung und Zeitlimit für Verbindungspool auf der Seite Verbindungseinstellungen einer Verbindung.
Abfragelimit und ‑zeitüberschreitung pro Nutzer: Damit nicht ein einzelner Nutzer die Looker-Abfragewarteschlange füllt, hat jeder Nutzer eine maximale Anzahl zulässiger gleichzeitiger Abfragen und eine entsprechende Zeitüberschreitung für Abfragen, die aufgrund des Limits für gleichzeitige Abfragen in die Warteschlange gestellt werden. Das Limit pro Nutzer gilt sowohl für Nutzer, die sich über den regulären Authentifizierungsprozess bei Looker anmelden, als auch für Nutzer, die sich mit API-Nutzeranmeldedaten anmelden. Es gibt zwei Möglichkeiten, die maximale Anzahl gleichzeitiger Abfragen pro Nutzer für Verbindungen in Ihrer Looker-Instanz zu definieren:
- Die Startoption
per-user-query-limit. Dies ist eine instanzweite Einstellung, mit der der Standard für Verbindungen in Ihrer Instanz festgelegt wird. Mit der Startoptionper-user-query-limitwird die Anzahl der gleichzeitigen Abfragen pro Nutzer, pro Verbindung und pro Knoten in der Looker-Instanz begrenzt. Das Standardmaximum von 15 gleichzeitigen Abfragen pro Nutzer gilt für jede gültige Verbindung und, wenn Ihre Looker-Instanz geclustert ist, für jeden Knoten im Cluster. Standardmäßig kann jeder Nutzer maximal 15 gleichzeitige Abfragen pro Verbindung und Knoten mit einem Zeitlimit von 600 Sekunden ausführen. Wenn Sie beispielsweise einen Cluster mit 5 Knoten und einemper-user-query-limitvon 15 haben, sind für diese Verbindung auf jedem Knoten 15 gleichzeitige Abfragen pro Nutzer möglich, also insgesamt 75 Abfragen auf allen Knoten (15 × 5 = 75).
Sie können das Abfragelimit pro Nutzer für eine Verbindung ändern, indem Sie auf der Seite Verbindungseinstellungen der Verbindung die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung verwenden. Wenn Ihre Looker-Instanz vom Kunden gehostet wird, können Sie die standardmäßige maximale Anzahl gleichzeitiger Abfragen pro Nutzer ändern, indem Sie die Startoption
--per-user-query-limitkonfigurieren. Das Warteschlangen-Zeitlimit können Sie mit der Startoption--per-user-query-timeoutkonfigurieren.- Die Option Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung in den Verbindungseinstellungen für eine Verbindung. Die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung hat den Standardwert 25 und gilt pro Nutzer und pro Verbindung, aber nicht pro Knoten. Wenn Sie beispielsweise einen Cluster mit 5 Knoten haben und diesen Wert auf 15 festlegen, sind für jede Verbindung auf jedem Knoten 3 gleichzeitige Abfragen pro Nutzer zulässig (15 / 5 = 3). Insgesamt sind also 15 Abfragen über alle Knoten hinweg möglich. Wenn für eine Verbindung ein Wert für die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung angegeben ist, wird der Wert Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung für die Verbindung durch die
per-user-query-limit-Startoption überschrieben.
- Die Startoption
Limit für Planerabfragen und Zeitüberschreitung: Um eine Überlastung des Looker-Planerprozesses zu verhindern, kann auf einer Looker-Instanz maximal 10 gleichzeitige geplante Abfragen ausgeführt werden. Das Zeitlimit für Abfragen in der Planerwarteschlange beträgt 1.200 Sekunden. Wenn Ihre Looker-Instanz vom Kunden gehostet wird, können Sie diese Standardeinstellungen ändern, indem Sie die
--scheduler-query-limit- und--scheduler-query-timeout-Startoptionen konfigurieren.Limit für Renderer-Abfragen und Zeitüberschreitung: Um eine Überlastung des Looker-Renderer-Prozesses zu verhindern, kann eine Looker-Instanz maximal zwei gleichzeitige bildbasierte Downloads rendern, z. B. im PDF- und PNG-Format. Wenn Ihre Looker-Instanz vom Kunden gehostet wird, können Sie diese Standardeinstellung ändern, indem Sie die
--concurrent-render-jobs-Startoption konfigurieren.
Proxy-Zeitlimit: Bei vom Kunden gehosteten Instanzen werden häufig Proxys mit einem Standardzeitlimit von 60 Sekunden verwendet. Wir empfehlen, dieses Zeitlimit auf 60 Minuten zu erhöhen. Weitere Informationen finden Sie im Looker Community-Beitrag Running Looker behind a proxy server or load balancer.
Datenbank-Zeitüberschreitung: Die meisten Datenbanken haben Regeln für die Warteschlange und Zeitüberschreitungen, die unabhängig von den Warteschlangen und Zeitüberschreitungen von Looker sind. Eine Abfrage wurde beispielsweise aus der Looker-Warteschlange entfernt, kann aber weiterhin in Ihrer Datenbank in der Warteschlange stehen. Weitere Informationen zum Anpassen von Zeitüberschreitungen für Datenbankabfragen finden Sie in der Dokumentation zu Ihrer Datenbank.