Loading Now
SQL Server , , , , , ,

SQL Server 2025: Como o OPTIMIZED_LOCKING Pode Finalmente Resolver o Maior Problema do Lock Escalation

Durante décadas, um dos maiores problemas do SQL Server em ambientes OLTP sempre foi o mesmo:
concorrência.

Quem administra sistemas transacionais grandes conhece perfeitamente o cenário:

  • blocking
  • deadlocks
  • lock escalation
  • filas travadas
  • aplicações congelando

E o mais curioso é que muita gente nunca entendeu o verdadeiro motivo do SQL Server fazer lock escalation.

A maioria pensa apenas:
“passou de 5000 linhas atualizadas e virou table lock.”

Mas o problema real é muito mais profundo.

O verdadeiro motivo do Lock Escalation

O SQL Server sempre foi um banco extremamente baseado em locking pessimista.

Isso significa:
quando uma transação altera linhas, o engine mantém locks ativos até o COMMIT.

Exemplo:

BEGIN TRAN

UPDATE Pedidos
SET Status = 'F'
WHERE Data < '2024-01-01'

COMMIT

Se essa query atualizar:

  • 100 mil linhas

o SQL Server pode manter:

  • dezenas ou centenas de milhares de row locks

ativos simultaneamente.

E isso custa memória.

Muita memória.

O detalhe que quase ninguém comenta

Cada lock possui estrutura interna dentro do Lock Manager.

Então imagine:

  • milhares de sessões
  • milhões de row locks
  • transações concorrentes

O consumo de memória pode explodir rapidamente.

E foi justamente para evitar isso que nasceu o:
LOCK ESCALATION.

O famoso “5000 locks”

Muita gente fala:
“passou de 5000 rows o SQL Server faz escalation.”

Tecnicamente não é exatamente linhas.

O SQL Server analisa:

  • quantidade de locks
  • pressão de memória
  • contexto da transação

Mas sim:
por volta de 5000 locks o engine frequentemente tenta converter:

  • row locks
  • key locks
  • page locks

em:

  • TABLE LOCK.

E aqui nasce o verdadeiro problema.

O trade-off histórico do SQL Server

O SQL Server sempre viveu preso em um dilema.

Cenário 1

Manter:

  • milhares de row locks

Problema:

  • consumo absurdo de memória
  • pressão no Lock Manager
  • overhead interno

Cenário 2

Fazer TABLE LOCK

Problema:

  • bloqueia toda a tabela
  • destrói concorrência
  • gera blocking massivo

Era literalmente uma troca entre:

  • memória
    ou
  • concorrência.

E sim… existiam trace flags para tentar resolver isso

Muitos DBAs experientes usavam:

  • Trace Flag 1211
  • Trace Flag 1224

para impedir ou reduzir lock escalation.

A ideia era simples:
“prefiro manter row locks do que bloquear a tabela inteira.”

Só que isso tinha um custo perigosíssimo.

Porque sem escalation…
o SQL Server podia manter:

  • milhões de locks simultâneos.

E isso consumia MUITA memória RAM.

Em ambientes antigos isso inclusive podia gerar:

  • instabilidade
  • pressão de memória
  • degradação severa do servidor

Então durante muitos anos o DBA precisava escolher:

  • mais memória
    ou
  • mais blocking.

E é exatamente aqui que entra o SQL Server 2025

O novo:

ALTER DATABASE MinhaBase
SET OPTIMIZED_LOCKING = ON;

não é apenas uma feature pequena.

Ele muda completamente a filosofia do engine de concorrência do SQL Server.

O que o OPTIMIZED_LOCKING faz de diferente

Historicamente o SQL Server fazia isso:

  • pega row lock
  • mantém lock até COMMIT
  • acumula milhares de locks
  • faz escalation

Agora o comportamento mudou.

Com o novo modelo:
o engine tenta:

  • liberar rapidamente os row locks
  • e manter apenas um lock lógico da transação

Esse mecanismo é chamado:
TID Locking.

A genialidade do TID Locking

Antes:

100 mil linhas atualizadas
=
100 mil row locks ativos

Agora:
o SQL Server modifica a linha…
libera rapidamente o row lock…
e mantém apenas um identificador lógico da transação.

Resultado:
a quantidade de locks simultâneos despenca.

E aqui está o ponto mais importante:

👉 se você não acumula milhares de locks…
você praticamente elimina a CAUSA do lock escalation.

O OPTIMIZED_LOCKING substitui lock escalation?

Não totalmente.

O mecanismo ainda existe.

Mas agora ele é necessário MUITO menos frequentemente.

Porque o SQL Server não precisa mais manter milhões de locks vivos simultaneamente.

Ou seja:
a feature não “desliga” escalation.

Ela reduz drasticamente a necessidade dele acontecer.

E isso é muito mais inteligente.

O segundo mecanismo revolucionário: LAQ

Além do TID Locking, o SQL Server 2025 introduziu:
LAQ — Lock After Qualification.

Historicamente:
o SQL Server muitas vezes pegava lock antes mesmo de validar se a linha realmente precisaria ser modificada.

Agora:
ele primeiro verifica a elegibilidade da linha usando row versioning…
e só depois aplica o lock se realmente precisar alterar o dado.

Isso reduz:

  • blocking
  • waits
  • contenção
  • lock desnecessário

O SQL Server está mudando de arquitetura

Isso é extremamente importante.

Durante décadas o SQL Server foi altamente dependente de locking pessimista.

Agora ele está claramente migrando para:

  • optimistic concurrency
  • row versioning
  • menos retenção de locks
  • menos dependência de escalation

Muito parecido com o que:

  • Oracle
  • PostgreSQL

já fazem há muitos anos.

Então acabou o blocking?

Não.

Isso é importante.

Ainda existem:

  • schema locks
  • metadata locks
  • latch contention
  • log flush waits
  • transaction dependencies

Além disso:
queries usando:

  • SERIALIZABLE
  • HOLDLOCK
  • UPDLOCK
  • XLOCK

continuam reduzindo bastante os benefícios da feature.

O impacto real no SQL Server Standard

E aqui está outro detalhe gigantesco.

No SQL Server Standard:
muitos ambientes sofrem absurdamente com blocking durante:

  • UPDATE massivo
  • DELETE grande
  • manutenção pesada

Porque qualquer escalation para TABLE LOCK pode congelar aplicações inteiras.

O OPTIMIZED_LOCKING pode reduzir muito isso.

E sinceramente?
Essa talvez seja uma das maiores melhorias de concorrência já feitas para workloads OLTP no SQL Server Standard.

Mas existe um detalhe perigoso

Muita gente vai ativar:
OPTIMIZED_LOCKING = ON

achando que virou mágica.

E definitivamente não é assim.

Porque essa feature altera o núcleo de concorrência do SQL Server.

Ela mexe literalmente:

  • no Lock Manager
  • no comportamento transacional
  • na estratégia interna de retenção de locks

E isso exige:

  • benchmark
  • replay de workload
  • monitoramento
  • análise de waits
  • análise de deadlocks

O SQL Server entrou em uma nova era

Historicamente o maior gargalo era:

  • I/O

Depois:

  • CPU

Hoje:
o gargalo cada vez mais é concorrência.

E o OPTIMIZED_LOCKING claramente mostra que a Microsoft finalmente começou a modernizar profundamente o mecanismo interno de concorrência do SQL Server.

Mas atenção…

👉 para o recurso entregar o potencial máximo dele…
o ideal é usar:

ALTER DATABASE MinhaBase
SET READ_COMMITTED_SNAPSHOT ON;

Porque o OPTIMIZED_LOCKING depende fortemente de:

  • row versioning
  • leitura otimista
  • visibilidade transacional baseada em versões

Sem RCSI, parte importante da mágica simplesmente não acontece.

O que muda com RCSI

No SQL Server tradicional:

READ COMMITTED usa locking clássico.

Então:

  • SELECT pega shared lock
  • UPDATE pega exclusive lock
  • ambos podem bloquear um ao outro

Exemplo clássico:

  • usuário lendo
  • outro atualizando
  • blocking acontecendo

Com READ_COMMITTED_SNAPSHOT ON

O comportamento muda completamente.

O SELECT:

  • não lê mais diretamente a linha bloqueada
  • ele lê uma versão anterior da linha no version store do tempdb

Ou seja:

  • leitura não bloqueia escrita
  • escrita não bloqueia leitura

Isso sozinho já reduz MUITO blocking.

E por que isso é importante para o OPTIMIZED_LOCKING?

Porque o novo mecanismo:

  • TID Locking
  • LAQ (Lock After Qualification)

foi desenhado assumindo que o SQL Server pode confiar em row versioning.

Especialmente o:
LAQ.

Porque o SQL Server agora tenta:

  • validar a linha primeiro
  • usando versões
  • sem bloquear imediatamente

Sem RCSI:
o engine ainda precisa usar muito mais locking tradicional.

Então o OPTIMIZED_LOCKING funciona sem RCSI?

Sim.

Mas perde parte importante dos benefícios.

A Microsoft até fala isso de forma indireta na documentação.

Sem:

  • RCSI
  • ADR

o ganho é menor.

Porque o SQL Server ainda fica preso em vários comportamentos pessimistas tradicionais.

O detalhe MAIS importante

Muita gente acha que:
“RCSI é só para SELECT não bloquear UPDATE”.

Mas não.

RCSI muda profundamente:

  • a filosofia de concorrência do banco
  • o comportamento transacional
  • a retenção de locks
  • o modelo interno de leitura

E agora no SQL Server 2025…
isso virou ainda mais importante.

Porque o engine novo foi claramente desenhado para um mundo mais:

  • optimistic
  • versioned
  • menos lock-based

Então o SQL Server está virando MVCC igual Oracle/Postgres?

Quase isso.

Mas ainda não totalmente.

Oracle e PostgreSQL nasceram:

  • version-based
  • MVCC-first

O SQL Server nasceu:

  • lock-first
  • pessimistic-first

Agora ele está evoluindo para um modelo híbrido.

E sinceramente?
O SQL Server 2025 talvez seja a maior mudança nessa direção desde o lançamento do Snapshot Isolation lá atrás.

Mas existe um custo importante

RCSI não é “grátis”.

Porque agora o SQL Server precisa manter versões das linhas no:

  • tempdb version store

Então você aumenta:

  • escrita no tempdb
  • uso de disco/tempdb
  • memória
  • cleanup interno de versões

Em workloads extremamente pesados isso pode virar outro gargalo.

Então vale a pena?

Na maioria dos ambientes OLTP modernos:
👉 sim.

Principalmente:

  • ERP
  • APIs
  • SaaS
  • sistemas concorrentes
  • workloads com muito blocking

Hoje muitos DBAs já consideram:
RCSI praticamente obrigatório.

Conclusão

O OPTIMIZED_LOCKING não é apenas uma feature nova.

Ele representa uma mudança arquitetural enorme no SQL Server.

Durante décadas o engine precisava escolher entre:

  • consumo de memória
    ou
  • concorrência.

Agora o SQL Server 2025 tenta entregar os dois:

  • menos locks
  • menos escalation
  • menos blocking
  • menos memória consumida

Tudo ao mesmo tempo.

E sinceramente?

Essa talvez seja uma das evoluções mais importantes do SQL Server moderno para ambientes OLTP de alta concorrência.

Quer se aprimorar como DBA ou DEV que trabalha com o SQL SERVER?

Segue Principais Formações:

  • Coloque comentário que gostaria de ter acesso aos cursos com desconto.
  1. AcademiaDBA. Formação Completa para DBA.
    Aprenda SQL Server, Oracle, PostgreSQL, MySQL, Data Warehouse, ETL com SSIS/SSAS e Power BI em uma plataforma prática e focada na carreira, criada para ajudar você a se tornar um profissional confiante em banco de dados e dados.
    1316 aulas e 412 horas de conteúdo original
    Legendas: Portugues
    https://formacaodba.academiadba.com/

1.1 DBAcademy. Master Databases.Build a Real Data Career.
Learn SQL Server, Oracle, PostgreSQL, MySQL, Data Warehousing, ETL with SSIS/SSAS, and Power BI in one practical, career-focused platform designed to help you become a confident database and data professional.
1316 class e 412 hours
Subtitles: English, Spain, France
https://dbacademy.academiadba.com/

  1. Mastering SQL Server – 86 horas: torne-se um DBA SQL Server
    Curso Completo de DBA SQL Server: Aprenda do Zero, na Prática, com Azure, Performance, Segurança e Alta Disponibilidade.
    https://www.udemy.com/course/servino_sqlserver/

2.1 Dominando scripts PowerShell para o SQL Server
Do básico ao avançado: aprenda PowerShell passo a passo e transforme sua rotina de DBA com automações inteligentes.
https://www.udemy.com/course/dbapowershell/

2.2 Toolkit do DBA SQL Server
Monitoramento com DBADASH, Stress Test com SQLQUERYSTRESS, DBATools e Scripts Essenciais para o DBA SQL Server
https://www.udemy.com/course/toolkitdbasqlserver/

2.3 SQL Server DBA Toolkit
Monitoring with DBADASH, Stress Testing with SQLQUERYSTRESS, DBATools, and Essential Scripts for the SQL Server DBA. In English
https://www.udemy.com/course/sql-server-dba-toolkit/

2.4 Cluster-AG Always ON e Log Shipping no SQL SERVER 2025
Aprenda a configurar ambiente de disaster recovery no SQL Server usando o Cluster com AG Always on e Log Shipping
https://www.udemy.com/course/logshippingsqlserver/

  1. Curso Postgres Completo, 50 horas – Formação DBA
    Aprenda Banco de Dados Postgres, Modelagem de Dados e programação usando SQL – do básico ao avançado
    https://www.udemy.com/course/postgrescompleto/

3.1 Cluster Postgres: Domine Clusters Gerenciado pelo Patroni
Aprenda a montar um cluster PostgreSQL robusto no Linux utilizando Patroni, ETCD, HAProxy e Keepalived
https://www.udemy.com/course/clusterpostgres/

3.2 Postgres Cluster: Master Patroni-Managed Clusters
Learn how to build a robust PostgreSQL cluster on Linux using Patroni, ETCD, HAProxy and Keepalived. In English
https://www.udemy.com/course/postgres-cluster/

  1. Curso ORACLE Completo – 89 horas, formação DBA
    Aprenda Banco de Dados Oracle, Modelagem de Dados e programação usando PL/SQL – do básico ao avançado
    https://www.udemy.com/course/dbaoracle/
  2. Curso MySQL Completo – 123 horas, formação DBA
    Aprenda MySQL, SQL, Azure MySQL, Modelagem de Dados, Windows Server e Linux Ubuntu Server – do básico ao avançado
    https://www.udemy.com/course/mysqlcompleto/

5.1 MySQL Course – 75 Hours, Become a DBA
MySQL Course – 75 hours, DBA training. Learn MySQL / SQL Language – From Basic to Advanced. In English
https://www.udemy.com/course/mysqlcourse/

  1. Curso Analista de Dados, formação profissional – 52 horas
    Aprenda SQL Server, modelagem de dados, Linguagem SQL, SSIS, SSAS, data Warehouse, Stage, Power BI
    https://www.udemy.com/course/analistadados/
  2. Curso PowerBI – Formação Analista de BI – 28 horas
    PowerBI, Linguagem SQL e Modelagem de Dados, do básico ao avançado. Se torne um Analista de BI – Business Intelligence
    https://www.udemy.com/course/curso-powerbi-completo/
  3. Guia Completo para a Carreira de DBA
    Como conquistar sua primeira vaga como DBA — mesmo começando do zero e evoluir até pleno ou criar seu próprio negócio
    https://www.udemy.com/course/guiacarreiradba/
  4. Analista de Dados: Da Primeira Vaga ao Negócio Próprio
    Aprenda a se posicionar, conseguir entrevistas, passar em processos seletivos, trabalhar bem nos primeiros 90 dias
    https://www.udemy.com/course/guianalistadados/

Bons Estudos
Prof. Msc Sandro Servino
www.academiadba.com

Share this content:

Tag
Prof. Msc. Sandro Servino

Sandro Servino is a senior IT professional with over 30 years of experience in technology, having worked as a Developer, Project Manager (acting as a Requirements Analyst and Scrum Master), Professor, IT Infrastructure Team Coordinator, IT Manager, and Database Administrator. He has been working with Database technologies since 1996 and has been vendor-certified since the early years of his career. Throughout his professional journey, he has combined deep technical expertise with leadership, education, and consulting experience in mission-critical environments. Sandro has trained more than 20,000 students in database technologies, helping professionals build strong foundations and advance their careers in data platforms and database administration. He has delivered corporate training programs for multiple companies and served as a university professor teaching Database and Data Administration for over five years. For many years, he worked as an independent consultant specializing in SQL Server, providing strategic and technical support for complex database environments. He has extensive experience in troubleshooting and resolving critical issues in SQL Server production environments, including performance tuning, high availability, disaster recovery, security, and infrastructure optimization. His academic background includes: Postgraduate Degree in School Education MBA in IT Governance Master’s Degree in Knowledge Management and Information Technology Currently, Sandro works as a Database Administrator for multinational companies in Europe, managing enterprise-level SQL Server environments and supporting large-scale, high-demand infrastructures. Areas of Expertise SQL Server (Administration, Performance, HA/DR, Troubleshooting) Azure SQL Databases MySQL Oracle PostgreSQL Power BI Data Analytics Data Warehouse Windows Server Oracle Linux Server Ubuntu Linux Server DBA Training and Mentorship Business Continuity and Disaster Recovery Strategies Courses and Training Programs Sandro delivers professional training programs focused on the formation of DBAs and Data/BI Analysts, covering: SQL Server and Azure SQL Databases MySQL Oracle PostgreSQL Power BI Data Analytics Data Warehouse Windows Server Oracle Linux Server Ubuntu Linux Server With a unique combination of technical depth, academic knowledge, real-world consulting experience, and international exposure, Sandro Servino brings practical, results-driven expertise to database professionals and organizations seeking reliability, performance, and resilience in their data platforms.

view all posts

Related Posts

Post Comment