Não estou tentando iniciar uma discussão do tipo windows / mac.
Pessoalmente, não preciso de convencimento de que NOLOCK
não seja uma boa ideia como prática reflexiva. Parece que quando você está desenvolvendo tudo deve ter um propósito, não reacionário (/ amém)
Então ... o programador encarregado insiste NOLOCK
é o caminho a percorrer. Recomenda com todas as consultas ad-hoc e sempre que consultar a produção. Eu não vi um procedimento armazenado sem dicas de nolock em todas as tabelas.
Não quero ser aquele cara que entra e diz a todos que uma crença central está errada sem algo para sustentar isso.
Basta olhar para as sessões de comentários nas várias postagens do blog, o envio de um link pode não ser suficiente. Crenças antigas etc ... Algumas pessoas não estão convencidas de que é um problema. Veja: Seção de comentários em todas as postagens do blog nolock que eu li.
Atualmente, alguns outros DBAs estão lutando com um impasse misterioso. Como se determina se NOLOCKs são a fonte?
Foi sugerido examinar XML de rastreamentos etc., mas isso não indica explicitamente que os impasses estão causando o problema, certo? Eu nunca vi mensagens de erro tão simples. isso é verdade?
De que outra forma esses impasses poderiam ser fixados nisso?
Instruções DDL como CREATE
seria uma pista. Existe alguma saída que eu possa apontar ou algum dado que eu possa encontrar que ajude a corroborar minha teoria antes de eu acionar o alarme?
Ou estou executando sinalizadores de rastreamento ou eventos estendidos para identificar o que está executando quando ocorrem os conflitos e deduzindo das instruções DDL?
Observando todas as diferentes maneiras pelas quais os dados podem ser confundidos com dicas nolock, parece um problema difícil de definir de maneira decisiva.