Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
La page Requêtes de la section Base de données du menu Admin liste des informations sur les 50 dernières requêtes que Looker a envoyées à votre base de données. Pour en savoir plus sur les requêtes plus anciennes que les 50 dernières, consultez la section Utilisation de Looker.
Récentes : affiche les requêtes exécutées au cours de la dernière heure. Dans cet onglet, les administrateurs Looker peuvent annuler les requêtes en cours d'exécution.
Complètes : affiche les 500 requêtes les plus récentes.
Si vous n'avez pas activé la fonctionnalité expérimentale Administration avancée des requêtes, la page Requêtes liste les 50 dernières requêtes sur une seule page.
En file d'attente : la requête est en attente d'exécution, car trop de requêtes sont déjà en cours (Looker peut limiter les requêtes dans la configuration de votre connexion ou dans votre base de données).
En cours d'exécution : la requête est en cours d'exécution.
Inconnu : Looker n'a pas pu déterminer ce qui s'est passé avec cette requête.
Connexion
La connexion Looker sous laquelle cette requête a été exécutée.
Utilisateur
Utilisateur qui a exécuté cette requête, si cela peut être déterminé. Certaines requêtes ne sont pas exécutées par un utilisateur spécifique, par exemple lorsque Looker crée une table dérivée persistante ou lorsqu'un utilisateur inconnu accède à un look public.
Source
Source de la requête dans Looker, comme la page "Explorer" ou SQL Runner. Si possible, un lien vers la requête enregistrée ou l'ID de requête, ainsi que le nom du modèle et de l'exploration, sont également affichés. Certaines requêtes ne comportent pas d'informations supplémentaires, comme celles exécutées dans SQL Runner. Les requêtes émises à partir de l'interface Open SQL ont une valeur Source de Sql_interface.
Environnement d'exécution
Temps nécessaire à l'exécution de la requête. Cela inclut la construction de la requête, le temps passé dans la file d'attente, le transit vers et depuis la base de données, et l'exécution de la requête par la base de données.Si la requête est en cours d'exécution, la durée d'exécution indique depuis combien de temps elle est en cours d'exécution. Pour les requêtes exécutées précédemment, la durée d'exécution indique également une estimation du temps nécessaire à l'exécution de la requête. L'estimation est basée sur la durée de la dernière exécution de la requête et indique par exemple "environ 2 s".
Bouton "Détails"
Pour en savoir plus, consultez la sous-section Bouton "Détails" sur cette page.
Bouton "Détails"
Cliquez sur le bouton Détails à droite d'une requête pour obtenir des informations supplémentaires à son sujet. Le menu Détails de la requête inclut les éléments suivants :
Une section Infos qui inclut des détails sur la requête (voir le tableau ci-dessous).
Une section SQL qui affiche le code SQL brut exécuté sur la base de données. Les commentaires contextuels n'apparaissent pas dans les informations Détails de la requête. Pour éviter que les commentaires n'affectent la mise en cache des requêtes, Looker ajoute les commentaires contextuels aux commandes SQL sortantes juste avant que le code SQL ne soit envoyé à la base de données.
Une section Requête d'interface SQL s'affiche lorsqu'une requête a été émise via l'interface SQL ouverte. Cette section affiche la requête SQL qui a été envoyée à Looker depuis l'outil de BI externe. Elle peut vous aider à résoudre les problèmes et à les reproduire.
Un lien Ouvrir dans l'exécuteur SQL qui ouvre la requête dans l'exécuteur SQL.
La section Infos inclut les informations suivantes :
Si la requête contient une PDT, le commentaire de génération de la PDT s'affiche dans ce champ. Si la requête ne contient pas de PDT, le champ n'apparaît pas.
Connexion
La connexion Looker sous laquelle cette requête a été exécutée.
Utilisateur
Utilisateur qui a exécuté cette requête, si cela peut être déterminé. Certaines requêtes ne sont pas exécutées par un utilisateur spécifique, par exemple lorsque Looker crée une table dérivée persistante ou lorsqu'un utilisateur inconnu accède à un look public.
Source
Source de la requête dans Looker, comme la page Explorer ou SQL Runner. Si possible, des informations supplémentaires s'affichent, comme un lien vers la présentation enregistrée, l'ID de requête, le nom du modèle, le nom de l'exploration ou les champs sélectionnés.
Lorsque vous fermez l'onglet du navigateur dans lequel une requête est en cours d'exécution, Looker l'arrête automatiquement. Les administrateurs Looker peuvent également arrêter une requête en cours d'exécution depuis la page Requêtes. (Les utilisateurs disposant de l'autorisation see_queries peuvent consulter la page Requêtes, mais seuls les administrateurs Looker peuvent arrêter une requête en cours d'exécution.) Pour toute requête en cours d'exécution, un bouton Arrêter s'affiche à droite. Cliquez sur Arrêter pour arrêter la requête.
Pour que Looker puisse arrêter les requêtes, votre dialecte de base de données doit prendre en charge cette fonctionnalité. La liste suivante répertorie les dialectes prenant en charge l'arrêt des requêtes dans la dernière version de Looker :
Dialecte
Compatibilité
Actian Avalanche
Oui
Amazon Athena
Oui
Amazon Aurora MySQL
Oui
Amazon Redshift
Oui
Amazon Redshift 2.1+
Oui
Amazon Redshift Serverless 2.1+
Oui
Apache Druid
Non
Apache Druid 0.13+
Non
Apache Druid 0.18+
Non
Apache Hive 2.3+
Oui
Apache Hive 3.1.2+
Oui
Apache Spark 3+
Oui
ClickHouse
Oui
Cloudera Impala 3.1+
Oui
Cloudera Impala 3.1+ with Native Driver
Oui
Cloudera Impala with Native Driver
Oui
DataVirtuality
Oui
Databricks
Oui
Denodo 7
Oui
Denodo 8 & 9
Oui
Dremio
Oui
Dremio 11+
Oui
Exasol
Oui
Firebolt
Oui
Google BigQuery Legacy SQL
Oui
Google BigQuery Standard SQL
Oui
Google Cloud PostgreSQL
Oui
Google Cloud SQL
Oui
Google Spanner
Oui
Greenplum
Oui
HyperSQL
Non
IBM Netezza
Oui
MariaDB
Oui
Microsoft Azure PostgreSQL
Oui
Microsoft Azure SQL Database
Oui
Microsoft Azure Synapse Analytics
Oui
Microsoft SQL Server 2008+
Oui
Microsoft SQL Server 2012+
Oui
Microsoft SQL Server 2016
Oui
Microsoft SQL Server 2017+
Oui
MongoBI
Oui
MySQL
Oui
MySQL 8.0.12+
Oui
Oracle
Oui
Oracle ADWC
Oui
PostgreSQL 9.5+
Oui
PostgreSQL pre-9.5
Oui
PrestoDB
Oui
PrestoSQL
Oui
SAP HANA
Oui
SAP HANA 2+
Oui
SingleStore
Oui
SingleStore 7+
Oui
Snowflake
Oui
Teradata
Oui
Trino
Oui
Vector
Oui
Vertica
Oui
Délai avant expiration des requêtes et mise en file d'attente
Looker arrête les requêtes qui sont en file d'attente depuis trop longtemps. Cette opération est appelée délai d'inactivité. Plusieurs délais d'expiration peuvent s'appliquer à votre requête :
Délai avant expiration du pool de connexions et nombre maximal de requêtes simultanées : pour éviter de surcharger votre base de données avec des requêtes simultanées, Looker conserve les requêtes simultanées excédentaires dans la file d'attente des requêtes Looker et arrête les requêtes qui y restent trop longtemps. Par défaut, 75 requêtes simultanées maximum sont autorisées par connexion. Les requêtes supplémentaires au-delà de la limite de connexion expireront après 0 seconde. Pour modifier ces valeurs par défaut, configurez les paramètres Nombre maximal de connexions, Nombre maximal de requêtes simultanées pour cette connexion et Délai avant expiration du pool de connexions sur la page Paramètres de connexion d'une connexion.
Limite de requêtes et délai d'expiration par utilisateur : pour éviter qu'un seul utilisateur ne remplisse la file d'attente des requêtes Looker, chaque utilisateur est soumis à un nombre maximal de requêtes simultanées autorisées et à un délai d'expiration de la file d'attente correspondant. Par défaut, chaque utilisateur peut exécuter un maximum de 15 requêtes simultanées. Le délai avant expiration est de 600 secondes pour les requêtes mises en file d'attente en raison de cette limite. Ces paramètres s'appliquent à la fois aux utilisateurs qui se connectent à Looker à l'aide de la procédure d'authentification habituelle et à ceux qui se connectent à l'aide d'identifiants d'utilisateur de l'API. Pour modifier ces valeurs par défaut, configurez les paramètres Nombre maximal de requêtes simultanées par utilisateur pour cette connexion sur la page Paramètres de connexion d'une connexion. Si votre instance Looker est hébergée par le client, vous pouvez modifier ces valeurs par défaut en configurant les options de démarrage--per-user-query-limit et --per-user-query-timeout.
Limite de requêtes et délai d'expiration du planificateur : pour éviter de surcharger le processus du planificateur Looker, une instance Looker peut exécuter un maximum de 10 requêtes programmées simultanément. Le délai d'expiration des requêtes dans la file d'attente du planificateur est de 1 200 secondes. Si votre instance Looker est hébergée par le client, vous pouvez modifier ces valeurs par défaut en configurant les options de démarrage--scheduler-query-limit et --scheduler-query-timeout.
Limite et délai avant expiration des requêtes du moteur de rendu : pour éviter de surcharger le processus du moteur de rendu Looker, une instance Looker peut générer un maximum de deux téléchargements simultanés basés sur des images, tels que les formats PDF et PNG. Si votre instance Looker est hébergée par le client, vous pouvez modifier cette valeur par défaut en configurant l'option de démarrage--concurrent-render-jobs.
Délai avant expiration du webhook : Looker tente d'envoyer des données à un webhook pendant 30 minutes au maximum. Si Looker ne parvient pas à communiquer avec la destination du webhook au bout de 30 minutes, la requête expire. Ce délai avant expiration n'est pas configurable.
Délai avant expiration du proxy : les instances hébergées par le client utilisent souvent des proxys avec un délai avant expiration par défaut de 60 secondes. Nous vous recommandons de porter ce délai à 60 minutes. Pour en savoir plus, consultez le post de la communauté Looker Exécuter Looker derrière un serveur proxy ou un équilibreur de charge.
Délai d'expiration de la base de données : la plupart des bases de données ont des règles de mise en file d'attente et de délai d'expiration qui sont indépendantes de celles de Looker. Par exemple, une requête peut avoir quitté la file d'attente Looker, mais elle peut toujours être en file d'attente dans votre base de données. Pour en savoir plus sur la personnalisation des délais d'expiration des requêtes de base de données, consultez la documentation de votre base de données.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (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."]]
