Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
Wenn Sie die Labs-Funktion Erweiterte Abfrageverwaltung aktiviert haben, werden auf der Seite Abfragen die folgenden Tabs angezeigt:
Letzte: Hier werden Abfragen angezeigt, die in der letzten Stunde ausgeführt wurden. Auf diesem Tab können Looker-Administratoren laufende Abfragen abbrechen.
Vollständig: Zeigt die letzten 500 Abfragen an.
Wenn Sie die Labs-Funktion Erweiterte Abfrageverwaltung nicht aktiviert haben, werden auf der Seite Abfragen die letzten 50 Abfragen auf einer einzigen Seite aufgeführt.
Der Status der Anfrage, der Folgendes umfassen kann:
Cache: Looker hat die Ergebnisse aus dem Cache zurückgegeben, anstatt eine doppelte Abfrage für die Datenbank auszuführen.
Abgeschlossen: Die Abfrage wurde erfolgreich abgeschlossen.
Fehler: Die Anfrage wurde nicht erfolgreich abgeschlossen, da ein Fehler aufgetreten ist. Die Details dazu finden Sie, wenn Sie auf die Schaltfläche „Details“ klicken.
Abgebrochen: Die Abfrage wurde von Looker oder vom Nutzer abgebrochen.
Warten auf PDT: Die Abfrage muss warten, bis eine persistente abgeleitete Tabelle erstellt wurde, bevor sie ausgeführt werden kann.
In der Warteschlange: Die Ausführung der Abfrage wird abgewartet, weil bereits zu viele Abfragen ausgeführt werden. Die Anzahl der Abfragen kann von Looker in Ihrer Verbindungseinrichtung oder von Ihrer Datenbank begrenzt werden.
Wird ausgeführt: Die Abfrage wird gerade ausgeführt.
Unbekannt: Looker konnte nicht ermitteln, was mit dieser Abfrage passiert ist.
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 dauerhafte 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“. 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 Interface 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 in der Laufzeit auch eine Schätzung angezeigt, wie lange die Ausführung der Abfrage dauern wird. Die Schätzung basiert auf der Dauer des letzten Ausführens 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 Abfrage-Caching auswirken, fügt Looker die Kontextkommentare kurz vor dem Senden des SQL-Codes an die Datenbank zu ausgehenden SQL-Befehlen hinzu.
Ein Abschnitt 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:
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.
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 dauerhafte 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.
Die Endzeit der Abfrage, die in Ihrer Anwendungszeitzone angezeigt wird.
Laufzeit
Die Zeit, die für die Ausführung der Abfrage benötigt wurde.
Abfrage beenden
Wenn Sie den Browsertab schließen, in dem eine Abfrage ausgeführt wird, wird die Abfrage in Looker automatisch beendet. Looker-Administratoren können eine laufende Abfrage auch auf der Seite Abfragen beenden. Nutzer mit der Berechtigung see_queries können die Seite Abfragen aufrufen, aber nur Looker-Administratoren können eine laufende Abfrage beenden. Bei jeder Abfrage, die noch ausgeführt wird, wird rechts neben der Abfrage die Schaltfläche Beenden angezeigt. Klicken Sie auf Beenden, um die Abfrage zu beenden.
Damit Looker Abfragen beenden kann, muss Ihr Datenbankdialekt das Beenden von Abfragen unterstützen. In der folgenden Liste ist zu sehen, welche Dialekte das Beenden von Abfragen in der aktuellen Looker-Version 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
Firebolt
Ja
Google BigQuery Legacy SQL
Ja
Google BigQuery Standard SQL
Ja
Google Cloud PostgreSQL
Ja
Google Cloud SQL
Ja
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 waren. 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 die Warteschlange. Standardmäßig kann jeder Nutzer maximal 15 gleichzeitige Abfragen ausführen. Das Zeitlimit für Abfragen, die aufgrund dieses Limits in die Warteschlange gestellt werden, beträgt 600 Sekunden. Diese Einstellungen gelten 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. Wenn Sie diese Standardwerte ändern möchten, konfigurieren Sie die Einstellungen für Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung auf der Seite Verbindungseinstellungen einer Verbindung. Wenn Ihre Looker-Instanz vom Kunden gehostet wird, können Sie diese Standardeinstellungen ändern, indem Sie die --per-user-query-limit- und --per-user-query-timeout-Startoptionen konfigurieren.
Limit für Planerabfragen und Zeitüberschreitung: Um eine Überlastung des Looker-Planerprozesses zu verhindern, können 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 und Zeitlimit für Renderer-Abfragen: Damit der Looker-Renderer-Prozess nicht überlastet wird, 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.
Webhook-Zeitüberschreitung: Looker versucht maximal 30 Minuten lang, die Datenlieferung an einen Webhook durchzuführen. Wenn Looker innerhalb von 30 Minuten nicht mit dem Webhook-Ziel kommunizieren kann, kommt es bei der Abfrage zu einer Zeitüberschreitung. Dieses Zeitlimit kann nicht konfiguriert werden.
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-08 (UTC)."],[],[],null,["# Admin settings - Queries\n\n| **Note:** Looker admins can enable the [**Enhanced Query Admin**](/looker/docs/admin-panel-general-labs#enhanced_query_admin) experimental Labs feature to enhance the **Queries** page. The Labs feature improves performance on the **Queries** page, and it lists 500 paginated queries, rather than 50.\n\nThe **Queries** page in the **Database** section of the **Admin** menu lists information about the last 50 queries that Looker submitted to your database. For information about queries that are older than the most recent 50 queries, see the [**Usage**](/looker/docs/admin-panel-server-usage) section of Looker.\n| **Note:** If you have a permission that provides access to only select pages in the Admin panel, such as [`manage_schedules`](/looker/docs/admin-panel-users-roles#manage_schedules), [`manage_themes`](/looker/docs/admin-panel-users-roles#manage_themes), or [`see_admin`](/looker/docs/admin-panel-users-roles#see_admin), but you don't have the [Admin role](/looker/docs/admin-panel-users-roles#default_roles), the page or pages that are described here may not be visible to you in the Admin panel.\n\nIf you have enabled the [Enhanced Query Admin](/looker/docs/admin-panel-general-labs#enhanced_query_admin) Labs feature, the **Queries** page displays the following tabs:\n\n- **Recent**: Displays queries that were run in the last hour. From this tab, Looker admins can cancel running queries.\n- **Complete**: Displays the most recent 500 queries.\n\nIf you haven't enabled the **Enhanced Query Admin** Labs feature, the **Queries** page lists the last 50 queries on a single page.\n\nBasic query information\n-----------------------\n\nThe Details button\n------------------\n\nClicking the **Details** button to the right of any query will bring up additional information about that query. The **Query Details** menu includes the following:\n\n- An **Info** section that includes details about the query (see the following table).\n- A **SQL** section that shows the raw SQL that was executed against the database. [**Context Comments**](/looker/docs/admin-panel-server-usage#sql_comments) will not appear in the **Query Details** information. To prevent comments from affecting query caching, Looker adds the context comments to outgoing SQL commands right before the SQL is sent to the database.\n- A **SQL Interface query** section that appears when a query has been issued through the [Open SQL Interface](/looker/docs/sql-interface#identifying-sql-interface-queries-in-the-looker-ui). This section displays the SQL query that was sent to Looker from the external BI tool and can aid in troubleshooting and reproducing issues.\n- An **Open in SQL Runner** link that will open the query in [SQL Runner](/looker/docs/sql-runner-basics).\n\nThe **Info** section includes the following information:\n\nQuery killing\n-------------\n\nWhen you close the browser tab in which a query is running, Looker will automatically stop the query. Looker admins can also stop a running query from the **Queries** page. (Users with the [`see_queries` permission](/looker/docs/admin-panel-users-roles#see_queries) can view the **Queries** page, but only Looker admins can stop a running query.) Any query that is still running shows a **Stop** button to the right of the query. Click **Stop** to stop the query.\n\nFor Looker to kill queries, your database dialect must support query killing. The following list shows which dialects support query killing in the latest release of Looker:\n\nQuery timeouts and queueing\n---------------------------\n\nLooker kills queries that have been waiting in queue for too long. This operation is called a *timeout*. Several timeouts may apply to your query:\n\n- **Connection pool timeout and maximum concurrent queries** : To prevent overloading of your database with concurrent queries, Looker holds excess concurrent queries in the Looker query queue, and will kill queries that remain in queue for too long. By default, 75 maximum concurrent queries are allowed per connection. Additional queries beyond the connection limit will be timed out after 0 seconds. To change these defaults, configure the [Max connections](/looker/docs/connecting-to-your-db#max_connections), [**Max concurrent queries for this connection**](/looker/docs/connecting-to-your-db#max-queries), and [**Connection pool timeout**](/looker/docs/connecting-to-your-db#connection_pool_timeout) settings on a connection's [**Connections Settings**](/looker/docs/connecting-to-your-db) page.\n\n- **Per-user query limit and timeout** : To prevent any single user from filling up the Looker query queue, each user has a maximum number of allowed concurrent queries and a corresponding queue timeout. By default, each user can run a maximum of 15 concurrent queries, and the timeout is 600 seconds for queries that are queued because of this limit. These settings apply to both users who log in to Looker using the regular authentication process, and to users who log in using API user credentials. To change these defaults, configure the [Max concurrent queries per user for this connection](/looker/docs/connecting-to-your-db#max-queries-per-user) settings on a connection's [**Connections Settings**](/looker/docs/connecting-to-your-db) page. If your Looker instance is customer-hosted, you can change these defaults by configuring the `--per-user-query-limit` and `--per-user-query-timeout` [startup options](/looker/docs/startup-options).\n\n | **Note:** The default maximum of 15 concurrent queries per user applies to each valid connection and, if your Looker instance is [clustered](/looker/docs/clustering-looker), to each node in the cluster. For example, if a user has access to 2 valid connections, they can run a maximum of 30 concurrent queries, 15 per connection. If the user is on a clustered instance with 2 nodes and has access to 1 valid connection, they can run 30 concurrent queries, 15 per node. If the user has 2 valid connections on a clustered instance with 2 nodes, they can run a maximum of 60 concurrent queries, 15 for each connection on each node.\n- **Scheduler query limit and timeout** : To prevent overloading of the Looker scheduler process, a Looker instance can run a maximum of 10 concurrent scheduled queries, and the timeout for queries in the scheduler queue is 1,200 seconds. If your Looker instance is customer-hosted, you can change these defaults by configuring the `--scheduler-query-limit` and `--scheduler-query-timeout` [startup options](/looker/docs/startup-options).\n\n | **Note:** If your Looker instance is [clustered](/looker/docs/clustering-looker), then each node of the cluster uses its own scheduler queue. Thus, adding nodes to your cluster increases your total amount of allowed concurrent scheduled queries without placing additional burden on the Looker scheduler process.\n- **Renderer query limit and timeout** : To prevent overloading of the Looker renderer process, a Looker instance can render a maximum of 2 concurrent image-based downloads, such as PDF and PNG formats. If your Looker instance is customer-hosted, you can change this default by configuring the `--concurrent-render-jobs` [startup option](/looker/docs/startup-options).\n\n | **Note:** If your Looker instance is [clustered](/looker/docs/clustering-looker), then each node of the cluster uses its own renderer queue. Thus, adding nodes to your cluster increases your total amount of allowed concurrent renderer jobs without placing additional burden on the Looker renderer process.\n\n\u003cbr /\u003e\n\n- **Webhook timeout** : Looker will attempt [data delivery to a webhook](/looker/docs/sharing-and-publishing/scheduling-and-sharing/send-webhook) for a maximum of 30 minutes. If Looker cannot communicate with the webhook destination in 30 minutes, the query will time out. This timeout is not configurable.\n - **Proxy timeout** : Customer-hosted instances often use proxies with a default timeout of 60 seconds. We recommend that this timeout be increased to 60 minutes. See the [Running Looker behind a proxy server or load balancer](https://discuss.google.dev/t/running-looker-behind-a-proxy-server-or-load-balancer/117104) Looker Community post for more information.\n\n - **Database timeout**: Most databases have rules for queueing and timeouts that are independent of Looker's queues and timeouts. For example, a query may have left the Looker queue, but it can still be queued on your database. Check the documentation for your database for more information on customizing database query timeouts."]]
