Timeout d'une requête SQL SFMC : causes et solutions
Votre requête SFMC s'arrête après 30 minutes. Comprenez le timeout SQL et corrigez-le avec des filtres SARGable, du staging et des lots.
Votre automatisation a tourné pendant une demi-heure, puis s'est arrêtée sur une erreur, et la data extension cible est vide. C'est le classique timeout d'une requête SQL SFMC, qui apparaît souvent la semaine où vos données dépassent ce qu'une requête approximative peut absorber.
La réponse courte : une Query Activity d'Automation Studio est interrompue au bout de 30 minutes, et cette limite ne se prolonge pas. On corrige le problème en demandant moins de travail à la requête, pas en attendant plus longtemps.
Ce guide explique pourquoi les timeouts surviennent, propose des réécritures avec des exemples SQL complets, et se termine par une checklist à dérouler dès qu'une requête se bloque.
Comprendre le timeout des requêtes SQL dans SFMC
La limite de 30 minutes
Les conseils de dépannage Automation Studio de Salesforce recommandent d'optimiser et de découper toute requête qui dépasse régulièrement 30 minutes. En pratique, c'est un plafond : une requête qui ne tient pas dans ce délai n'aboutira pas, même relancée dix fois.
Deux points comptent. Salesforce conseille aussi de placer chaque requête dans sa propre étape pour qu'aucune autre activité ne lui fasse concurrence, et une requête tout juste assez rapide un dimanche calme peut échouer un lundi chargé.
À quoi ressemble un timeout en pratique
Dans Automation Studio, l'activité affiche une erreur dans la colonne Progress de la vue d'ensemble de l'automatisation, et le survol donne la cause. L'onglet Action Log contient le détail. Le schéma typique est une requête qui fonctionnait depuis des mois et qui échoue à mesure que les data extensions sources grossissent.
N'oubliez pas non plus qu'une activité de requête qui échoue 24 fois de suite est désactivée, d'après le blog développeurs de Salesforce. Un timeout ignoré peut donc couper complètement l'activité.
Pourquoi une requête SQL SFMC atteint le timeout
Fonctions sur les colonnes et filtres trop larges
La cause la plus fréquente est une clause WHERE qui enveloppe une colonne dans une fonction, comme DATEDIFF() ou CONVERT(). La base doit alors évaluer chaque ligne au lieu d'utiliser un index ou une plage étroite.
La deuxième cause est de parcourir bien plus d'historique que nécessaire. Salesforce conseille de limiter les requêtes à environ six mois de données quand c'est possible : plus vous réduisez la fenêtre de dates tôt, moins il y a de lignes à joindre.
Jointures lourdes, tables larges et data views système
Les jointures sur des champs sans clé primaire, entre des colonnes de types différents, ou sur des data extensions larges avec beaucoup de champs texte longs ajoutent du travail. Nommer les colonnes utiles plutôt que SELECT * aide, tout comme des champs texte aussi courts que les données le permettent.
Les data views système comme _Sent et _Open peuvent être énormes dans les comptes actifs. Notre guide pour interroger les data views SFMC en SQL montre comment garder ces lectures légères.
Si la rédaction et l'optimisation du SQL à la main ralentissent votre équipe, vous pouvez aussi générer du SQL SFMC à partir d'une phrase en langage naturel et relire le résultat avant exécution.
Solution 1 : écrire des filtres exploitables par la base
Remplacer les fonctions sur colonnes par des plages
On appelle « SARGable » un filtre qui peut s'appuyer sur un index. La règle est simple : laissez la colonne intacte et faites le calcul de l'autre côté de la comparaison.
Comparez deux façons de trouver les commandes des 30 derniers jours. La première applique une fonction à la colonne, donc chaque ligne est évaluée :
WHERE DATEDIFF(day, o.OrderDate, GETDATE()) <= 30La seconde laisse OrderDate intacte et la compare à une borne calculée. Vous la retrouverez dans la requête de staging ci-dessous, et notre article sur les fonctions de date SQL dans SFMC détaille DATEADD() et GETDATE().
Filtrer tôt et ne garder que les colonnes utiles
Placez le filtre le plus sélectif sur la plus grande table, ne sélectionnez que les champs dont l'étape suivante a besoin, et agrégez avant de joindre. Une requête qui réduit des millions de lignes de commandes à une ligne par abonné avant la jointure est bien plus légère que l'inverse.
Solution 2 : découper le travail en étapes et en lots
Isoler la partie lourde dans une data extension de staging
Quand une requête joint plusieurs grosses tables, coupez-la en deux. La première fait l'agrégation lourde et écrit dans une petite data extension de staging, la seconde joint ce petit résultat à votre table clients.
Étape 1 : trouver les acheteurs récents. Data extension cible : Recent_Buyers_Stage, clé primaire SubscriberKey, type de mise à jour Overwrite.
SELECT o.SubscriberKey,
MAX(o.OrderDate) AS LastOrderDate
FROM Orders_Master o
WHERE o.OrderDate >= DATEADD(day, -30, CAST(GETDATE() AS DATE))
GROUP BY o.SubscriberKey- La ligne WHERE compare OrderDate à une date calculée, la colonne reste donc intacte.
- GROUP BY regroupe les commandes en une ligne par SubscriberKey, ce qui garde la table de staging petite.
- MAX(OrderDate) conserve la date de dernière commande pour la requête suivante.
- Overwrite reconstruit la table de staging à chaque exécution, sans lignes périmées.
Étape 2 : joindre la petite table de staging à la table clients. Data extension cible : Recent_Buyers_Audience, clé primaire SubscriberKey, type de mise à jour Overwrite.
SELECT c.SubscriberKey,
c.EmailAddress,
s.LastOrderDate
FROM Customers_Master c
INNER JOIN Recent_Buyers_Stage s
ON s.SubscriberKey = c.SubscriberKey
WHERE c.EmailAddress IS NOT NULL- La jointure porte sur SubscriberKey, présent dans les deux data extensions avec le même type de données.
- Seules trois colonnes sont renvoyées, ce qui garde la table d'audience étroite.
- Le filtre sur EmailAddress écarte les lignes que vous ne pourriez de toute façon pas contacter.
- Exécutez chaque requête dans sa propre étape Automation Studio, l'une après l'autre, pour qu'elles ne se disputent pas les ressources.
Répartir une requête géante en plusieurs lots
Si même la requête de staging reste trop lourde, répartissez les abonnés en groupes à l'aide d'une valeur stable comme SubscriberKey. La même requête s'exécute trois fois avec une condition en plus, et chaque passage traite environ un tiers des lignes.
SELECT c.SubscriberKey,
c.EmailAddress
FROM Customers_Master c
INNER JOIN Recent_Buyers_Stage s
ON s.SubscriberKey = c.SubscriberKey
WHERE ABS(CHECKSUM(c.SubscriberKey)) % 3 = 0- CHECKSUM transforme SubscriberKey en un nombre qui ne change pas d'une exécution à l'autre.
- ABS rend ce nombre positif, et le modulo 3 renvoie 0, 1 ou 2.
- Lancez d'abord la version qui se termine par 0 en Overwrite, puis les versions 1 et 2 en Update ou Append vers la même cible.
- Data extension cible : Recent_Buyers_Audience, clé primaire SubscriberKey.
Le choix du mode d'écriture est important ici, et notre guide Overwrite, Update ou Append dans SFMC précise quand chacun est sûr.
Réponse rapide : checklist contre le timeout SFMC
Déroulez ces points dans l'ordre. Les trois premiers règlent la plupart des cas.
- Retirez les fonctions de la clause WHERE et comparez la colonne brute à une plage calculée.
- Réduisez la fenêtre de dates au strict besoin de l'audience, idéalement six mois ou moins.
- Sélectionnez des colonnes nommées plutôt que SELECT *.
- Ne joignez que des champs de même type de données, avec une clé primaire claire sur les data extensions.
- Agrégez les tables lourdes dans une data extension de staging avant la jointure finale.
- Placez chaque activité de requête dans sa propre étape et décalez les heures de lancement des automatisations.
- Répartissez les très gros traitements en lots avec une condition CHECKSUM et modulo.
Pour concevoir des data extensions qui gardent des jointures rapides, consultez nos bonnes pratiques pour les data extensions SFMC.
Questions fréquentes
Peut-on augmenter le timeout d'une requête SQL SFMC ?
Non. La limite de 30 minutes est fixe, le seul levier est donc de réduire le travail de la requête. Le staging, les lots et de meilleurs filtres sont les voies pratiques.
Pourquoi ma requête passe dans Query Studio mais échoue dans Automation Studio ?
Automation Studio exécute la requête sur l'ensemble des données et écrit tout le résultat dans la data extension cible. Des automatisations, envois et imports simultanés sur les mêmes données peuvent aussi la ralentir par rapport à un test réalisé à un moment calme.
SELECT * provoque-t-il des timeouts ?
Il peut y contribuer, surtout sur des data extensions larges, car chaque colonne doit être lue et écrite. Ne nommer que les colonnes utiles est une amélioration peu coûteuse, et fait partie des conseils d'optimisation de Salesforce.
Que se passe-t-il si une activité de requête échoue en boucle ?
Salesforce désactive une activité SQL Query après 24 échecs consécutifs, et ce comportement ne peut pas être désactivé. Corrigez la requête et réactivez-la avant d'atteindre ce seuil.
Créez cette audience en quelques secondes avec QAiry
Régler jointures, tables de staging et conditions de lots est le genre de travail qui mange une après-midi. QAiry transforme une demande en langage naturel en SQL SFMC prêt pour la production et en data extension associée, installé comme une application dans votre propre SFMC : vous partez d'une requête saine plutôt que d'un éditeur vide.
Vous pouvez essayer QAiry gratuitement ou regarder les démos produit pour voir le fonctionnement sur une vraie demande.
