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.
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.
- 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.
- 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:
- Por que page_lock_wait_count pode ser maior que 0 quando row_lock_wait_count=0?
- Quais condições ou cenários causarão espera de bloqueio de página?