APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Query Store mantém informação de consultas, planos e execução que ajuda a comparar comportamento antes e depois de uma mudança. Usa janelas com volume e concorrência comparáveis. O custo estimado do plano não é duração em milissegundos. Verifica também a saúde da recolha: desired_state READ_WRITE pode coexistir com actual_state READ_ONLY se um limite ou outra condição impedir novas observações. Consulta readonly_reason e o consumo antes de alterar retenção ou capacidade. Não apagues toda a história precisamente quando precisas de explicar uma regressão. Automatic tuning pode corrigir planos e verificar efeitos; as opções disponíveis diferem entre SQL Database e Managed Instance.
Aplicação guiada
Num fecho fictício, muitas sessões aguardam uma transação longa. Identifica o head blocker, o owner e o código antes de terminar sessões. Rollback e retries podem prolongar impacto. Deadlock é diferente de uma espera comum: existe uma dependência circular e o motor escolhe uma vítima, frequentemente comunicada pelo erro 1205. Analisa o grafo e a ordem de acesso aos recursos, mantendo transações curtas e consistentes onde apropriado. Retry pode ser parte da resposta, mas precisa de reconhecer transação anulada, estado confirmado e efeitos externos. O relatório do incidente deve distinguir causa observada, mitigação aplicada, tempo de recuperação e ação para evitar repetição.
desired_state=READ_WRITE, actual_state=READ_ONLY: confirmar a causa efetiva antes de confiar na ausência de novas amostras.
Armadilhas comuns
Sem amostras como saudável; plano forçado como ótimo permanente; bloqueio como deadlock; kill sem avaliar rollback.
Tópicos relacionados: Plataforma, capacidade e migração · Identidade, rede e cifragem · Dados sensíveis e evidência
A saúde da telemetria faz parte do diagnóstico.
Referência: Query Store history and plans · DP-300 English objectives effective 2026-04-24