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 finden Sie Informationen zu den letzten 50 Abfragen, die Looker an Ihre Datenbank gesendet hat. 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.
Abgeschlossen: Hier werden die 500 letzten Abfragen angezeigt.
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.
Cache: Looker hat die Ergebnisse aus dem Cache zurückgegeben, anstatt eine doppelte Abfrage in der Datenbank auszuführen.
Abgeschlossen: Die Abfrage wurde erfolgreich abgeschlossen.
Fehler: Die Abfrage konnte nicht abgeschlossen werden, 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 dem 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 Abfrage wartet auf ihre Ausführung, weil bereits zu viele Abfragen ausgeführt werden. Abfragen können in der Verbindungseinrichtung oder in der Datenbank von Looker begrenzt werden.
Wird ausgeführt: Die Abfrage wird gerade ausgeführt.
Unbekannt: In Looker konnte nicht ermittelt werden, 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 Looker eine persistente abgeleitete Tabelle erstellt oder ein unbekannter Nutzer auf einen öffentlichen Look zugreift.
Quelle
Die Quelle der Abfrage in Looker, z. B. die Explore-Seite oder der SQL Runner. Nach Möglichkeit wird auch ein Link zum gespeicherten Look oder die Abfrage-ID zusammen mit dem Namen des Modells und des Explores angezeigt. Einige Abfragen enthalten keine zusätzlichen Informationen, z. B. solche, die im SQL Runner ausgeführt werden. Abfragen, die über die Open SQL Interface gesendet werden, haben den Wert Sql_interface für Source.
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, der Datentransfer zwischen Datenbank und Abfrage sowie die Ausführung der Abfrage in der Datenbank.Wenn die Abfrage ausgeführt wird, wird in der Laufzeit angezeigt, wie lange die Abfrage schon läuft. Bei zuvor ausgeführten Abfragen wird in der Laufzeit auch eine Schätzung der Zeit angezeigt, die die Abfrage noch in Anspruch nimmt. Die Schätzung basiert auf der Dauer der letzten Ausführung der Abfrage und wird in etwa so lauten: „etwa 2 Sekunden“.
Wenn Sie rechts neben einer Abfrage auf die Schaltfläche Details klicken, werden weitere Informationen zu dieser Abfrage angezeigt. Das Menü Abfragedetails enthält die folgenden Optionen:
Einen Abschnitt Info mit Details zur Abfrage (siehe folgende Tabelle).
Einen Abschnitt SQL mit dem Roh-SQL-Code, der für die Datenbank ausgeführt wurde. Kontextkommentare werden nicht in den Abfragedetails angezeigt. Damit Kommentare das Abfrage-Caching nicht beeinträchtigen, fügt Looker die Kontextkommentare den ausgehenden SQL-Befehlen hinzu, kurz bevor der SQL-Code an die Datenbank gesendet wird.
Ein Abschnitt SQL-Schnittstellenabfrage, der angezeigt wird, wenn eine Abfrage über die Open SQL-Schnittstelle gesendet wurde. In diesem Abschnitt wird die SQL-Abfrage angezeigt, die vom externen BI-Tool an Looker gesendet wurde. Sie kann bei der Fehlerbehebung und der Reproduktion von Problemen helfen.
Einen Link In SQL Runner öffnen, über den 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 keine 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 Looker eine persistente abgeleitete Tabelle erstellt oder ein unbekannter Nutzer auf einen öffentlichen Look zugreift.
Quelle
Die Quelle der Abfrage in Looker, z. B. die Seite Explore oder der SQL Runner. Nach Möglichkeit 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 Uhrzeit, zu der die Abfrage abgeschlossen wurde, in Ihrer Anwendungszeitzone.
Laufzeit
Die Dauer der Abfrage.
Abfragen 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 Abbrechen 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
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 und Warteschlangen für Abfragen
Looker beendet Abfragen, die zu lange in der Warteschlange gewartet haben. Dieser Vorgang wird als Zeitüberschreitung bezeichnet. Für Ihre Abfrage können mehrere Zeitüberschreitungen gelten:
Zeitüberschreitung des Verbindungspools und maximale Anzahl gleichzeitiger Abfragen: Um eine Überlastung Ihrer Datenbank durch gleichzeitige Abfragen zu verhindern, hält Looker überzählige Abfragen in der Looker-Abfragewarteschlange und beendet Abfragen, die zu lange in der Warteschlange bleiben. Standardmäßig sind pro Verbindung maximal 75 gleichzeitige Abfragen zulässig. Zusätzliche Abfragen, die das Verbindungslimit ü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.
Limit und Zeitüberschreitung für Abfragen pro Nutzer: Damit kein einzelner Nutzer die Looker-Abfragewarteschlange füllt, hat jeder Nutzer eine maximale Anzahl zulässiger gleichzeitiger Abfragen und eine entsprechende Warteschlangenzeitüberschreitung. Standardmäßig kann jeder Nutzer maximal 15 gleichzeitige Abfragen ausführen. Für Abfragen, die aufgrund dieses Limits in die Warteschlange gestellt werden, beträgt die Zeitüberschreitung 600 Sekunden. Diese Einstellungen gelten sowohl für Nutzer, die sich über den regulären Authentifizierungsprozess in Looker anmelden, als auch für Nutzer, die sich mit API-Nutzerdaten anmelden. Wenn Sie diese Standardeinstellungen ändern möchten, konfigurieren Sie die Einstellungen für die 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 Startoptionen für --per-user-query-limit und --per-user-query-timeout konfigurieren.
Limit und Zeitüberschreitung für Planerabfragen: Um eine Überlastung des Looker-Planerprozesses zu vermeiden, kann eine Looker-Instanz maximal 10 gleichzeitige geplante Abfragen ausführen. Die Zeitüberschreitung 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 Startoptionen für --scheduler-query-limit und --scheduler-query-timeout konfigurieren.
Limit und Zeitlimit für Renderer-Abfragen: Um eine Überlastung des Looker-Renderer-Prozesses zu vermeiden, kann eine Looker-Instanz maximal zwei gleichzeitige bildbasierte Downloads wie PDF- und PNG-Formate rendern. Wenn Ihre Looker-Instanz vom Kunden gehostet wird, können Sie diese Standardeinstellung ändern, indem Sie die --concurrent-render-jobsStartoption konfigurieren.
Webhook-Zeitüberschreitung: Looker versucht maximal 30 Minuten lang, die Daten an einen Webhook zu senden. Wenn Looker innerhalb von 30 Minuten nicht mit dem Webhook-Ziel kommunizieren kann, kommt es zu einer Zeitüberschreitung. Dieses Zeitlimit kann nicht konfiguriert werden.
Proxy-Zeitüberschreitung: Von Kunden gehostete Instanzen verwenden häufig Proxys mit einem Standardzeitlimit von 60 Sekunden. Wir empfehlen, diese Zeitüberschreitung auf 60 Minuten zu erhöhen. Weitere Informationen finden Sie im Looker-Communitybeitrag Looker hinter einem Proxyserver oder Load Balancer ausführen.
Datenbankzeitüberschreitung: Die meisten Datenbanken haben Regeln für die Warteschlangen- und Zeitüberschreitung, die unabhängig von den Warteschlangen und Zeitüberschreitungen von Looker sind. Eine Abfrage kann beispielsweise die Looker-Warteschlange verlassen haben, aber noch in der Warteschlange Ihrer Datenbank sein. Weitere Informationen zum Anpassen der Zeitüberschreitungen für Datenbankabfragen finden Sie in der Dokumentation 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-08-25 (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."]]
