ALTER TASK

Modifie les propriétés d’une tâche existante.

Voir aussi :

CREATE TASK , DROP TASK , SHOW TASKS , DESCRIBE TASK

Syntaxe

ALTER TASK [ IF EXISTS ] <name> RESUME | SUSPEND

ALTER TASK [ IF EXISTS ] <name> REMOVE AFTER <string> [ , <string> , ... ] | ADD AFTER <string> [ , <string> , ... ]

ALTER TASK [ IF EXISTS ] <name> SET
  [ WAREHOUSE = <string> ]
  [ SCHEDULE = '{ <number> MINUTE | USING CRON <expr> <time_zone> }' ]
  [ CONFIG = <configuration_string> ]
  [ ALLOW_OVERLAPPING_EXECUTION = TRUE | FALSE ]
  [ USER_TASK_TIMEOUT_MS = <num> ]
  [ SUSPEND_TASK_AFTER_NUM_FAILURES = <num> ]
  [ COMMENT = <string> ]
  [ <session_parameter> = <value> [ , <session_parameter> = <value> ... ] ]

ALTER TASK [ IF EXISTS ] <name> UNSET
  [ WAREHOUSE ]
  [ SCHEDULE ]
  [ CONFIG ]
  [ ALLOW_OVERLAPPING_EXECUTION ]
  [ USER_TASK_TIMEOUT_MS ]
  [ SUSPEND_TASK_AFTER_NUM_FAILURES ]
  [ COMMENT ]
  [ <session_parameter> [ , <session_parameter> ... ] ]
  [ , ... ]

ALTER TASK [ IF EXISTS ] <name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ]

ALTER TASK [ IF EXISTS ] <name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER TASK [ IF EXISTS ] <name> SET FINALIZE = <string>

ALTER TASK [ IF EXISTS ] <name> UNSET FINALIZE

ALTER TASK [ IF EXISTS ] <name> MODIFY AS <sql>

ALTER TASK [ IF EXISTS ] <name> MODIFY WHEN <boolean_expr>
Copy

Paramètres

name

Identificateur de la tâche à modifier. Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.

RESUME | SUSPEND

Spécifie l’action à effectuer sur la tâche :

  • RESUME amène une tâche suspendue à un état « démarré » utilisable. Notez que les comptes sont actuellement limités à un maximum de 30 000 tâches reprises (c.-à-d. dans un statut « Démarré »).

  • SUSPEND met la tâche dans un état « suspendu ».

Si la planification de la tâche est définie sur un intervalle (c’est-à-dire number MINUTE), pour éviter toute ambiguïté, l’intervalle de base de la planification est réinitialisé à l’heure actuelle lorsque la tâche est reprise.

L’intervalle de base démarre le compteur d’intervalle à partir de l’heure actuelle. Par exemple, si une valeur INTERVAL de 10 est définie et que la tâche est reprise à 9:03 AM, elle s’exécute à 9:13 AM, 9:23 AM, etc. Notez que nous faisons de notre mieux pour assurer une précision absolue, mais nous garantissons uniquement que les tâches ne s’exécutent pas avant que leur intervalle défini ne soit exécuté (par exemple, dans cet exemple, la tâche pourrait d’abord être exécutée à 9:14 AM, mais ne fonctionnera certainement pas à 9:12 AM).

REMOVE AFTER string [ , string , ... ]

Spécifie les noms d’un ou plusieurs prédécesseurs actuels pour cette tâche enfant dans un DAG de tâches.

Lorsque tous les prédécesseurs d’une tâche enfant sont supprimés, l’ancienne tâche enfant devient alors une tâche autonome ou une tâche racine, selon que d’autres tâches identifient cette ancienne tâche enfant comme leur prédécesseur. Si l’ancienne tâche enfant devient une tâche racine, cette tâche est suspendue par défaut et doit être reprise manuellement.

ADD AFTER string [ , string , ... ]

Spécifie les noms d’une ou plusieurs tâches existantes à ajouter comme prédécesseurs de cette tâche enfant dans un DAG de tâches. Chaque tâche enfant dans un DAG s’exécute lorsque toutes les tâches prédécesseurs terminent leur exécution avec succès. Pour plus d’informations, voir la description du paramètre AFTER dans CREATE TASK.

Chaque tâche enfant est limitée à 100 tâches prédécesseurs.

SET ...

Spécifie l’un ou les deux éléments suivants :

  • Spécifie une (ou plusieurs) propriétés à définir pour la tâche (séparées par des espaces, des virgules ou de nouvelles lignes). Pour plus de détails sur les propriétés que vous pouvez définir, voir CREATE TASK.

  • Liste de paramètres de session séparés par des virgules à définir pour la session lorsque la tâche est exécutée. Une tâche prend en charge tous les paramètres de session. Pour obtenir la liste complète, voir Paramètres.

  • TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]

    Spécifie le nom de la balise et la valeur de la chaîne de la balise.

    La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.

    Pour plus de détails sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.

UNSET ...

Spécifie une (ou plusieurs) propriété(s) et/ou paramètres de session à désactiver pour la tâche, ce qui les réinitialise aux valeurs par défaut.

Vous pouvez réinitialiser plusieurs propriétés/paramètres avec une seule instruction ALTER ; cependant, chaque propriété/paramètre doit être séparé(e) par une virgule. Lors de la réinitialisation d’une propriété ou d’un paramètre, spécifiez seulement le nom ; si vous spécifiez une valeur pour la propriété/le paramètre, vous obtiendrez une erreur.

sql

Spécifie le code SQL à exécuter lorsque la tâche s’exécute :

  • Instruction SQL unique

  • Appel d’une procédure stockée

  • Logique procédurale à l’aide de l’Exécution de scripts Snowflake

    Notez qu’actuellement, Snowsight et l”Classic Console ne prennent pas en charge la création ou la modification de tâches pour utiliser Exécution de scripts Snowflake. Utilisez plutôt SnowSQL ou un autre client en ligne de commande.

Note

Vérifiez que le code SQL auquel vous faites référence dans une tâche s’exécute comme prévu avant de créer la tâche. Les tâches sont destinées à automatiser le code SQL qui a déjà été testé de manière approfondie.

WHEN boolean_expr

Spécifie une expression booléenne SQL. Lorsqu’une tâche est déclenchée (en fonction de son paramètre SCHEDULE ou AFTER), elle valide les conditions de l’expression pour déterminer si elle doit être exécutée. Si les conditions de l’expression ne sont pas remplies, la tâche ignore l’exécution en cours. Aucune tâche identifiant cette tâche en tant que prédécesseur ne s’exécute pas non plus.

La validation des conditions de l’expression WHEN ne nécessite pas d’entrepôt virtuel. La validation est plutôt traitée dans la couche des services Cloud. Une charge nominale s’accumule chaque fois qu’une tâche évalue sa condition WHEN et ne s’exécute pas. Les frais s’accumulent chaque fois que la tâche est déclenchée jusqu’à son exécution. À ce moment, les frais sont convertis en crédits Snowflake et ajoutés à l’utilisation des ressources de calcul pour l’exécution de la tâche.

En général, le temps de calcul pour valider la condition est insignifiant par rapport au temps d’exécution de la tâche. La meilleure pratique consiste à aligner le plus étroitement possible le déroulement prévu et le déroulement effectif des tâches. Évitez les calendriers de tâches qui sont totalement désynchronisés par rapport aux tâches réelles. Par exemple, si des données sont insérées dans une table avec un flux toutes les 24 heures environ, ne programmez pas une tâche qui vérifie les données du flux toutes les minutes. Les frais pour valider l’expression WHEN à chaque exécution sont généralement insignifiants, mais les frais se cumulent.

Notez que la consommation quotidienne de services Cloud qui tombe en dessous des 10 % de quota de l’utilisation quotidienne des ressources de calcul n’accumule pas de frais de services Cloud.

Actuellement, les fonctions suivantes sont prises en charge pour l’évaluation dans l’expression SQL :

SYSTEM$STREAM_HAS_DATA

Indique si un flux spécifié contient des données de suivi des modifications. Utilisé pour ignorer l’exécution de la tâche en cours si le flux ne contient aucune donnée de modification.

Si le résultat est FALSE, la tâche ne s’exécute pas.

SYSTEM$GET_PREDECESSOR_RETURN_VALUE

Récupère la valeur de retour pour le prédécesseur dans un DAG de tâches. Utilisé pour décider si la tâche doit être exécutée en fonction du résultat obtenu.

Notes sur l’utilisation

  • La reprise ou la suspension d’une tâche (avec ALTER TASK … RESUME ou ALTER TASK … SUSPEND, respectivement) requiert le privilège OWNERSHIP ou OPERATE sur la tâche.

    Lorsqu’une tâche est reprise, Snowflake vérifie que le rôle avec le privilège OWNERSHIP sur la tâche possède également le privilège USAGE sur l’entrepôt affecté à la tâche, ainsi que le privilège global EXECUTE TASK ; sinon, une erreur se produit.

    Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent accorder le privilège EXECUTE TASK à un rôle. Pour faciliter l’utilisation, nous vous recommandons de créer un rôle personnalisé (par exemple, TASKADMIN) et d’attribuer le privilège EXECUTE TASK à ce rôle. Tout rôle pouvant octroyer des privilèges (par exemple, SECURITYADMIN ou n’importe quel rôle disposant du privilège MANAGE GRANTS) peut ensuite attribuer ce rôle personnalisé à tout rôle de propriétaire de tâche afin de permettre la modification de ses propres tâches. Pour obtenir des instructions sur la création de rôles personnalisés et de hiérarchies de rôles, voir Configuration du contrôle d’accès.

  • Seul le propriétaire de la tâche (c’est-à-dire le rôle doté du privilège OWNERSHIP sur la tâche) peut définir ou annuler la définition des propriétés sur une tâche.

  • Lorsque vous modifiez la configuration, vous ne pouvez pas mettre à jour des paires clé-valeur individuelles. Vous devez plutôt fournir l’intégralité de la chaîne json de remplacement représentant la configuration complète.

  • Une tâche autonome doit être suspendue avant de pouvoir être modifiée.

  • La tâche racine dans un DAG de tâches doit être suspendue avant que toute tâche dans le DAG soit modifiée, une tâche enfant suspendue ou reprise, ou une tâche enfant ajoutée (à l’aide de ALTER TASK … AFTER).

  • Un DAG est limité à un maximum de 1 000 tâches au total (y compris la tâche racine) dans un état repris ou suspendu.

  • Pour reprendre de manière récursive toutes les tâches dépendantes liées à une tâche racine dans un DAG, interrogez la fonction SYSTEM$TASK_DEPENDENTS_ENABLE plutôt que d’activer chaque tâche individuellement (à l’aide de ALTER TASK … RESUME).

  • Par défaut, une instruction DML exécutée sans démarrer explicitement une transaction est automatiquement validée en cas de succès ou annulée en cas d’échec à la fin de l’instruction. Ce comportement s’appelle validation automatique, et il est contrôlé avec le paramètre AUTOCOMMIT. Ce paramètre doit être défini sur TRUE. Si le paramètre AUTOCOMMIT est défini sur FALSE au niveau du compte, définissez-le sur TRUE pour la tâche individuelle (avec ALTER TASK … SET AUTOCOMMIT = TRUE).

  • Lorsqu’une tâche est suspendue, son exécution actuelle (c’est-à-dire une exécution avec un état EXECUTING dans la sortie TASK_HISTORY) est terminée. Pour interrompre l’exécution de la tâche spécifiée, exécutez la fonction SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS.

  • Les ressources de calcul pour les exécutions individuelles d’une tâche sont soit gérées par Snowflake (c’est-à-dire le modèle de calcul sans serveur), soit par un entrepôt virtuel spécifié par l’utilisateur. Pour convertir une tâche qui s’appuie sur un entrepôt au modèle de calcul sans serveur, désactivez WAREHOUSE.

    Note

    Le modèle de calcul sans serveur est pris en charge en tant que fonctionnalité en avant-première.

  • Si une tâche échoue avec une erreur inattendue, vous pouvez recevoir une notification concernant l’erreur. Pour plus d’informations sur la configuration des notifications d’erreur de tâche, reportez-vous à Activation des notifications d’erreur pour des tâches.

  • Concernant les métadonnées :

    Attention

    Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

  • En ce qui concerne la tâche de finalisation :

    • Lorsque vous lancez une requête SET FINALIZE = <sur le nom de tâche racine>, une tâche standard est configurée pour être une tâche de finalisation associée à la tâche racine donnée.

    • Lorsque vous lancez une requête UNSET FINALIZE, une tâche de finalisation redevient une tâche autonome standard, sans planification ni prédécesseur.

    • Une tâche de finalisation ne doit jamais avoir de planification ni de prédécesseur. Par conséquent, le lancement d’une requête SET FINALIZE sur une tâche est en conflit avec les requêtes SET SCHEDULE et ADD AFTER. Une tâche avec une planification ou un prédécesseur existant(e) fera également échouer la requête SET FINALIZE. Si la tâche racine cible possède déjà une tâche de finalisation, la requête ALTER remplace l’ancienne afin que la tâche racine cible ait une nouvelle tâche de finalisation.

    • La tâche racine doit être suspendue avant la modification, l’activation ou la désactivation de la tâche de finalisation.

Exemples

L’exemple suivant lance l’opération d’une tâche :

ALTER TASK mytask RESUME;
Copy

L’exemple suivant convertit une tâche vers le modèle de calcul sans serveur et définit xsmall comme quantité de ressources de calcul à provisionner pour les premières exécutions sans serveur de la tâche :

ALTER TASK mytask UNSET WAREHOUSE;

ALTER TASK mytask SET USER_TASK_MANAGED_INITIAL_WAREHOUSE_SIZE = 'XSMALL';
Copy

L’exemple suivant définit les paramètres de session TIMEZONE et CLIENT_TIMESTAMP_TYPE_MAPPING pour la session dans laquelle la tâche est exécutée :

ALTER TASK mytask SET TIMEZONE = 'America/Los_Angeles', CLIENT_TIMESTAMP_TYPE_MAPPING = TIMESTAMP_LTZ;
Copy

L’exemple suivant définit une planification différente pour une tâche :

ALTER TASK mytask SET SCHEDULE = 'USING CRON */3 * * * * UTC';
Copy

L’exemple suivant supprime les prédécesseurs actuels pour la tâche enfant mytask (pred_task1, pred_task2) et les remplace par un prédécesseur différent (pred_task3) :

ALTER TASK mytask REMOVE AFTER pred_task1, pred_task2;

ALTER TASK mytask ADD AFTER pred_task3;
Copy

L’exemple suivant modifie l’instruction SQL associée à une tâche. La tâche interroge désormais la fonction CURRENT_VERSION lorsqu’elle s’exécute :

ALTER TASK mytask MODIFY AS SELECT CURRENT_VERSION();
Copy

L’exemple suivant modifie la condition WHEN associée à une tâche. Lorsqu’elle est déclenchée (selon une planification ou après l’exécution réussie de la tâche précédente), la tâche s’exécute désormais uniquement lorsque le flux mystream contient des données :

ALTER TASK mytask MODIFY WHEN SYSTEM$STREAM_HAS_DATA('MYSTREAM');
Copy

Mettez à jour une tâche existante avec une nouvelle configuration ou une configuration de remplacement.

ALTER TASK task_with_config SET
      CONFIG=$${"output_directory": "/temp/prod_directory/", "environment": "prod"}$$;
Copy

Supprimez la configuration d’une tâche existante.

ALTER TASK task_with_config UNSET CONFIG;
Copy