Início / dba / Perguntas / 341081
Accepted
Jerry.Chen
Asked: 2024-07-22 17:05:43 +0800 CST

Quando o bloqueio de página ocorre no nível de isolamento de leitura confirmada no SQL Server

  • 772

Eu tenho uma tabela de índice clusterizada no Banco de Dados SQL do Azure. Depois de verificar dm_db_index_operative_stats, a coluna page_lock_wait_count maior que 0 significa que houve algum bloqueio de página para isso antes, mas nenhum row_lock_wait_count registrado como na foto abaixo. de dm_db_index_operacional_stats

Tento simular esse cenário no SQL Server 2019. Defina o nível de transação como Read Committed Snapshot em meu ambiente de banco de dados de teste, igual ao Azure SQL. Mas só consigo situações abaixo do bloqueio.

  1. Comece a transação A, para atualizar algumas linhas na tabela T. Comece a transação B para atualizar linhas semelhantes na tabela. O tipo de recurso de bloqueio em espera da transação B é KEY em dm_tran_locks.
  2. Comece a transação A, para atualizar várias linhas na tabela T. Comece a transação B para atualizar também uma grande quantidade de linhas na tabela. O tipo de recurso de espera é OBJECT para a transação B, uma vez que a transação A mantém o modo X de OBJECT, acho que isso ocorre porque o bloqueio foi escalado. Tentei os cenários acima muitas vezes em meu ambiente de teste. Como a transação A causará o bloqueio da página IX, row_lock_count/row_lock_wait_count/page_lock_count aumentará, mas nenhum page_lock_wait_count ocorreu.

Pergunta:

  1. Por que page_lock_wait_count pode ser maior que 0 quando row_lock_wait_count=0?
  2. Quais condições ou cenários causarão espera de bloqueio de página?
sql-server

1 respostas

  1. Best Answer
    1. Por que page_lock_wait_count pode ser maior que 0 quando row_lock_wait_count=0?

    Eles estão medindo duas coisas diferentes e muitas vezes independentes.

    Um processo que solicita um bloqueio de linha e descobre que ele precisa esperar será incrementado row_lock_wait_count.
    Um processo solicitando um bloqueio de página e descobrindo que ele precisa esperar será incrementado page_lock_wait_count.

    Cada acesso aos dados começa com o mecanismo de armazenamento tomando uma decisão sobre qual granularidade de bloqueio usar. Ele pode decidir começar com bloqueio em nível de linha, página ou até mesmo em nível de objeto.

    Você pode influenciar essa decisão com dicas como ROWLOCK, PAGLOCKe TABLOCK. Caso contrário, o mecanismo toma sua própria decisão com base em vários metadados no momento da execução. Uma recompilação do plano não é necessária para que o mecanismo mude de idéia sobre o bloqueio da granularidade entre as execuções do mesmo plano.

    Um processo que acessa dados sob bloqueio em nível de página pode aumentar, page_lock_wait_countmas nunca aumentará row_lock_wait_countporque nunca tenta adquirir bloqueios nessa granularidade.

    Além da atividade do usuário, também existem processos do sistema que operam apenas na granularidade de bloqueio no nível da página, como a reorganização do índice.

    1. Quais condições ou cenários causarão espera de bloqueio de página?

    Sempre que um processo solicita um bloqueio de página incompatível com outro bloqueio de página já mantido por outro processo. Deve haver um milhão de possibilidades.

    Um problema comum ( em RCSI ) seria quando dois processos simultâneos estivessem usando Ubloqueios update() na mesma tabela com granularidade de página . Nenhum dos processos pode concluir o escalonamento de bloqueio com êxito porque o outro já possui um bloqueio incompatível na tabela.

    Observe que o escalonamento de bloqueio só é escalado para o nível de partição ou objeto. Os bloqueios nunca passam da granularidade da linha para a granularidade da página, por exemplo.

    • 4

relate perguntas