Query Activity que estoura os 30 minutos e para a automação

Em uma frase: a Query Activity tem limite de 30 minutos de execução, e uma consulta escrita sem pensar no volume estoura esse limite à medida que as Data Extensions crescem.

Ninguém escreve uma query que demora 30 minutos de propósito. Ela nasce rápida, com uma DE de origem pequena, e fica lenta aos poucos. Um dia a automação para com erro de tempo esgotado, e normalmente é o dia de maior volume.

Por que é um erro médio

Diferente do Overwrite sem staging, aqui a falha é visível: a atividade termina com erro e a automação para. Nenhum dado é apagado, e quem configurou notificação de erro fica sabendo. Por isso não é crítico.

Também não é comum, porque a correção raramente é trivial. Ela exige entender por que a consulta ficou cara, e a resposta costuma envolver o desenho dos dados, não só a sintaxe do SQL. E o erro tende a voltar: se a causa é crescimento, a query consertada hoje estoura de novo daqui a alguns meses.

Como identificar e depurar

O histórico do Automation Studio mostra a duração de cada execução. Uma query que passou de 5 para 15 e depois para 25 minutos está avisando antes de falhar. Vale olhar essa tendência nas queries que alimentam envios diários.

Na consulta, os suspeitos de sempre:

• Data Views lidas por inteiro. _Sent, _Open e _Click guardam meses de eventos da conta toda. Uma query que não filtra por data logo de início varre tudo isso a cada execução. O guia de Data Views no SQL mostra o filtro por período.
• JOIN entre duas DEs grandes sem filtro prévio. Cada lado traz milhões de linhas e a junção multiplica o trabalho.
• Funções na coluna do JOIN ou do WHERE. LOWER(Email) = LOWER(...) dos dois lados impede o aproveitamento da chave e força comparação linha a linha.
• Uma query fazendo o trabalho de três. Subconsultas aninhadas com várias junções e agregações num passo só.

O caminho de investigação é reduzir a consulta até ela ficar rápida e ir adicionando as partes de volta, medindo. Quase sempre aparece um trecho responsável pela maior parte do tempo. A solução estrutural costuma ser quebrar o processo em etapas, com DEs intermediárias já filtradas, e manter a retenção das DEs de origem sob controle.

Impactos reais na organização

• Envio do dia que não sai. A query para, o passo de envio não roda, e a campanha do dia é perdida ou sai fora de horário.
• Plantão de madrugada. Automações noturnas que falham viram chamada fora do expediente para quem cuida da conta.
• Retrabalho recorrente. Sem tratar a causa, o time ajusta a mesma query a cada poucos meses.
• Dados desatualizados em cascata. Outras automações que dependem da DE gerada por essa query passam a trabalhar com informação de ontem, ou de anteontem.