Dépannage des tâches¶
Cette section décrit une approche méthodique du dépannage des tâches qui ne s’exécutent pas comme prévu.
Dans ce chapitre :
La tâche n’a pas été exécutée¶
Étape 1 : Vérification de la non-exécution de la tâche¶
Interrogez la fonction de table TASK_HISTORY pour vérifier que la tâche n’a pas été exécutée. Il est possible que la tâche ait été exécutée avec succès, mais que l’instruction SQL de la définition de la tâche ait échoué. En particulier, notez les heures planifiées et effectuées, ainsi que tout code et message d’erreur.
Si la tâche a une tâche prédécesseur (dans un DAG), vérifiez si la tâche prédécesseur s’est terminée avec succès.
Étape 2 : Vérification de la reprise de la tâche¶
Vérifiez que le statut de la tâche (ou de chaque tâche dans un DAG) est RESUMED (à l’aide de DESCRIBE TASK ou SHOW TASKS).
Pour reprendre une tâche individuelle, exécutez ALTER TASK … RESUME. Pour activer de manière récursive toutes les tâches dépendantes liées à une tâche racine, interrogez la fonction SYSTEM$TASK_DEPENDENTS_ENABLE plutôt que d’activer chaque tâche individuellement.
Pendant que vous examinez les détails de la tâche, si la tâche a une planification, vérifiez également l’expression cron. Vérifiez qu’au moins une occurrence de l’heure planifiée est passée.
Étape 3 : Vérification des autorisations accordées au propriétaire de la tâche¶
Vérifiez que le propriétaire de la tâche (c’est-à-dire le rôle qui dispose du privilège OWNERSHIP sur la tâche) dispose des privilèges suivants qui sont nécessaires la tâche à exécuter :
Objet |
Privilège |
Remarques |
|---|---|---|
Compte |
EXECUTE TASK |
Requis pour exécuter toutes les tâches du rôle. La révocation du privilège EXECUTE TASK sur un rôle empêche toutes les tâches suivantes de démarrer sous ce rôle. |
Base de données |
USAGE |
|
Schéma |
USAGE |
|
Tâche |
OWNERSHIP |
|
Entrepôt |
USAGE |
Vérifiez les privilèges accordés au rôle à l’aide de SHOW GRANTS TO ROLE role_name.
Étape 4 : Vérification de la condition¶
Si la tâche inclut une clause WHEN avec une condition SYSTEM$STREAM_HAS_DATA, vérifiez que le flux spécifié contient des enregistrements de capture de données modifiées (CDC) lors de la dernière exécution de la tâche. Les données historiques d’un flux peuvent être interrogées à l’aide d’une clause AT | BEFORE.
La tâche a expiré ou a dépassé la fenêtre de planification¶
Il existe une limite de 60 minutes par défaut pour une seule exécution d’une tâche. Cette limitation a été mise en œuvre à titre de protection contre les tâches ne se terminant pas. Interrogez la fonction de table TASK_HISTORY. Si la tâche a été annulée ou a dépassé la fenêtre prévue pour la tâche, la cause en est souvent un entrepôt trop petit. Vérifiez la taille de l’entrepôt et envisagez de l’augmenter pour l’adapter à la période de planification ou à la limite d’une heure.
Vous pouvez également envisager d’augmenter le délai d’expiration de la tâche en exécutant ALTER TASK … SET USER_TASK_TIMEOUT_MS = <num>. Pour déterminer si le paramètre USER_TASK_TIMEOUT_MS a été défini pour une tâche spécifique, exécutez l’instruction suivante :
SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK <task_name>;
Où <task_name> est le nom de la tâche dont vous ajustez le délai d’expiration. Si l’instruction ne renvoie aucun enregistrement, la tâche dispose actuellement du délai d’expiration par défaut de 3600000 millisecondes (60 minutes).
Notez que ni l’augmentation de la taille de l’entrepôt ni l’augmentation du délai d’expiration ne sont utiles en cas de problèmes de parallélisation des requêtes. Envisagez d’autres moyens de réécrire l’instruction SQL exécutée par la tâche.