Contagem de seleção do SQL Server READ_COMMITTED_SNAPSHOT QUESTION

Parece que estou recebendo muitos impasses ao fazer select count (*) em uma tabela específica. Eu já alterei todos os parâmetros necessários e os transformei em bloqueio apenas de linha.

Também alterei o banco de dados para usar o isolamento READ_COMMITTED_SNAPSHOT,

no entanto, parece que usando uma contagem de seleção (*) em que coluna =? na mesa aciona impasses ou travas na mesa.

Estou certo de que a contagem de seleção (*) deve estar acessando apenas linhas intermediárias ?, no entanto, não parece assim e ainda estou encontrando impasses. A indexação adequada provavelmente ajudaria,

A pergunta é: O SQL Server 2008 R2 coloca um bloqueio compartilhado na tabela durante a contagem de seleção (*) mesmo quando o read_committed_snapshot está ativado?

obrigado

— grassbl8d
fonte

Você precisa de uma contagem exata (conforme a solicitação) ou uma contagem aproximada está correta?

— Jon Seigel

na verdade, só preciso saber se estão sendo colocados bloqueios compartilhados. Estou tentando investigar um problema de impasse. Graças

— grassbl8d

Meu argumento foi que, se você pode considerar alterar a maneira como a contagem é obtida, esse pode ser o caminho para resolver o problema do impasse. Mas agora que li a pergunta novamente, se você precisar usar uma WHEREcláusula, o método em que estou pensando não funcionará de qualquer maneira.

— quer

Você pode obter contagens aproximadas das tabelas de metadados para um subconjunto da tabela se a cláusula where corresponder a um índice filtrado.

— Aaron Bertrand

Respostas:

Cuidado com o READ_COMMITTED_SNAPSHOT: se você o ativar, poderá causar muitos bugs sutis.

Também READ_COMMITTED_SNAPSHOT é o nível de isolamento padrão, que pode ser substituído por algo. Execute USEROPTIONS do DBCC para determinar o nível de isolamento real em que o seu select é executado.

Eu explicaria o INSTANTÂNEO DO NÍVEL DA ISOLAÇÃO DA TRANSAÇÃO imediatamente antes da sua seleção. Dessa forma, você terá certeza de que o seu select nunca será aceito em impasses e não quebrará nenhum outro código, como READ_COMMITTED_SNAPSHOT.

— AK
fonte

O bloqueio com isolamento de instantâneo não muda. O que muda é que, quando as páginas estão sendo alteradas sob você, essas páginas são copiadas para o banco de dados tempdb, para que você possa lê-las no banco de dados tempdb, e não no banco de dados normal. (Sim, esta é uma versão simplificada do que está acontecendo.)

Você mencionou que não possui uma indexação adequada, portanto, está fazendo uma verificação de índice em cluster (ou uma verificação de tabela, se for um monte). São potencialmente muitos dados a serem movidos para o banco de dados tempdb. Se essa consulta for algo que será executado mais de uma vez, sugiro adicionar o índice à tabela.

Qual nível de isolamento sua consulta está usando?

— Mrdenny
fonte

Estou usando o nível de isolamento read_commited_snapshot. Liguei-o como eu estou usando o read_committed por padrão. Só estou interessado se bloqueios estão sendo colocados durante contagens selecionadas. Obrigado, eu já coloquei os índices btw

— grassbl8d

Sim, os bloqueios ainda estão sendo executados. Você pode consultar sys.dm_tran_locks para ver os bloqueios que estão sendo executados. Execute sua consulta em uma janela e consulte sys.dm_tran_locks em outra janela para ver quais bloqueios estão sendo executados. Você pode estar escalando para bloqueios de tabela e precisa usar uma dica para forçar bloqueios de página ou mesmo de linha.

— mrdenny