Passer au contenu principal

SYSTEM RELOAD EMBEDDED DICTIONARIES

Recharge tous les dictionnaires internes. 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), 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) ; ainsi, au lieu d’être chargés automatiquement au démarrage, ils sont initialisés lors du premier accès, via la fonction dictGet ou une instruction SELECT sur des tables avec ENGINE = Dictionary. Syntaxe

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.
L’état du dictionnaire peut être vérifié en interrogeant la table system.dictionaries.

SYSTEM RELOAD MODELS

Cette instruction et SYSTEM RELOAD MODEL se contentent de décharger les modèles CatBoost de clickhouse-library-bridge. La fonction catboostEvaluate() charge un modèle lors du premier accès s’il n’est pas encore chargé.
Décharge tous les modèles CatBoost. Syntaxe

SYSTEM RELOAD MODEL

Décharge le modèle CatBoost situé à model_path. Syntaxe

SYSTEM RELOAD FUNCTIONS

Recharge toutes les fonctions définies par l’utilisateur exécutables enregistrées, ou l’une d’entre elles, à partir d’un fichier de configuration. Syntaxe

SYSTEM RELOAD ASYNCHRONOUS METRICS

Recalcule toutes les métriques asynchrones. Comme les métriques asynchrones sont mises à jour périodiquement selon le paramètre asynchronous_metrics_update_period_s, il n’est généralement pas nécessaire de les mettre à jour manuellement à l’aide de cette instruction.

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 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 TEXT INDEX CACHES

Efface les caches d’en-tête, de dictionnaire 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 HEADER CACHE,
  • SYSTEM CLEAR TEXT INDEX DICTIONARY CACHE, ou
  • SYSTEM CLEAR TEXT INDEX POSTINGS CACHE

SYSTEM DROP REPLICA

Les répliques inactives des tables ReplicatedMergeTree peuvent être supprimées à l’aide de la syntaxe suivante :
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 :
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 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 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, 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 CACHE DE REQUÊTES

Efface le cache de requêtes. 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. 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, 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.

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.
Si vous ne voulez pas tout vider, vous pouvez vider un ou plusieurs logs individuels en indiquant soit leur nom, soit leur table cible :

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

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).

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. 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. Il existe trois types différents de handlers à ajouter aux fonctions : Syntax
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.

SLEEP

Suspend l’exécution pendant un nombre défini de secondes, soit sur ENTRY, soit sur EXIT :
ou pour un nombre aléatoire de secondes suivant une distribution uniforme, en fournissant min et max séparés par un espace :

PROFIL

Mesure le temps écoulé entre ENTRY et EXIT d’une fonction. Le résultat du profilage est stocké dans system.trace_log et peut être converti en format de trace d’événements Chrome.

SYSTEM INSTRUMENT REMOVE

Supprime un point d’instrumentation donné avec :
tous à l’aide du mot-clé ALL :
un ensemble d’ID provenant d’une sous-requête :
ou tous les points d’instrumentation correspondant à un function_name donné :
Les informations sur les points d’instrumentation peuvent être récupérées depuis la table système system.instrumentation.

Gestion des tables Distributed

ClickHouse peut gérer des tables 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, FLUSH DISTRIBUTED et START DISTRIBUTED SENDS. Vous pouvez également insérer des données distribuées de manière synchrone avec le paramètre 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.
Si 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.
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.

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.
  • 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.

Gestion des tables MergeTree

ClickHouse peut gérer les opérations en arrière-plan dans les tables MergeTree.

SYSTEM STOP MERGES

Permet d’arrêter les fusions en arrière-plan pour les tables de la famille MergeTree :
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 :

SYSTEM STOP TTL MERGES

Permet d’interrompre la suppression en arrière-plan des anciennes données selon l’expression 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 :

SYSTEM START TTL MERGES

Permet de lancer en arrière-plan la suppression des anciennes données conformément à l’expression 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 :

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 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 :

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 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 :

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

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).

Gestion des tables ReplicatedMergeTree

ClickHouse peut gérer les processus de réplication en arrière-plan dans les tables ReplicatedMergeTree.

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.

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.

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 :

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 :

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 :

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 :

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.

SYSTEM START PULLING REPLICATION LOG

Annule l’effet de SYSTEM STOP PULLING REPLICATION LOG.

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.
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 spécifiée applique toutes les modifications de schéma de la file d’attente DDL de cette base de données. Syntaxe

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.

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
Exemple
Syntaxe
Autre syntaxe :
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.
Une autre méthode :

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.

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.

SYSTEM LOAD PRIMARY KEY

Charge les clés primaires de la table indiquée ou de toutes les tables.

SYSTEM UNLOAD PRIMARY KEY

Décharge les clés primaires de la table spécifiée ou de toutes les tables.

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 Surveillez system.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.

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.

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.

SYSTEM REFRESH VIEW

Déclenche un rafraîchissement immédiat d’une vue donnée en dehors de la planification prévue.

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.

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.

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 ou AzureQueue 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).
Dernière modification le 2 juillet 2026