O aumento da latência da rede causará bloqueios de tabela no MS SQL Server?

Se o cliente demorar muito para receber os dados e, por sua vez, enviar ao SQL Server a confirmação de que recebeu os dados, o SQL Server terá que esperar, devido a essa espera, o SQL Server não liberará os bloqueios mantidos pela consulta, a menos que a confirmação seja recebida do cliente.

Isso não é preciso, depende do nível de isolamento.

No padrão, os READ COMMITTEDbloqueios não são mantidos durante a execução das instruções. READ COMMITTEDnão fornece consistência de leitura em nível de instrução, a única garantia é que você não pode ler dados não confirmados. Um bloqueio compartilhado é adquirido e mantido para ler a linha e, em seguida, liberado.

A menos que você tenha tipos de LOB.

Os tipos LOB, sendo potencialmente muito grandes, não podem ser armazenados em buffer. Um bloqueio compartilhado deve ser adquirido e mantido até que a instrução seja concluída, essencialmente dando a você o REPEATABLE READcomportamento em READ COMMITTED.

Se eu estiver fazendo uma única chamada para um banco de dados MSSQL em uma rede de alta latência, ocorrerão bloqueios de tabela devido a essa latência?

A latência não está causando o travamento da mesa, não. No entanto, se um bloqueio de tabela foi adquirido, a latência irá prolongá-lo.

Para citar alguém que conhece a mecânica disso melhor do que eu ( @RemusRusanu ):

Os resultados são devolvidos ao programa cliente à medida que a execução prossegue. À medida que as linhas 'borbulham' na árvore de execução, o operador principal geralmente recebe a tarefa de gravar essas linhas em buffers de rede e enviá-las de volta ao cliente. O resultado não é criado primeiro em algum armazenamento intermediário (memória ou disco) e depois enviado de volta ao cliente, em vez disso, é enviado de volta conforme está sendo criado (conforme a consulta é executada). O envio do resultado de volta ao cliente está, obviamente, sujeito ao protocolo de controle de fluxo de rede. Se o cliente não estiver consumindo ativamente o resultado (por exemplo, chamando SqlDataReader.Read()), eventualmente o controle de fluxo terá que bloquear o lado de envio (a consulta que está sendo executada) e isso, por sua vez, suspenderá a execução do consulta.[fonte]

Onde os resultados não são consumidos tão rapidamente quanto o SQL Server pode entregá-los, seja devido ao cliente ou à rede, vemos ASYNC_NETWORK_IOesperas se acumulando. Para reiterar, isso não influenciará os bloqueios adquiridos, apenas a duração em que são mantidos.

A resposta de Mark esclareceu muito da minha confusão, mas gostaria de postar minhas descobertas depois de testar isso usando o NetBalancer para emular a latência.

Fiz minha máquina local chamar um servidor SQL remoto e executar SELECTs e INSERTs em uma tabela dentro de uma pequena transação. Na máquina remota, conectei-me à instância SQL local e usei um loop WHILE para iterar repetidamente na tabela sys.dm_tran_locks, procurando por bloqueios na tabela que estava modificando e lendo. Instalei o NetBalancer no servidor e o usei para emular a latência de rede na conexão de rede do servidor.

Aqui está o que eu encontrei:

• Para instruções que não retornam muitos dados ao cliente, a latência não afeta o bloqueio. Eu estava retornando apenas algumas centenas de bytes de dados, no máximo. A transação na minha máquina tinha um WAITFOR de 250ms que mantinha os bloqueios e, quando aumentei a latência da rede para 5000ms, a duração do bloqueio ficou próxima a 250ms.
• Para instruções que retornam muitos dados, a latência definitivamente afeta o bloqueio . Devolvi dezenas de milhares de linhas ao cliente e, sem latência, a duração do bloqueio foi curta. Quando aumentei a latência, os bloqueios continuaram até receber todos os dados.

A partir disso, estou concluindo que a latência não importa, desde que os dados caibam no buffer de rede. Se o SQL tiver que colocar muitos dados no buffer de rede, a latência fará com que o buffer faça backup e o SQL manterá os bloqueios da tabela até que possa colocar todos os resultados da consulta no buffer.

Se eu estiver fazendo uma única chamada para um banco de dados MSSQL em uma rede de alta latência, ocorrerão bloqueios de tabela devido a essa latência?

Quando uma consulta é disparada e concluída pelo SQL Server, ela produz os resultados, coloca-a no buffer de saída e a envia ao cliente, que busca o resultado no buffer de saída. O SQL Server não liberará os bloqueios mantidos pela consulta, a menos que a confirmação seja recebida do cliente. O que pode causar bloqueio.

Editar: Evan, você pode consultar este artigo de suporte do MS

Na seção 3

Bloqueio causado por um SPID cujo aplicativo cliente correspondente não buscou todas as linhas de resultado até a conclusão

Depois de enviar uma consulta ao servidor, todos os aplicativos devem buscar imediatamente todas as linhas de resultado até a conclusão. Se um aplicativo não buscar todas as linhas de resultado, bloqueios podem ser deixados nas tabelas, bloqueando outros usuários. Se você estiver usando um aplicativo que envia instruções SQL de forma transparente ao servidor, o aplicativo deve buscar todas as linhas de resultado. Caso contrário (e se não puder ser configurado para isso), talvez você não consiga resolver o problema de bloqueio. Para evitar o problema, você pode restringir aplicativos mal-comportados a um relatório ou banco de dados de suporte à decisão.