Esta é a pergunta 1 de 2 relacionada aOPTION (FAST 1);
Acabamos de atualizar nosso banco de dados ERP de SQL 2000 EE para 2008 R2 EE e notamos um aumento no bloqueio do banco de dados. Reduzi ao que acredito ser a declaração ofensiva no código do fornecedor, que é:
SELECT MAX(column)
FROM [table]
WHERE <condition>
OPTION (FAST 1);
O spid deixa uma transação aberta e trava na mesa, bloqueando todos os outros clientes. No entanto, o cliente chamador não parece mais estar interagindo com o servidor para informar ao servidor que recebeu os dados para encerrar a sessão.
Lendo a documentação sobre Query Hints , vi esta declaração
FAST number_rows
Especifica que a consulta é otimizada para recuperação rápida das primeiras number_rows. Este é um número inteiro não negativo. Depois que os primeiros number_rows são retornados, a consulta continua a execução e produz seu conjunto de resultados completo.
Isso me faz pensar se o cliente quebrou a comunicação de alguma forma, o servidor manteria a transação aberta, processando o conjunto de resultados completo após as primeiras nlinhas serem retornadas e deixando a transação aberta? O processo é um processo interno, então não posso realmente assistir a um usuário final executar a sessão para fazer isso, e isso não é algo que acontece toda vez que o processo interno ocorre. No entanto, ele é usado apenas pelo processo interno.
Depois de ler a resposta de Remus no SO, parece um exagero pela simplicidade da consulta. Olhando para a consulta, se eles estão recebendo mais de um resultado de um desagrupado MAX, então algo é muito suspeito.
Portanto, enquanto me preparo para trabalhar com o fornecedor, gostaria de saber se poderia começar a atribuir com precisão nossos problemas de bloqueio ao fato de que essa dica de consulta está sendo usada.
Sinta-se à vontade para editar/solicitar edições, pois sei que isso pode não estar claro.
Se fosse uma consulta que retornasse mais de 1 linha, eu especularia que alguém do fornecedor (há muito tempo, dada a versão do SQL Server) tropeçou no otimizador de consulta produzindo um plano preferível quando
FASTfoi especificado como uma dica.Como está retornando apenas 1 linha, a explicação provavelmente tem mais em comum com o teorema do macaco infinito do que com um julgamento fundamentado. Um júnior viu uma dica
FASTe decidiu que era preferível que sua consulta não fosse rápida.A consulta retorna 1 linha, portanto, não há mais resultados definidos para processar. Estou inclinado a suspeitar que há outro código mais acima na pilha que está causando o problema.