> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Documentation des instructions SYSTEM
# SYSTEM
export const CloudNotSupportedBadge = () => {
return
Non pris en charge par ClickHouse Cloud
;
};
## SYSTEM RELOAD EMBEDDED DICTIONARIES
Recharge tous les [dictionnaires internes](/fr/reference/statements/create/dictionary).
Par défaut, les dictionnaires internes sont désactivés.
Renvoie toujours `Ok.`, quel que soit le résultat de la mise à jour des dictionnaires internes.
## SYSTEM RELOAD DICTIONARIES
La requête `SYSTEM RELOAD DICTIONARIES` recharge les dictionnaires dont le statut est `LOADED` (voir la colonne `status` de [`system.dictionaries`](/fr/reference/system-tables/dictionaries)), c’est-à-dire les dictionnaires qui ont déjà été chargés avec succès.
Par défaut, les dictionnaires sont chargés de manière différée (voir [dictionaries\_lazy\_load](/fr/reference/settings/server-settings/settings/dictionaries#dictionaries_lazy_load)) ; ainsi, au lieu d’être chargés automatiquement au démarrage, ils sont initialisés lors du premier accès, via la fonction [`dictGet`](/fr/reference/functions/regular-functions/ext-dict-functions#dictGet) ou une instruction `SELECT` sur des tables avec `ENGINE = Dictionary`.
**Syntaxe**
```sql theme={null}
SYSTEM RELOAD DICTIONARIES [ON CLUSTER cluster_name]
```
## SYSTEM RELOAD DICTIONARY
Recharge entièrement un dictionnaire `dictionary_name`, quel que soit son état (LOADED / NOT\_LOADED / FAILED).
Renvoie toujours `Ok.`, quel que soit le résultat de la mise à jour du dictionnaire.
```sql theme={null}
SYSTEM RELOAD DICTIONARY [ON CLUSTER cluster_name] dictionary_name
```
L’état du dictionnaire peut être vérifié en interrogeant la table `system.dictionaries`.
```sql theme={null}
SELECT name, status FROM system.dictionaries;
```
## SYSTEM UNLOAD DICTIONARY
Décharge le dictionnaire `dictionary_name` afin de libérer sa mémoire, si l'état du dictionnaire est `LOADED`.
Le dictionnaire est rechargé à la demande lorsque cela redevient nécessaire.
```sql theme={null}
SYSTEM UNLOAD DICTIONARY dictionary_name
```
L’état du dictionnaire peut être vérifié en interrogeant la table `system.dictionaries`.
```sql theme={null}
SELECT name, status FROM system.dictionaries;
```
## SYSTEM UNLOAD DICTIONARIES
La requête `SYSTEM UNLOAD DICTIONARIES` décharge de la mémoire tous les dictionnaires dont le statut est `LOADED` (voir la colonne `status` de [`system.dictionaries`](/fr/reference/system-tables/dictionaries)), c’est-à-dire les dictionnaires qui ont déjà été chargés avec succès.
```sql theme={null}
SYSTEM UNLOAD DICTIONARIES
```
## SYSTEM RELOAD FUNCTIONS
Recharge toutes les [fonctions définies par l’utilisateur exécutables](/fr/reference/functions/regular-functions/udf#executable-user-defined-functions) enregistrées, ou l’une d’entre elles, à partir d’un fichier de configuration.
**Syntaxe**
```sql theme={null}
SYSTEM RELOAD FUNCTIONS [ON CLUSTER cluster_name]
SYSTEM RELOAD FUNCTION [ON CLUSTER cluster_name] function_name
```
## SYSTEM RELOAD ASYNCHRONOUS METRICS
Recalcule toutes les [métriques asynchrones](/fr/reference/system-tables/asynchronous_metrics). Comme les métriques asynchrones sont mises à jour périodiquement selon le paramètre [asynchronous\_metrics\_update\_period\_s](/fr/reference/settings/server-settings/settings/asynchronous-metrics#asynchronous_metrics_update_period_s), il n’est généralement pas nécessaire de les mettre à jour manuellement à l’aide de cette instruction.
```sql theme={null}
SYSTEM RELOAD ASYNCHRONOUS METRICS [ON CLUSTER cluster_name]
```
## SYSTEM CLEAR|DROP DNS CACHE
Vide le cache DNS interne de ClickHouse. Il est parfois nécessaire (avec d’anciennes versions de ClickHouse) d’utiliser cette commande lors d’une modification de l’infrastructure (par exemple, en cas de changement de l’adresse IP d’un autre serveur ClickHouse ou du serveur utilisé par les Dictionaries).
Pour une gestion plus pratique (automatique) du cache, consultez les paramètres `disable_internal_dns_cache`, `dns_cache_max_entries`, `dns_cache_update_period`.
## SYSTEM CLEAR|DROP MARK CACHE
Vide le cache de marques.
## SYSTEM CLEAR|DROP PRIMARY INDEX CACHE
Efface le cache de l’index primaire, qui stocke en mémoire les clés primaires des tables [`MergeTree`](/fr/reference/engines/table-engines/mergetree-family/mergetree).
Sa taille est configurée à l’aide du paramètre de niveau serveur [`primary_index_cache_size`](/fr/reference/settings/server-settings/settings/primary-index#primary_index_cache_size).
## SYSTEM CLEAR|DROP ICEBERG METADATA CACHE
Vide le cache des métadonnées Iceberg.
## SYSTEM CLEAR|DROP AVRO SCHEMA CACHE
Vide les caches par URL du Confluent Schema Registry utilisés par le format `AvroConfluent`. Cette opération supprime à la fois le cache de récupération des schémas (id → schéma) et le cache d'enregistrement des schémas (subject + schéma → id), de sorte que les lectures et écritures suivantes repassent par le serveur du registre. Utile lorsqu'un schéma a été supprimé ou réécrit côté registre, ou pour vérifier l'idempotence du registre dans les tests.
## SYSTEM DROP PARQUET METADATA CACHE
Efface le cache de métadonnées Parquet.
## SYSTEM CLEAR|DROP PAIMON METADATA CACHE
Efface le cache en mémoire des fichiers de métadonnées Paimon analysés (listes de manifestes et manifestes).
## SYSTEM CLEAR|DROP POINT IN POLYGON CACHE
Efface le cache des polygones constants prétraités utilisés par la fonction [`pointInPolygon`](/fr/reference/functions/regular-functions/geo/coordinates#pointinpolygon). La limite de taille configurée (le paramètre serveur `point_in_polygon_cache_size`) reste inchangée, de sorte que le cache continue ensuite à accepter des entrées. Pour désactiver le cache, définissez plutôt `point_in_polygon_cache_size` sur `0`.
## SYSTEM CLEAR|DROP TEXT INDEX CACHES
Efface les caches de tokens, d’en-tête et de postings de l’index de texte.
Si vous souhaitez effacer séparément l’un de ces caches, vous pouvez exécuter
* `SYSTEM CLEAR TEXT INDEX TOKENS CACHE`,
* `SYSTEM CLEAR TEXT INDEX HEADER CACHE`, ou
* `SYSTEM CLEAR TEXT INDEX POSTINGS CACHE`
## SYSTEM CLEAR|DROP INDEX MARK CACHE
Vide le cache des marques des index secondaires (data-skipping).
## SYSTEM CLEAR|DROP INDEX UNCOMPRESSED CACHE
Efface le cache des blocs non compressés des index secondaires (data-skipping).
## SYSTEM CLEAR|DROP MMAP CACHE
Efface le cache des fichiers mappés en mémoire.
## SYSTEM CLEAR|DROP PAGE CACHE
Efface le userspace page cache, c’est-à-dire le cache en mémoire propre à ClickHouse pour les données lues depuis le stockage sous-jacent.
## SYSTEM CLEAR|DROP VECTOR SIMILARITY INDEX CACHE
Vide le cache de l’index de similarité vectorielle.
## SYSTEM CLEAR|DROP CONNECTIONS CACHE
Efface le cache des pools de connexions HTTP utilisés pour les connexions sortantes.
## SYSTEM CLEAR|DROP S3 CLIENT CACHE
Efface le cache des clients S3.
## SYSTEM PREWARM MARK CACHE
Charge en mémoire les marks d’une table dans le [cache de marque](#drop-mark-cache). Les marks des index secondaires sont également chargés dans le [cache des marks d’index](#drop-index-mark-cache).
```sql theme={null}
SYSTEM PREWARM MARK CACHE [ON CLUSTER cluster_name] [db.]table
```
## SYSTEM PREWARM PRIMARY INDEX CACHE
Charge les index primaires d’une table `MergeTree` dans le [cache de l’index primaire](#drop-primary-index-cache).
```sql theme={null}
SYSTEM PREWARM PRIMARY INDEX CACHE [ON CLUSTER cluster_name] [db.]table
```
## SYSTEM CLEAR|DROP DISK METADATA CACHE
Vide le cache de métadonnées du disque spécifié.
```sql theme={null}
SYSTEM DROP DISK METADATA CACHE
```
## SYSTEM SYNC FILESYSTEM CACHE
Met en cohérence l’état en mémoire de ClickHouse pour le cache du système de fichiers avec les fichiers de cache réellement présents sur le disque, et renvoie le `cache_name`, le `path` et la `size` téléchargée de chaque segment de fichier mis en cache. Un nom de cache facultatif limite l’opération à un seul cache.
```sql theme={null}
SYSTEM SYNC FILESYSTEM CACHE ['']
```
## SYSTEM CLEAR|DROP DISTRIBUTED CACHE
`SYSTEM CLEAR|DROP DISTRIBUTED CACHE` est disponible uniquement dans ClickHouse Cloud.
Supprime le Distributed Cache. Utilisez `CONNECTIONS` pour supprimer uniquement les connexions mises en cache vers les serveurs du Distributed Cache, ou indiquez un identifiant de serveur pour cibler un seul serveur.
```sql theme={null}
SYSTEM DROP DISTRIBUTED CACHE [CONNECTIONS | 'server_id']
```
## SYSTEM DROP REPLICA
Les répliques inactives des tables `ReplicatedMergeTree` peuvent être supprimées à l’aide de la syntaxe suivante :
```sql theme={null}
SYSTEM DROP REPLICA 'replica_name' FROM TABLE database.table;
SYSTEM DROP REPLICA 'replica_name' FROM DATABASE database;
SYSTEM DROP REPLICA 'replica_name';
SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/path/to/table/in/zk';
```
Les requêtes supprimeront le chemin de la réplique `ReplicatedMergeTree` dans ZooKeeper. Cela est utile lorsque la réplique est hors service et que ses métadonnées ne peuvent plus être supprimées de ZooKeeper via `DROP TABLE`, car la table n'existe plus. Seule la réplique inactive/obsolète sera supprimée ; la réplique locale ne peut pas l'être. Pour cela, utilisez `DROP TABLE`. `DROP REPLICA` ne supprime aucune table et n'efface ni données ni métadonnées sur le disque.
La première supprime les métadonnées de la réplique `'replica_name'` de la table `database.table`.
La deuxième fait de même pour toutes les tables répliquées de la base de données.
La troisième fait de même pour toutes les tables répliquées sur le serveur local.
La quatrième est utile pour supprimer les métadonnées d'une réplique hors service lorsque toutes les autres répliques d'une table ont été supprimées. Elle nécessite que le chemin de la table soit spécifié explicitement. Il doit s'agir du même chemin que celui passé comme premier argument du moteur `ReplicatedMergeTree` lors de la création de la table.
## SYSTEM DROP DATABASE REPLICA
Les répliques inactives des bases de données `Replicated` peuvent être supprimées à l’aide de la syntaxe suivante :
```sql theme={null}
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM DATABASE database;
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'];
SYSTEM DROP DATABASE REPLICA 'replica_name' [FROM SHARD 'shard_name'] FROM ZKPATH '/path/to/table/in/zk';
```
Semblable à `SYSTEM DROP REPLICA`, mais supprime le chemin de la réplique de la base de données `Replicated` dans ZooKeeper lorsqu'il n'existe aucune base de données sur laquelle exécuter `DROP DATABASE`. Veuillez noter que cela ne supprime pas les répliques `ReplicatedMergeTree` (vous pouvez donc aussi avoir besoin de `SYSTEM DROP REPLICA`). Les noms du shard et de la réplique sont ceux qui ont été spécifiés dans les arguments du moteur `Replicated` lors de la création de la base de données. En outre, ces noms peuvent être récupérés à partir des colonnes `database_shard_name` et `database_replica_name` de `system.clusters`. Si la clause `FROM SHARD` est absente, `replica_name` doit alors être un nom de réplique complet au format `shard_name|replica_name`.
## SYSTEM CLEAR|DROP UNCOMPRESSED CACHE
Efface le cache des données décompressées.
Le cache des données décompressées est activé/désactivé par le paramètre [`use_uncompressed_cache`](/fr/reference/settings/session-settings/use#use_uncompressed_cache) au niveau de la requête, de l’utilisateur ou du profil.
Sa taille peut être configurée à l’aide du paramètre [`uncompressed_cache_size`](/fr/reference/settings/server-settings/settings/uncompressed-cache#uncompressed_cache_size) au niveau du serveur.
## SYSTEM CLEAR|DROP COMPILED EXPRESSION CACHE
Efface le cache des expressions compilées.
Le cache des expressions compilées est activé ou désactivé à l’aide du paramètre [`compile_expressions`](/fr/reference/settings/session-settings/compile#compile_expressions), défini au niveau de la requête, de l’utilisateur ou du profil.
## SYSTEM CLEAR|DROP QUERY CONDITION CACHE
Vide le cache des conditions de requête.
## SYSTEM CLEAR|DROP ENCRYPTION HEADERS CACHE
Efface le cache des en-têtes de chiffrement. Ce cache stocke les en-têtes de chiffrement lus au début des fichiers chiffrés et est utilisé par le chemin de lecture expérimental `use_reader_executor` afin d’éviter de les relire ; sa taille est configurée par le paramètre serveur `encryption_header_cache_size`.
## SYSTEM CLEAR|DROP CACHE DE REQUÊTES
```sql theme={null}
SYSTEM CLEAR QUERY CACHE;
SYSTEM CLEAR QUERY CACHE TAG ''
```
Efface le [cache de requêtes](/fr/concepts/features/performance/caches/query-cache).
Si un tag est spécifié, seules les entrées du cache de requêtes associées à ce tag sont supprimées.
## SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE
Vide le cache des schémas chargés depuis [`format_schema_path`](/fr/reference/settings/server-settings/settings/format#format_schema_path).
Cibles prises en charge :
* Protobuf : supprime de la mémoire les définitions de messages Protobuf importées.
* Fichiers : supprime les fichiers de schéma mis en cache et stockés localement dans [`format_schema_path`](/fr/reference/settings/server-settings/settings/format#format_schema_path), générés lorsque `format_schema_source` est défini sur `query`.
Remarque : si aucune cible n'est spécifiée, les deux caches sont vidés.
```sql theme={null}
SYSTEM CLEAR|DROP FORMAT SCHEMA CACHE [FOR Protobuf/Files]
```
## SYSTEM FLUSH LOGS
Force l’écriture des messages de journalisation mis en mémoire tampon dans les tables système, par exemple `system.query_log`. Cette commande est surtout utile pour le débogage, car la plupart des tables système ont un intervalle de vidage par défaut de 7,5 secondes.
Elle crée également les tables système, même si la file d’attente des messages est vide.
```sql theme={null}
SYSTEM FLUSH LOGS [ON CLUSTER cluster_name] [log_name|[database.table]] [, ...]
```
Si vous ne voulez pas tout vider, vous pouvez vider un ou plusieurs logs individuels en indiquant soit leur nom, soit leur table cible :
```sql theme={null}
SYSTEM FLUSH LOGS query_log, system.query_views_log;
```
## SYSTEM RELOAD CONFIG
Recharge la configuration de ClickHouse. S’utilise lorsque la configuration est stockée dans ZooKeeper. Notez que `SYSTEM RELOAD CONFIG` ne recharge pas la configuration `USER` stockée dans ZooKeeper ; il recharge uniquement la configuration `USER` stockée dans `users.xml`. Pour recharger l’ensemble de la configuration `USER`, utilisez `SYSTEM RELOAD USERS`
```sql theme={null}
SYSTEM RELOAD CONFIG [ON CLUSTER cluster_name]
```
## SYSTEM RELOAD USERS
Recharge l’ensemble des stockages d’accès, notamment : users.xml, le stockage d’accès sur disque local, le stockage d’accès répliqué (dans ZooKeeper).
```sql theme={null}
SYSTEM RELOAD USERS [ON CLUSTER cluster_name]
```
## SYSTEM SHUTDOWN
Arrête proprement ClickHouse (comme `service clickhouse-server stop` / `kill {$pid_clickhouse-server}`)
## SYSTEM KILL
Met fin au processus ClickHouse (comme `kill -9 {$ pid_clickhouse-server}`)
## SYSTEM INSTRUMENT
Gère les points d’instrumentation à l’aide de la fonctionnalité XRay de LLVM, disponible lorsque ClickHouse est compilé avec `ENABLE_XRAY=1`.
Cela permet de déboguer et de profiler en production sans modifier le code source, avec une surcharge minimale.
Lorsqu’aucun point d’instrumentation n’est ajouté, la pénalité de performance est négligeable, car cela ajoute seulement un saut supplémentaire vers une adresse proche
au prologue et à l’épilogue des fonctions de plus de 200 instructions.
### SYSTEM INSTRUMENT ADD
Ajoute un nouveau point d’instrumentation. Les fonctions instrumentées peuvent être examinées dans la table système [`system.instrumentation`](/fr/reference/system-tables/instrumentation). Plusieurs handlers peuvent être ajoutés à une même fonction, et ils seront exécutés dans le même ordre que celui dans lequel l’instrumentation a été ajoutée.
Les fonctions à instrumenter peuvent être répertoriées à partir de la table système [`system.symbols`](/fr/reference/system-tables/symbols).
Il existe trois types différents de handlers à ajouter aux fonctions :
**Syntax**
```sql theme={null}
SYSTEM INSTRUMENT ADD FUNCTION HANDLER [ARGUMENTS]
```
où `FUNCTION` désigne n’importe quelle fonction ou sous-chaîne d’une fonction, telle que `QueryMetricLog::startQuery`, et où le gestionnaire est l’un des suivants
#### LOG
Affiche le texte passé en argument ainsi que la stack trace, soit à l'`ENTRY`, soit à l'`EXIT` de la fonction.
```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG ENTRY 'this is a log printed at entry'
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' LOG EXIT 'this is a log printed at exit'
```
#### SLEEP
Suspend l’exécution pendant un nombre défini de secondes, soit sur `ENTRY`, soit sur `EXIT` :
```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0.5
```
ou pour un nombre aléatoire de secondes suivant une distribution uniforme, en fournissant min et max séparés par un espace :
```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' SLEEP ENTRY 0 1
```
#### PROFIL
Mesure le temps écoulé entre `ENTRY` et `EXIT` d'une fonction.
Le résultat du profilage est stocké dans [`system.trace_log`](/fr/reference/system-tables/trace_log) et peut être converti
en [format de trace d'événements Chrome](/fr/reference/system-tables/trace_log#chrome-event-trace-format).
```sql theme={null}
SYSTEM INSTRUMENT ADD 'QueryMetricLog::startQuery' PROFILE
```
### SYSTEM INSTRUMENT REMOVE
Supprime un point d’instrumentation donné avec :
```sql theme={null}
SYSTEM INSTRUMENT REMOVE ID
```
tous à l’aide du mot-clé `ALL` :
```sql theme={null}
SYSTEM INSTRUMENT REMOVE ALL
```
un ensemble d’ID provenant d’une sous-requête :
```sql theme={null}
SYSTEM INSTRUMENT REMOVE (SELECT id FROM system.instrumentation WHERE handler = 'log')
```
ou tous les points d’instrumentation correspondant à un function\_name donné :
```sql theme={null}
SYSTEM INSTRUMENT REMOVE 'QueryMetricLog::startQuery'
```
Les informations sur les points d’instrumentation peuvent être récupérées depuis la table système [`system.instrumentation`](/fr/reference/system-tables/instrumentation).
## Gestion des tables Distributed
ClickHouse peut gérer des tables [Distributed](/fr/reference/engines/table-engines/special/distributed). Lorsqu'un utilisateur insère des données dans ces tables, ClickHouse crée d'abord une file d'attente des données à envoyer aux nœuds du cluster, puis les envoie de manière asynchrone. Vous pouvez gérer le traitement de cette file d'attente avec les requêtes [`STOP DISTRIBUTED SENDS`](#stop-distributed-sends), [FLUSH DISTRIBUTED](#flush-distributed) et [`START DISTRIBUTED SENDS`](#start-distributed-sends). Vous pouvez également insérer des données distribuées de manière synchrone avec le paramètre [`distributed_foreground_insert`](/fr/reference/settings/session-settings/distributed#distributed_foreground_insert).
### SYSTEM STOP DISTRIBUTED SENDS
Désactive la distribution des données en arrière-plan lors de l’insertion de données dans des tables Distributed.
```sql theme={null}
SYSTEM STOP DISTRIBUTED SENDS [db.] [ON CLUSTER cluster_name]
```
Si [`prefer_localhost_replica`](/fr/reference/settings/session-settings/prefer#prefer_localhost_replica) est activé (valeur par défaut), les données seront malgré tout insérées dans le shard local.
### SYSTEM FLUSH DISTRIBUTED
Force ClickHouse à envoyer les données aux nœuds du cluster de façon synchrone. Si certains nœuds sont indisponibles, ClickHouse lève une exception et arrête l’exécution de la requête. Vous pouvez relancer la requête jusqu’à ce qu’elle aboutisse, ce qui se produira lorsque tous les nœuds seront de nouveau en ligne.
Vous pouvez également surcharger certains paramètres via la clause `SETTINGS` ; cela peut être utile pour contourner certaines limitations temporaires, comme `max_concurrent_queries_for_all_users` ou `max_memory_usage`.
```sql theme={null}
SYSTEM FLUSH DISTRIBUTED [db.] [ON CLUSTER cluster_name] [SETTINGS ...]
```
Chaque bloc en attente est stocké sur le disque avec les paramètres de la requête INSERT initiale ; il peut donc parfois être utile de remplacer ces paramètres.
### SYSTEM START DISTRIBUTED SENDS
Active la distribution des données en arrière-plan lors de l’insertion de données dans les tables Distributed.
```sql theme={null}
SYSTEM START DISTRIBUTED SENDS [db.] [ON CLUSTER cluster_name]
```
### SYSTEM STOP LISTEN
Ferme le socket et met fin proprement aux connexions existantes au serveur sur le port spécifié, à l’aide du protocole spécifié.
Toutefois, si les paramètres du protocole correspondant n’ont pas été spécifiés dans la configuration de clickhouse-server, cette commande n’aura aucun effet.
```sql theme={null}
SYSTEM STOP LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
```
* Si le modificateur `CUSTOM 'protocol'` est spécifié, le protocole personnalisé portant le nom indiqué, défini dans la section des protocoles de la configuration du serveur, sera arrêté.
* Si le modificateur `QUERIES ALL [EXCEPT .. [,..]]` est spécifié, tous les protocoles seront arrêtés, sauf ceux indiqués dans la clause `EXCEPT`.
* Si le modificateur `QUERIES DEFAULT [EXCEPT .. [,..]]` est spécifié, tous les protocoles par défaut seront arrêtés, sauf ceux indiqués dans la clause `EXCEPT`.
* Si le modificateur `QUERIES CUSTOM [EXCEPT .. [,..]]` est spécifié, tous les protocoles personnalisés seront arrêtés, sauf ceux indiqués dans la clause `EXCEPT`.
### SYSTEM START LISTEN
Permet d’établir de nouvelles connexions sur les protocoles spécifiés.
Cependant, si le serveur sur le port et avec le protocole spécifiés n’a pas été arrêté à l’aide de la commande SYSTEM STOP LISTEN, cette commande sera sans effet.
```sql theme={null}
SYSTEM START LISTEN [ON CLUSTER cluster_name] [QUERIES ALL | QUERIES DEFAULT | QUERIES CUSTOM | TCP | TCP WITH PROXY | TCP SECURE | HTTP | HTTPS | MYSQL | GRPC | POSTGRESQL | PROMETHEUS | CUSTOM 'protocol']
```
## Gestion des tables MergeTree
ClickHouse peut gérer les opérations en arrière-plan dans les tables [MergeTree](/fr/reference/engines/table-engines/mergetree-family/mergetree).
### SYSTEM STOP MERGES
Permet d'arrêter les fusions en arrière-plan pour les tables de la famille MergeTree :
```sql theme={null}
SYSTEM STOP MERGES [ON CLUSTER cluster_name] [ON VOLUME | [db.]merge_tree_family_table_name]
```
Un `DETACH / ATTACH` d'une table redémarre les fusions en arrière-plan de cette table, même si elles ont auparavant été arrêtées pour toutes les tables MergeTree.
### SYSTEM START MERGES
Permet de démarrer les fusions en arrière-plan pour les tables de la famille MergeTree :
```sql theme={null}
SYSTEM START MERGES [ON CLUSTER cluster_name] [ON VOLUME | [db.]merge_tree_family_table_name]
```
### SYSTEM STOP TTL MERGES
Permet d’interrompre la suppression en arrière-plan des anciennes données selon l’[expression TTL](/fr/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-ttl) pour les tables de la famille MergeTree :
Renvoie `Ok.` même si la table n’existe pas ou n’utilise pas le moteur MergeTree. Renvoie une erreur lorsque la base de données n’existe pas :
```sql theme={null}
SYSTEM STOP TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```
### SYSTEM START TTL MERGES
Permet de lancer en arrière-plan la suppression des anciennes données conformément à l’[expression TTL](/fr/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-ttl) pour les tables de la famille MergeTree :
Renvoie `Ok.` même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
```sql theme={null}
SYSTEM START TTL MERGES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```
### SYSTEM STOP MOVES
Permet d’arrêter les déplacements de données en arrière-plan selon l’[expression TTL de table avec la clause TO VOLUME ou TO DISK](/fr/reference/engines/table-engines/mergetree-family/mergetree#mergetree-table-ttl) pour les tables de la famille MergeTree :
Renvoie `Ok.` même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
```sql theme={null}
SYSTEM STOP MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```
### SYSTEM START MOVES
Permet de lancer en arrière-plan les déplacements de données conformément à l’[expression TTL de table avec les clauses TO VOLUME et TO DISK](/fr/reference/engines/table-engines/mergetree-family/mergetree#mergetree-table-ttl) pour les tables de la famille MergeTree :
Renvoie `Ok.` même si la table n’existe pas. Renvoie une erreur lorsque la base de données n’existe pas :
```sql theme={null}
SYSTEM START MOVES [ON CLUSTER cluster_name] [[db.]merge_tree_family_table_name]
```
### SYSTEM UNFREEZE
Supprime de tous les disques la sauvegarde gelée portant le nom spécifié. Pour en savoir plus sur le dégel de parts distinctes, voir [ALTER TABLE table\_name UNFREEZE WITH NAME ](/fr/reference/statements/alter/partition#unfreeze-partition)
```sql theme={null}
SYSTEM UNFREEZE WITH NAME
```
### SYSTEM WAIT LOADING PARTS
Attend le chargement de toutes les parts de données d’une table chargées de manière asynchrone (parts de données obsolètes).
```sql theme={null}
SYSTEM WAIT LOADING PARTS [ON CLUSTER cluster_name] [db.]merge_tree_family_table_name
```
## Gestion des tables ReplicatedMergeTree
ClickHouse peut gérer les processus de réplication en arrière-plan dans les tables [ReplicatedMergeTree](/fr/reference/engines/table-engines/mergetree-family/replication).
### SYSTEM STOP FETCHES
Permet d'arrêter les opérations de récupération en arrière-plan des parts insérées pour les tables de la famille `ReplicatedMergeTree` :
Renvoie toujours `Ok.`, quel que soit le moteur de table, même si la table ou la base de données n'existe pas.
```sql theme={null}
SYSTEM STOP FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START FETCHES
Permet de lancer les opérations de récupération en arrière-plan des parts insérées pour les tables de la famille `ReplicatedMergeTree` :
Renvoie toujours `Ok.`, quel que soit le moteur de table, même si la table ou la base de données n’existe pas.
```sql theme={null}
SYSTEM START FETCHES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATED SENDS
Permet d’arrêter les envois en arrière-plan vers d’autres répliques du cluster des nouvelles parts insérées pour les tables de la famille `ReplicatedMergeTree` :
```sql theme={null}
SYSTEM STOP REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATED SENDS
Permet de démarrer les envois en arrière-plan vers d’autres répliques du cluster pour les nouvelles parts de données insérées des tables de la famille `ReplicatedMergeTree` :
```sql theme={null}
SYSTEM START REPLICATED SENDS [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP REPLICATION QUEUES
Permet d'arrêter les tâches de récupération en arrière-plan des files d'attente de réplication stockées dans ZooKeeper pour les tables de la famille `ReplicatedMergeTree`. Types possibles de tâches en arrière-plan - fusions, récupérations, mutations, instructions DDL avec la clause ON CLUSTER :
```sql theme={null}
SYSTEM STOP REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START REPLICATION QUEUES
Permet de démarrer les tâches de récupération en arrière-plan depuis les files d’attente de réplication stockées dans ZooKeeper pour les tables de la famille `ReplicatedMergeTree`. Types possibles de tâches en arrière-plan : fusions, récupérations, mutations, instructions DDL avec la clause ON CLUSTER :
```sql theme={null}
SYSTEM START REPLICATION QUEUES [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM STOP PULLING REPLICATION LOG
Arrête le chargement des nouvelles entrées du journal de réplication vers la file d’attente de réplication d’une table `ReplicatedMergeTree`.
```sql theme={null}
SYSTEM STOP PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM START PULLING REPLICATION LOG
Annule l’effet de `SYSTEM STOP PULLING REPLICATION LOG`.
```sql theme={null}
SYSTEM START PULLING REPLICATION LOG [ON CLUSTER cluster_name] [[db.]replicated_merge_tree_family_table_name]
```
### SYSTEM SYNC REPLICA
Attendez qu'une table `ReplicatedMergeTree` soit synchronisée avec les autres répliques d'un cluster, sans dépasser `receive_timeout` secondes.
```sql theme={null}
SYSTEM SYNC REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name [IF EXISTS] [STRICT | LIGHTWEIGHT [FROM 'srcReplica1'[, 'srcReplica2'[, ...]]] | PULL]
```
Après l’exécution de cette instruction, `[db.]replicated_merge_tree_family_table_name` récupère les commandes du journal répliqué commun dans sa propre file de réplication, puis la requête attend que la réplique traite toutes les commandes récupérées. Les modificateurs suivants sont pris en charge :
* Avec `IF EXISTS` (disponible à partir de la version 25.6), la requête ne renverra pas d’erreur si la table n’existe pas. Cela est utile lors de l’ajout d’une nouvelle réplique à un cluster, lorsqu’elle fait déjà partie de la configuration du cluster mais qu’elle est encore en cours de création et de synchronisation de la table.
* Si un modificateur `STRICT` a été spécifié, la requête attend que la file de réplication soit vide. La version `STRICT` peut ne jamais aboutir si de nouvelles entrées apparaissent constamment dans la file de réplication.
* Si un modificateur `LIGHTWEIGHT` a été spécifié, la requête attend uniquement que les entrées `GET_PART`, `ATTACH_PART`, `DROP_RANGE`, `REPLACE_RANGE` et `DROP_PART` soient traitées.
De plus, le modificateur LIGHTWEIGHT prend en charge une clause facultative `FROM 'srcReplicas'`, où 'srcReplicas' est une liste de noms de répliques sources séparés par des virgules. Cette extension permet une synchronisation plus ciblée en se concentrant uniquement sur les tâches de réplication provenant des répliques sources spécifiées.
* Si un modificateur `PULL` a été spécifié, la requête récupère de nouvelles entrées de la file de réplication depuis ZooKeeper, mais n’attend pas leur traitement.
### SYNCHRONISER LA RÉPLIQUE DE LA BASE DE DONNÉES
Attend jusqu’à ce que la [base de données répliquée](/fr/reference/engines/database-engines/replicated) spécifiée applique toutes les modifications de schéma de la file d’attente DDL de cette base de données.
**Syntaxe**
```sql theme={null}
SYSTEM SYNC DATABASE REPLICA replicated_database_name;
```
### SYSTEM RESTART REPLICA
Permet de réinitialiser l’état de la session ZooKeeper pour la table `ReplicatedMergeTree`, de comparer l’état actuel à celui de ZooKeeper, qui sert de source de référence, et d’ajouter des tâches à la file d’attente ZooKeeper si nécessaire.
L’initialisation de la file d’attente de réplication à partir des données ZooKeeper s’effectue de la même manière que pour l’instruction `ATTACH TABLE`. Pendant une courte période, la table sera indisponible pour toute opération.
```sql theme={null}
SYSTEM RESTART REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
### SYSTEM RESTORE REPLICA
Restaure une réplique si les données sont \[potentiellement] présentes, mais que les métadonnées ZooKeeper ont été perdues.
Fonctionne uniquement sur les tables `ReplicatedMergeTree` en mode readonly.
Cette requête peut être exécutée après :
* la perte de la racine ZooKeeper `/` ;
* la perte du chemin des répliques `/replicas` ;
* la perte du chemin d'une réplique individuelle `/replicas/replica_name/`.
La réplique attache les parts trouvées localement et envoie à ZooKeeper des informations à leur sujet.
Les parts présentes sur une réplique avant la perte des métadonnées ne sont pas récupérées de nouveau depuis d'autres répliques si elles ne sont pas obsolètes (la restauration d'une réplique ne signifie donc pas le retéléchargement de toutes les données sur le réseau).
Les parts dans tous les états sont déplacées vers le dossier `detached/`. Les parts actives avant la perte des données (`committed`) sont attachées.
### SYSTEM RESTORE DATABASE REPLICA
Restaure une réplique si des données sont \[éventuellement] présentes, mais que les métadonnées de ZooKeeper sont perdues.
**Syntaxe**
```sql theme={null}
SYSTEM RESTORE DATABASE REPLICA repl_db [ON CLUSTER cluster]
```
**Exemple**
```sql theme={null}
CREATE DATABASE repl_db
ENGINE=Replicated("/clickhouse/repl_db", shard1, replica1);
CREATE TABLE repl_db.test_table (n UInt32)
ENGINE = ReplicatedMergeTree
ORDER BY n PARTITION BY n % 10;
-- zookeeper_delete_path("/clickhouse/repl_db", recursive=True) <- root loss.
SYSTEM RESTORE DATABASE REPLICA repl_db;
```
**Syntaxe**
```sql theme={null}
SYSTEM RESTORE REPLICA [db.]replicated_merge_tree_family_table_name [ON CLUSTER cluster_name]
```
Autre syntaxe :
```sql theme={null}
SYSTEM RESTORE REPLICA [ON CLUSTER cluster_name] [db.]replicated_merge_tree_family_table_name
```
**Exemple**
Création d'une table sur plusieurs serveurs. Après la perte des métadonnées de la réplique dans ZooKeeper, la table sera attachée en lecture seule, faute de métadonnées. La dernière requête doit être exécutée sur chaque réplique.
```sql theme={null}
CREATE TABLE test(n UInt32)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/test/', '{replica}')
ORDER BY n PARTITION BY n % 10;
INSERT INTO test SELECT * FROM numbers(1000);
-- zookeeper_delete_path("/clickhouse/tables/test", recursive=True) <- root loss.
SYSTEM RESTART REPLICA test;
SYSTEM RESTORE REPLICA test;
```
Une autre méthode :
```sql theme={null}
SYSTEM RESTORE REPLICA test ON CLUSTER cluster;
```
### SYSTEM RESTART REPLICAS
Permet de réinitialiser l’état des sessions Zookeeper pour toutes les tables `ReplicatedMergeTree`, de comparer l’état actuel avec celui de Zookeeper, considéré comme source de vérité, et d’ajouter des tâches à la file d’attente de Zookeeper si nécessaire
### SYSTEM CLEAR|DROP FILESYSTEM CACHE
Permet de supprimer le cache du système de fichiers.
```sql theme={null}
SYSTEM CLEAR FILESYSTEM CACHE [ON CLUSTER cluster_name]
```
### SYSTEM SYNC FILE CACHE
Cette opération est trop lourde et peut faire l’objet d’une mauvaise utilisation.
Exécute l’appel système sync.
```sql theme={null}
SYSTEM SYNC FILE CACHE [ON CLUSTER cluster_name]
```
### SYSTEM LOAD PRIMARY KEY
Charge les clés primaires de la table indiquée ou de toutes les tables.
```sql theme={null}
SYSTEM LOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM LOAD PRIMARY KEY
```
### SYSTEM UNLOAD PRIMARY KEY
Décharge les clés primaires de la table spécifiée ou de toutes les tables.
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY [db.]name
```
```sql theme={null}
SYSTEM UNLOAD PRIMARY KEY
```
## Gestion des vues matérialisées avec rafraîchissement
Commandes permettant de contrôler les tâches d'arrière-plan exécutées par les [vues matérialisées avec rafraîchissement](/fr/reference/statements/create/view#refreshable-materialized-view)
Surveillez [`system.view_refreshes`](/fr/reference/system-tables/view_refreshes) lors de leur utilisation.
### SYSTEM STOP \[REPLICATED] VIEW, STOP VIEWS
Désactive l’actualisation périodique de la vue spécifiée ou de toutes les vues actualisables. Si une actualisation est en cours, elle est également annulée.
Si la vue se trouve dans une base de données Replicated ou Shared, `STOP VIEW` n’affecte que la réplique courante, tandis que `STOP REPLICATED VIEW` affecte toutes les répliques.
L’état d’arrêt n’est pas conservé après un redémarrage du serveur. Après redémarrage, les vues reprennent leur planification d’actualisation configurée.
Dans les bases de données Replicated ou Shared, `SYSTEM STOP VIEW` n’affecte que la réplique courante. Utilisez `SYSTEM STOP REPLICATED VIEW` pour arrêter les actualisations sur toutes les répliques.
```sql theme={null}
SYSTEM STOP VIEW [db.]name
```
```sql theme={null}
SYSTEM STOP VIEWS
```
### SYSTEM START \[REPLICATED] VIEW, START VIEWS
Active l'actualisation périodique pour la vue indiquée ou pour toutes les vues actualisables. Aucun rafraîchissement immédiat n'est déclenché.
Si la vue se trouve dans une base de données Replicated ou Shared, `START VIEW` annule l'effet de `STOP VIEW`, et `START REPLICATED VIEW` annule l'effet de `STOP REPLICATED VIEW`. `START VIEW` annule également l'effet de `PAUSE VIEW`.
```sql theme={null}
SYSTEM START VIEW [db.]name
```
```sql theme={null}
SYSTEM START VIEWS
```
### SYSTEM PAUSE VIEW, PAUSE VIEWS
Désactive le rafraîchissement périodique de la vue spécifiée ou de toutes les vues actualisables.
Contrairement à `SYSTEM STOP VIEW`, `SYSTEM PAUSE VIEW` n’interrompt pas un rafraîchissement déjà en cours : le rafraîchissement en cours peut aller à son terme, et seules les rafraîchissements suivantes sont empêchées.
Pour annuler, utilisez `SYSTEM START VIEW` ou `SYSTEM START VIEWS`.
L’état en pause ne persiste pas après un redémarrage du serveur. Après le redémarrage, les vues reprendront leur planification de rafraîchissement configurée.
Dans les bases de données Replicated ou Shared, `SYSTEM PAUSE VIEW` n’affecte que la réplique actuelle.
```sql theme={null}
SYSTEM PAUSE VIEW [db.]name
```
```sql theme={null}
SYSTEM PAUSE VIEWS
```
### SYSTEM REFRESH VIEW
Déclenche un rafraîchissement immédiat d’une vue donnée en dehors de la planification prévue.
```sql theme={null}
SYSTEM REFRESH VIEW [db.]name
```
### SYSTEM WAIT VIEW
Attend la fin du rafraîchissement en cours. Si aucun rafraîchissement n’est en cours, la commande retourne immédiatement. Si la dernière tentative de rafraîchissement a échoué, elle signale une erreur.
Peut être utilisée juste après la création d’une nouvelle vue matérialisée actualisable (sans le mot-clé EMPTY) pour attendre la fin du rafraîchissement initial.
Si la vue se trouve dans une base de données Replicated ou Shared, et qu’un rafraîchissement est en cours sur une autre réplique, attend la fin de ce rafraîchissement.
```sql theme={null}
SYSTEM WAIT VIEW [db.]name
```
### SYSTEM CANCEL VIEW
S'il y a un rafraîchissement en cours pour la vue spécifiée sur la réplique actuelle, interrompez-le et annulez-le. Sinon, ne faites rien.
```sql theme={null}
SYSTEM CANCEL VIEW [db.]name
```
## Gestion des activités en arrière-plan
Commandes indépendantes du moteur permettant de contrôler les activités en arrière-plan d’une table donnée ou de toutes les tables concernées du serveur à la fois. Elles couvrent :
* les [vues matérialisées rafraîchissables](/fr/reference/statements/create/view#refreshable-materialized-view) (leur rafraîchissement périodique) ;
* les moteurs de table de streaming qui consomment en continu une source externe : [Kafka](/fr/reference/engines/table-engines/integrations/kafka), [RabbitMQ](/fr/reference/engines/table-engines/integrations/rabbitmq), [NATS](/fr/reference/engines/table-engines/integrations/nats), [S3Queue](/fr/reference/engines/table-engines/integrations/s3queue) et [AzureQueue](/fr/reference/engines/table-engines/integrations/azure-queue).
Pour une vue matérialisée rafraîchissable, chaque verbe est un alias de la commande `SYSTEM ... VIEW` correspondante décrite dans [Gestion des vues matérialisées rafraîchissables](#managing-refreshable-materialized-views). Ainsi, `SYSTEM STOP [db.]name` se comporte exactement comme `SYSTEM STOP VIEW [db.]name`, et ainsi de suite.
Les formes applicables à une table et avec caractère générique diffèrent dans leur traitement des tables sans activité en arrière-plan. La forme applicable à une table (`SYSTEM STOP [db.]table`) génère une erreur si la table désignée n’est ni un moteur de streaming ni une vue matérialisée rafraîchissable. La forme avec caractère générique ignore silencieusement ces tables ; son exécution est donc toujours sans risque.
`STOP` et `CANCEL` interrompent la consommation dès que possible. Pour [Kafka](/fr/reference/engines/table-engines/integrations/kafka), [RabbitMQ](/fr/reference/engines/table-engines/integrations/rabbitmq) et [NATS](/fr/reference/engines/table-engines/integrations/nats), ils arrêtent la lecture depuis la source, mais n’interrompent pas un insert déjà commencé : un bloc en cours d’écriture dans les vues matérialisées est tout de même terminé et validé. [S3Queue](/fr/reference/engines/table-engines/integrations/s3queue) et [AzureQueue](/fr/reference/engines/table-engines/integrations/azure-queue) effectuent la lecture et l’insertion dans un seul pipeline. Lorsque la déduplication est activée (par défaut), l’insert est également annulé et les fichiers sont retraités ultérieurement. Lorsque la déduplication est désactivée, le batch en cours est au contraire terminé et validé (comme pour les moteurs ci-dessus) afin d’éviter la duplication de lignes. Les données lues mais pas encore validées sont de nouveau consommées ultérieurement : rien n’est donc perdu, à l’exception de NATS core (sans JetStream), qui ne peut pas les redistribuer et les supprime.
`PAUSE` n’interrompt pas un insert en cours ; il n’entraîne donc normalement aucune perte. NATS core fait exception : la mise en pause arrête la consommation et supprime les messages déjà reçus, mais pas encore insérés, que NATS core ne peut pas redistribuer.
Aucun de ces états ne persiste après le redémarrage du serveur. Après un redémarrage, les vues rafraîchissables reprennent leurs planifications configurées et les moteurs de streaming reprennent la consommation.
### SYSTEM STOP
Arrête l’activité en arrière-plan et la maintient à l’arrêt : interrompt ce qui est en cours d’exécution et n’exécute plus rien jusqu’à `SYSTEM START`. Équivalent à `PAUSE` + `CANCEL`.
```sql theme={null}
SYSTEM STOP [db.]table
SYSTEM STOP ALL BACKGROUND
```
### SYSTEM START
Reprend l’activité après un `SYSTEM STOP` ou un `SYSTEM PAUSE`. Aucune activité n’est interrompue.
```sql theme={null}
SYSTEM START [db.]table
SYSTEM START ALL BACKGROUND
```
### SYSTEM PAUSE
Empêche toute nouvelle activité en arrière-plan, mais laisse d’abord se terminer les tâches en cours.
```sql theme={null}
SYSTEM PAUSE [db.]table
SYSTEM PAUSE ALL BACKGROUND
```
### SYSTEM CANCEL
Interrompt uniquement l’activité en cours, sans bloquer les activités futures : la table continue de s’actualiser ou de consommer selon sa planification. N’a aucun effet si aucune activité n’est en cours.
```sql theme={null}
SYSTEM CANCEL [db.]table
SYSTEM CANCEL ALL BACKGROUND
```
### SYSTEM REFRESH
Exécute un cycle supplémentaire en dehors de la planification. Sur une table de streaming, cette commande s’exécute immédiatement et une seule fois, même si la table est arrêtée ou en pause. Sur une vue matérialisée rafraîchissable, elle se comporte comme `SYSTEM REFRESH VIEW` : si la vue est arrêtée, le rafraîchissement est mémorisé et s’exécute une fois que `SYSTEM START` la relance.
```sql theme={null}
SYSTEM REFRESH [db.]table
SYSTEM REFRESH ALL BACKGROUND
```
### Privilèges
Chaque commande requiert le privilège correspondant au moteur concerné : `SYSTEM VIEWS` pour une vue matérialisée actualisable et `SYSTEM STREAMING ENGINES` pour une table de streaming. Ces deux privilèges sont des enfants de `SYSTEM BACKGROUND` ; l’octroi de `SYSTEM BACKGROUND` permet donc de contrôler l’activité en arrière-plan de toutes ces tables. Les formes `ALL BACKGROUND` s’appliquent uniquement aux tables que l’utilisateur est autorisé à contrôler et ignorent silencieusement les autres.
## SYSTEM FLUSH OBJECT STORAGE QUEUE
Bloque l’exécution jusqu’à ce que le fichier indiqué ait été traité ou ait définitivement échoué dans la table [S3Queue](/fr/reference/engines/table-engines/integrations/s3queue) ou [AzureQueue](/fr/reference/engines/table-engines/integrations/azure-queue) donnée. Renvoie immédiatement si le fichier a déjà été traité. Génère une erreur si le fichier a définitivement échoué (toutes les tentatives de nouvelle exécution ont été épuisées).
```sql theme={null}
SYSTEM FLUSH OBJECT STORAGE QUEUE [db.]table_name PATH 'path'
```
## SYSTEM ENABLE|DISABLE FAILPOINT
Les failpoints sont des emplacements nommés dans le code du serveur où une défaillance peut être injectée à la demande — une erreur, un délai ou une mise en pause du thread en cours d'exécution — à des fins de test. Ils sont répertoriés dans la table [`system.fail_points`](/fr/reference/system-tables/fail_points), avec leur état actuel.
```sql theme={null}
SYSTEM ENABLE FAILPOINT name
SYSTEM DISABLE FAILPOINT name
SYSTEM DISABLE ALL FAILPOINTS
SYSTEM WAIT FAILPOINT name [PAUSE|RESUME]
SYSTEM NOTIFY FAILPOINT name
```
`SYSTEM ENABLE FAILPOINT` arme un failpoint donné ; `SYSTEM DISABLE FAILPOINT` le désarme et relance tout thread bloqué dessus ; il s'agit d'une no-op si le failpoint n'était pas activé.
`SYSTEM DISABLE ALL FAILPOINTS` désactive tous les failpoints en une seule fois et relance tous les threads bloqués sur un failpoint pouvant être mis en pause. Cette instruction ne prend aucun nom et est idempotente : un harnais de test peut donc l'utiliser pour ramener le serveur dans un état qui n'injecte rien, sans avoir à savoir quels failpoints le test précédent avait activés. Sur un build dépourvu de prise en charge des failpoints, le statement réussit sans rien faire.
`SYSTEM WAIT FAILPOINT ... PAUSE` bloque jusqu'à ce qu'un thread soit mis en pause sur le failpoint indiqué (ou que celui-ci soit désactivé), `... RESUME` bloque jusqu'à ce que le thread en pause soit relancé, et `SYSTEM NOTIFY FAILPOINT` relance les threads en pause sans désactiver le failpoint.
Les failpoints relèvent d'un état local au node : aucun de ces statements n'accepte donc `ON CLUSTER`. Tous requièrent le privilège `SYSTEM FAILPOINT`.