Bloqueio otimizado

Aplica-se a: SQL Server 2025 (17.x) Azure SQL Database AzureSQL Managed Instance SQL database in Microsoft Fabric

O bloqueio otimizado oferece um mecanismo de bloqueio de transações aprimorado para reduzir o bloqueio e o consumo de memória de bloqueio em transações simultâneas.

O que é o bloqueio otimizado?

O bloqueio otimizado ajuda a reduzir a memória de bloqueio, pois muito poucos bloqueios são mantidos, mesmo para transações grandes. Além disso, o bloqueio otimizado evita escalonamentos de bloqueio e pode evitar certos tipos de deadlocks. Isso permite mais acesso simultâneo à tabela.

O bloqueio otimizado é composto por dois componentes principais: bloqueio de ID de transação (TID) e bloqueio após qualificação (LAQ) .

Um ID de transação (TID) é um identificador exclusivo de uma transação. Cada linha é rotulada com a última TID que a modificou. Em vez de muitos bloqueios de chaves ou identificadores de linha, utiliza-se um único bloqueio no TID para proteger todas as linhas modificadas. Para obter mais informações, consulte bloqueio de ID de transação (TID).
Bloqueio após qualificação (LAQ) é uma otimização que avalia predicados de consulta usando a versão confirmada mais recente da linha sem adquirir um bloqueio, melhorando assim a simultaneidade. O LAQ requer isolamento de instantâneo com leitura comprometida (RCSI). Para obter mais informações, consulte Bloqueio após qualificação (LAQ).

Por exemplo:

Sem bloqueio otimizado, a atualização de 1.000 linhas em uma tabela pode exigir 1.000 bloqueios de linha exclusivos (X) mantidos até o final da transação.
Com bloqueios otimizados, atualizar 1.000 linhas numa tabela pode exigir 1.000 X bloqueios de linha, mas cada bloqueio é libertado assim que cada linha é atualizada, e apenas um X bloqueio TID é mantido até ao final da transação. Como os bloqueios são liberados rapidamente, o uso de memória de bloqueio é reduzido e o escalonamento de bloqueio é muito menos provável de ocorrer, melhorando a concorrência da carga de trabalho.

Note

A habilitação do bloqueio otimizado reduz ou elimina os bloqueios de linha e página adquiridos pelas instruções DML (Data Modification Language), como INSERT, UPDATE, DELETEMERGE. Não tem efeito sobre outros tipos de bloqueios de banco de dados e objeto, como os bloqueios de esquema.

Availability

A tabela seguinte resume a disponibilidade e o estado habilitado do bloqueio otimizado entre plataformas SQL.

Platform	Available	Ativado por padrão
Base de Dados SQL do Azure	Yes	Sim (sempre ativado)
Banco de dados SQL no Microsoft Fabric	Yes	Sim (sempre ativado)
Instância Gerenciada SQL do Azure^AUTD	Yes	Sim (sempre ativado)
Instância Gerenciada SQL do Azure²⁰²⁵	Yes	Sim (sempre ativado)
Instância Gerenciada SQL do Azure²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	Não (pode ser ativado por banco de dados)
SQL Server 2022 (16.x) e versões mais antigas	No	N/A

Ativar e desativar

Para habilitar ou desabilitar o bloqueio otimizado para um banco de dados do SQL Server, use o ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF comando. Para obter mais informações, consulte as opções ALTER DATABASE SET.

O bloqueio otimizado baseia-se em outros recursos de banco de dados:

Você deve habilitar a recuperação acelerada de banco de dados (ADR) em um banco de dados antes de habilitar o bloqueio otimizado. Por outro lado, para desativar o ADR, você deve desativar o bloqueio otimizado primeiro se ele estiver habilitado.
Para obter o máximo benefício do bloqueio otimizado, de isolamento de instantâneo confirmado de leitura confirmada (RCSI) deve ser habilitada para o banco de dados. O componente LAQ do bloqueio otimizado só estará em vigor se o RCSI estiver ativado.

O ADR está sempre ativado no Azure SQL Database, Azure SQL Managed Instance e SQL Database no Microsoft Fabric. O RCSI está ativado automaticamente no Azure SQL Database e na base de dados SQL no Microsoft Fabric.

Para verificar se essas opções estão habilitadas para seu banco de dados atual, conecte-se ao banco de dados e execute a seguinte consulta T-SQL:

SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_read_committed_snapshot_on,
       is_optimized_locking_on
FROM sys.databases
WHERE name = DB_NAME();

O bloqueio otimizado está ativado?

O bloqueio otimizado está ativado por base de dados. Conecte-se ao banco de dados e use a seguinte consulta para verificar se o bloqueio otimizado está habilitado:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

Result	Description
`0`	O bloqueio otimizado está desativado.
`1`	O bloqueio otimizado está ativado.
`NULL`	O bloqueio otimizado não está disponível.

Você também pode usar a exibição de catálogo sys.databases . Por exemplo, para ver se o bloqueio otimizado está habilitado para todos os bancos de dados, execute a seguinte consulta:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Visão geral do bloqueio

Este é um breve resumo do comportamento quando o bloqueio otimizado não está ativado. Para obter mais informações, consulte o guia de bloqueio de transações e versionamento de linhas.

No mecanismo de banco de dados, o bloqueio é um mecanismo que impede que várias transações atualizem os mesmos dados simultaneamente, a fim de garantir o ACID propriedades das transações.

Quando uma transação precisa modificar dados, ela solicita um bloqueio nos dados. O bloqueio é concedido se nenhum outro bloqueio conflitante for mantido nos dados, e a transação pode prosseguir com a modificação. Se outro bloqueio conflitante for mantido nos dados, a transação deverá aguardar que o bloqueio seja liberado antes de poder prosseguir.

Quando várias transações tentam acessar os mesmos dados simultaneamente, o mecanismo de banco de dados deve resolver conflitos potencialmente complexos com leituras e gravações simultâneas. O bloqueio é um dos mecanismos pelos quais o motor pode fornecer a semântica para os níveis de isolamento da transação ANSI SQL . Embora o bloqueio em bases de dados seja essencial, a redução da concorrência, deadlocks, complexidade e sobrecarga de bloqueio podem afetar o desempenho e a escalabilidade.

Bloqueio de ID de transação (TID)

Quando controle de versão de linha níveis de isolamento baseados estão em uso ou quando o ADR está habilitado, cada linha no banco de dados contém internamente uma ID de transação (TID). O TID mantém-se na disputa. Cada transação que modifica uma linha carimba a linha com o seu TID.

Com o bloqueio TID, em vez de ser feito sobre a chave da linha, o bloqueio é realizado sobre o TID da linha. A transação de modificação mantém um bloqueio de X sobre o seu TID. Outras transações adquirem um bloqueio S no TID para esperar até que a primeira transação seja concluída. Com o bloqueio TID, os bloqueios de página e linha continuam a ser feitos para modificações, mas cada bloqueio de página e linha é liberado assim que cada linha é modificada. O único bloqueio mantido até ao final da transação é o bloqueio único X no recurso TID, substituindo vários bloqueios de página e de linha (chave).

Considere o exemplo seguinte que mostra bloqueios para a sessão atual enquanto uma transação de escrita está ativa.

/* Is optimized locking is enabled? */
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

CREATE TABLE t0
(
a int PRIMARY KEY,
b int NULL
);

INSERT INTO t0 VALUES (1,10),(2,20),(3,30);
GO

BEGIN TRANSACTION;

UPDATE t0
SET b = b + 10;

SELECT *
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
      AND
      resource_type IN ('PAGE','RID','KEY','XACT');

COMMIT TRANSACTION;
GO

DROP TABLE IF EXISTS t0;

Se o bloqueio otimizado estiver habilitado, a solicitação manterá apenas um único bloqueio de X no recurso XACT (transação).

Se o bloqueio otimizado não estiver habilitado, a mesma solicitação manterá quatro bloqueios - um bloqueio IX (exclusivo de intenção) na página que contém as linhas e três X bloqueios de chave em cada linha:

A sys.dm_tran_locks vista de gestão dinâmica (DMV) é útil para examinar ou resolver problemas de bloqueio. Aqui é usado para observar o bloqueio otimizado em ação.

Bloqueio após qualificação (LAQ)

Com base na infraestrutura TID, o componente LAQ do bloqueio otimizado altera a forma como as instruções DML, como INSERT, UPDATEe DELETE adquirem bloqueios.

Sem bloqueio otimizado, os predicados de consulta são verificados linha por linha durante uma análise, começando com a obtenção de um bloqueio de linha de atualização (U). Se o predicado for satisfeito, um bloqueio de linha exclusivo (X) é feito antes de atualizar a linha e mantido até o final da transação.

Com bloqueios otimizados, e quando o READ COMMITTED nível de isolamento de snapshots (RCSI) está ativado, os predicados podem ser verificados de forma otimista na versão mais recente da linha comprometida sem aceitar quaisquer bloqueios. Se o predicado não satisfizer, a consulta será movida para a próxima linha da verificação. Se o predicado for satisfeito, um bloqueio de linha X será usado para atualizar a linha.

Em outras palavras, o bloqueio é realizado após a qualificação da linha para modificação. O bloqueio de linha X é liberado assim que a atualização da linha é concluída, antes do final da transação.

Como a avaliação de predicados é realizada sem adquirir bloqueios, consultas simultâneas modificando linhas diferentes não bloqueiam umas às outras.

Por exemplo:

/* Confirm that optimized locking and read committed snapshot isolation (RCSI) are both enabled on this database. */
SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_optimized_locking_on,
       is_read_committed_snapshot_on
FROM sys.databases
WHERE name = DB_NAME();

CREATE TABLE t1
(
a int NOT NULL,
b int NULL
);

INSERT INTO t1
VALUES (1,10),(2,20),(3,30);
GO

Sessão 1	Sessão 2
`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Sem bloqueamento otimizado, a sessão 2 é bloqueada porque a sessão 1 mantém um bloqueio de U na linha que a sessão 2 precisa atualizar. No entanto, com o bloqueio otimizado, a sessão 2 não é bloqueada porque não são aplicados bloqueios de U e porque, na versão mais recente confirmada da linha 1, a coluna a é igual a 1, o que não atende o predicado da sessão 2.

O LAQ é realizado de forma otimista no pressuposto de que uma linha não é modificada após a verificação do predicado. Se o predicado for satisfeito e a linha não tiver sido modificada após essa verificação, ela será modificada pela transação atual.

Como os U bloqueios não são tomados, uma transação concorrente pode modificar a linha depois de o predicado ter sido avaliado. Se houver uma transação ativa que esteja a manter um bloqueio TID na linha, o mecanismo de banco de dados aguardará que ela seja concluída. Se a linha tiver mudado depois de o predicado ter sido avaliado anteriormente, o motor da base de dados reavalia (requalifica) o predicado novamente antes de modificar a linha. Se o predicado ainda estiver satisfeito, a linha será modificada.

A requalificação de predicados é suportada por um subconjunto dos operadores do motor de consulta. Caso seja necessária uma reavaliação de predicados, mas o plano de consulta utilize um operador que não suporte a requalificação de predicados, o motor de base de dados interrompe internamente o processamento da instrução e reinicia-o sem LAQ. Quando esse abortamento ocorre, o evento lock_after_qual_stmt_abort estendido é acionado.

Algumas instruções, por exemplo UPDATE , instruções com atribuição variável e instruções com a cláusula OUTPUT , não podem ser abortadas e reiniciadas sem alterar sua semântica. Para declarações desse tipo, o LAQ não é utilizado.

No exemplo a seguir, o predicado é reavaliado porque outra transação alterou a linha:

CREATE TABLE t3
(
a int NOT NULL,
b int NULL
);

INSERT INTO t3 VALUES (1,10),(2,20),(3,30);
GO

Sessão 1	Sessão 2
`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Saltar bloqueios de índice (SIL)

Com o bloqueio TID, são usados bloqueios de linha exclusivos de curta duração (X) e bloqueios de página exclusivos por intenção (IX) para modificar linhas. Quando são usados RCSI e LAQ, estes bloqueios só são necessários se houver outras consultas que acedem à linha e esperam que esta permaneça estável. Exemplos dessas consultas são aquelas que executam sob os níveis de isolamento REPEATABLE READ ou SERIALIZABLE, ou que utilizam as sugestões de bloqueio correspondentes. Estas consultas são conhecidas como consultas de bloqueio de linhas (RLQ).

Quando não há consultas RLQ a aceder a uma linha, o motor da base de dados pode evitar tomar bloqueios de linha e página ao modificar uma linha, e usar apenas um latch exclusivo de página. Esta otimização reduz a sobrecarga de bloqueio enquanto preserva a semântica das transações ACID. Evitar bloqueios de linhas e páginas beneficia particularmente as transações que modificam um grande número de linhas.

Atualmente, a otimização SIL é utilizada apenas nos seguintes casos:

INSERT Declarações em montes.
- IX Os bloqueios de página são ignorados.
UPDATE declarações sobre índices agrupados, índices não agrupados e heaps.
- IX Bloqueios de página e X bloqueios de linha são ignorados.

A otimização SIL atualmente não é utilizada nos seguintes casos:

DELETE declarações.
UPDATE instruções nos heaps se a linha contiver ponteiros de encaminhamento existentes ou se novos ponteiros de encaminhamento forem adicionados pela atualização.
Se a linha modificada tiver quaisquer colunas que usem os tipos de dados LOB, como varchar(max), nvarchar(max), varbinary(max), e json.
Para linhas em páginas que foram divididas na mesma transação.

Heurística LAQ

Como descrito em Lock after qualification (LAQ), quando é usado LAQ, instruções que usam operadores de consulta que não suportam requalificação por predicados podem ser reiniciadas internamente e processadas sem LAQ. Se isto acontecer frequentemente, a sobrecarga do reprocessamento pode tornar-se significativa. Para minimizar a sobrecarga, o bloqueio otimizado utiliza um mecanismo de feedback baseado em heurísticas que desativa o LAQ se a sobrecarga exceder os limiares.

Para efeitos do mecanismo de retroalimentação, o trabalho realizado por uma instrução é medido no número de leituras lógicas. Se o motor da base de dados estiver a modificar uma linha que foi modificada por outra transação após o início do processamento das declarações, então o trabalho realizado pela instrução é tratado como potencialmente desperdiçado porque a instrução pode precisar de ser reprocessada.

À medida que as instruções são executadas, o motor da base de dados mantém dados de feedback LAQ que acompanham o trabalho potencialmente desperdiçado, as ocorrências de reprocessamento de instruções e o trabalho total realizado pelas instruções que podem ser reprocessadas.

O LAQ é desativado se a razão entre o trabalho potencialmente desperdiçado e o trabalho total, ou a razão entre o número de instruções reprocessadas e o número total de declarações, exceder os respetivos limiares. Se ambos os rácios ficarem abaixo dos limiares, o LAQ é reativado.

Os dados de feedback do LAQ são acompanhados em dois níveis:

Para um plano de consulta.
- O motor da base de dados começa a acompanhar o feedback do LAQ para um plano na primeira ocorrência de reprocessamento de instruções.
- Se uma consulta for capturada na Loja de Consultas, o feedback LAQ também é capturado na Loja de Consultas. O motor da base de dados utiliza este feedback para manter o LAQ ativado ou desativado para o plano caso a base de dados reinicie.
- Os planos de consulta com feedback LAQ capturado têm uma linha com um valor correspondente plan_id na vista de catálogo sys.query_store_plan_feedback. As feature_id colunas e feature_desc são definidas para 4 e LAQ Feedback respetivamente.
Para uma base de dados.
- O feedback é agregado para todas as instruções que não têm feedback ao nível do plano de consulta, por exemplo, se uma consulta não for capturada na Loja de Consultas.
- O feedback é acompanhado desde o arranque da base de dados e é recriado após cada arranque.

Ao decidir se deve usar LAQ para uma instrução, o sistema utiliza o feedback do plano de consulta, caso esteja disponível. Caso contrário, utiliza o feedback ao nível da base de dados. Isto significa que algumas instruções podem ser executadas com LAQ, e outras podem ser executadas sem LAQ. Por exemplo, o LAQ pode estar desativado para um plano de consulta, mas ativado para a base de dados, e vice-versa.

Limitações do LAQ

O lock após a qualificação não é utilizado nos seguintes cenários:

Quando desativado pela heurística LAQ.
Quando dicas de bloqueio conflitantes, como UPDLOCK, READCOMMITTEDLOCK, XLOCK, ou HOLDLOCK são usadas.
Quando o nível de isolamento da transação é diferente de READ COMMITTED, ou quando a READ_COMMITTED_SNAPSHOT opção de banco de dados está desabilitada.
Quando a tabela a ser modificada tem um índice columnstore.
Quando a instrução DML inclui atribuição variável.
Quando a declaração DML tem uma OUTPUT cláusula.
Quando a instrução DML usa mais de um operador de busca ou verificação de índice para ler as linhas que estão sendo modificadas.
Nas declarações MERGE.

O comportamento da consulta muda com bloqueio otimizado e RCSI

Cargas de trabalho simultâneas sob RCSI (Read Committed snapshot isolation) que dependem de uma ordem de execução estrita de transações podem apresentar diferenças no comportamento da consulta quando o bloqueio otimizado está habilitado.

Considere o exemplo a seguir em que a transação T2 está atualizando a tabela t4 com base na coluna b que foi atualizada durante a transação T1.

CREATE TABLE t4
(
a int NOT NULL,
b int NULL
);

INSERT INTO t4
VALUES (1,1);
GO

Sessão 1	Sessão 2
`BEGIN TRANSACTION T1;` `UPDATE t4` `SET b = 2` `WHERE a = 1;`
	`BEGIN TRANSACTION T2;` `UPDATE t4` `SET b = 3` `WHERE b = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Vamos avaliar o resultado do cenário anterior com e sem bloqueio após a qualificação (LAQ).

Sem LAQ

Sem LAQ, a declaração UPDATE na transação T2 é bloqueada, à espera da transação T1. Quando T1 é concluído, T2 atualiza a coluna de configuração de linha b para 3 porque seu predicado está satisfeito.

Após a confirmação de ambas as transações, a tabela t4 contém as seguintes linhas:

 a | b
 1 | 3

com LAQ

Com o LAQ, a transação T2 usa a última versão confirmada da linha onde a coluna b é igual a 1 para avaliar seu predicado (b = 2). A linha de dados não se qualifica; portanto, é ignorada e a declaração é concluída sem ter sido bloqueada pela transação T1. Neste exemplo, o LAQ remove o bloqueio, mas leva a resultados diferentes.

Após a confirmação de ambas as transações, a tabela t4 contém as seguintes linhas:

 a | b
 1 | 2

Important

Mesmo sem LAQ, as aplicações não devem assumir que o mecanismo de base de dados garante uma ordenação rigorosa sem usar sugestões de bloqueio quando são usados níveis de isolamento baseados em controle de versão de linha. Nossa recomendação geral para clientes que executam cargas de trabalho simultâneas sob RCSI que dependem de ordem de execução estrita de transações (como mostrado no exemplo anterior) é usar níveis de isolamento mais rígidos como REPEATABLE READ e SERIALIZABLE.

Melhorias de diagnóstico para um bloqueio otimizado

As melhorias a seguir ajudam a monitorizar e resolver problemas de bloqueios e interbloqueios quando o bloqueio otimizado está ativado:

Tipos de espera para bloqueio otimizado
- XACT tipos de espera para o S bloqueio no TID e descrições de recursos em sys.dm_os_wait_stats:
  - LCK_M_S_XACT_READ - Ocorre quando uma tarefa está à espera de um bloqueio partilhado num tipo XACTwait_resource, com a intenção de ler.
  - LCK_M_S_XACT_MODIFY - Ocorre quando uma tarefa está à espera de um bloqueio compartilhado em um tipo de XACTwait_resource, com a intenção de modificação.
  - LCK_M_S_XACT - Ocorre quando uma tarefa está aguardando um bloqueio partilhado em tipo XACTwait_resource e a intenção não pode ser inferida. Este cenário não é comum.
Bloqueando a visibilidade dos recursos
- XACT bloquear recursos. Para obter mais informações, consulte resource_description em sys.dm_tran_locks.
Aguarde a visibilidade do recurso
- XACT aguardar recursos. Para obter mais informações, consulte wait_resource em sys.dm_exec_requests.
Gráfico de impasse
- Em cada recurso no relatório de deadlock <resource-list>, cada elemento <xactlock> detalha os recursos subjacentes e apresenta informações específicas sobre os bloqueios de cada membro de um deadlock. Para obter mais informações e um exemplo, consulte Bloqueio otimizado e impasses.
Eventos prolongados
- O lock_after_qual_stmt_abort evento é ativado quando uma declaração é reprocessada internamente devido a um conflito com outra transação. Para obter mais informações, consulte Bloqueio após qualificação (LAQ).
- O locking_stats evento é ativado para todas as bases de dados a cada poucos minutos e fornece estatísticas agregadas de bloqueio para o intervalo de tempo, como o número de escalonamentos de bloqueios, se o bloqueio TID e os componentes LAQ de bloqueio otimizado estão ativados, e o número de consultas onde o LAQ não foi usado por várias razões. Esse evento é acionado mesmo se o bloqueio otimizado estiver desativado.
- No SQL Server e Azure SQL Managed Instance, o locking_stats2 evento é ativado para todas as bases de dados a cada poucos minutos e fornece os bloqueios de índice de salto e as estatísticas heurísticas LAQ para o intervalo de tempo.

Práticas recomendadas com bloqueio otimizado

Habilitar o isolamento de instantâneo de leitura confirmada (RCSI)

Para maximizar os benefícios do bloqueio otimizado, é recomendável habilitar o RCSI (isolamento de instantâneo confirmado de leitura) no banco de dados e usar READ COMMITTED o isolamento como o nível de isolamento padrão.

No Azure SQL Database e na base de dados SQL no Microsoft Fabric, o RCSI está ativado por padrão e READ COMMITTED é o nível de isolamento por defeito. Com o RCSI ativado e ao usar o nível de isolamento READ COMMITTED, os leitores leem uma versão da linha do instantâneo tirado no início da instrução. Com o LAQ, os utilizadores avaliam as linhas com base no predicado, considerando a última versão confirmada das linhas e sem adquirir bloqueios U. Com o LAQ, uma consulta aguarda somente se a linha for qualificada e houver uma transação de gravação ativa nessa linha. A qualificação com base na versão confirmada mais recente, juntamente com o bloqueio apenas das linhas qualificadas, reduz o bloqueio e aumenta a simultaneidade.

Evite bloquear dicas

Embora dicas de tabela e consulta como UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCK, etc. sejam consideradas quando o bloqueio otimizado é ativado, elas reduzem o benefício do bloqueio otimizado. As sugestões de bloqueio forçam o mecanismo de base de dados a adotar bloqueios de linha ou página e mantê-los até ao final da transação, para respeitar a intenção das sugestões de bloqueio. Alguns aplicativos têm lógica onde as dicas de bloqueio são necessárias, por exemplo, ao ler uma linha com a dica UPDLOCK e atualizá-la mais tarde. Recomendamos usar dicas de bloqueio apenas quando necessário.

Com o bloqueio otimizado, não há restrições para consultas existentes e as consultas não precisam ser reescritas. As consultas que não estão usando sugestões beneficiam-se mais do bloqueio otimizado.

Uma indicação de tabela numa tabela numa consulta não desativa o bloqueio otimizado para outras tabelas na mesma consulta. Além disso, o bloqueio otimizado afeta apenas o comportamento de bloqueio de tabelas que estão sendo atualizadas por uma instrução DML, como INSERT, UPDATE, DELETEou MERGE. Por exemplo:

CREATE TABLE t5
(
a int NOT NULL,
b int NOT NULL
);

CREATE TABLE t6
(
a int NOT NULL,
b int NOT NULL
);
GO

INSERT INTO t5 VALUES (1,10),(2,20),(3,30);
INSERT INTO t6 VALUES (1,10),(2,20),(3,30);
GO

UPDATE t5 SET t5.b = t6.b
FROM t5
INNER JOIN t6 WITH (UPDLOCK)
ON t5.a = t6.a;

No exemplo de consulta anterior, apenas a tabela t6 é afetada pela dica de bloqueio, enquanto t5 ainda pode se beneficiar do bloqueio otimizado.

UPDATE t5
    SET t5.b = t6.b
FROM t5 WITH (REPEATABLEREAD)
     INNER JOIN t6
         ON t5.a = t6.a;

No exemplo de consulta anterior, somente a tabela t5 usa o nível de isolamento REPEATABLE READ e mantém bloqueios até o final da transação. Outras atualizações para t5 ainda podem beneficiar do bloqueio otimizado. O mesmo se aplica à dica HOLDLOCK.

Perguntas frequentes (FAQ)

O bloqueio otimizado é ativado por padrão em bancos de dados novos e existentes?

No Azure SQL Database, Azure SQL Managed Instance^AUTD e SQL database no Microsoft Fabric, sim. No SQL Server 2025 (17.x), o bloqueio otimizado está desativado por defeito, mas pode ser ativado em qualquer base de dados de utilizador que tenha a recuperação acelerada da base de dados ativada.

Como posso detetar se o bloqueio otimizado está ativado?

Consulte O bloqueio otimizado está ativado?

E se eu quiser forçar o bloqueio de consultas apesar do bloqueio otimizado?

Se o RCSI estiver ativado, utilize a dica de tabela READCOMMITTEDLOCK para forçar o bloqueio entre duas consultas quando o bloqueio otimizado estiver ativado.

O bloqueio otimizado é utilizado em réplicas secundárias apenas para leitura?

Não, porque as instruções DML não podem ser executadas em réplicas somente leitura, e os bloqueios de linha e página correspondentes não são feitos.

O bloqueio otimizado é usado ao modificar dados em tempdb e em tabelas temporárias?

Neste momento, não.

Comentários

Esta página foi útil?

Last updated on 2025-11-24