Treinamento de Tuning de Banco de

Dados
Capítulo 3 – Lock, Block, Deadlock e aspectos de transações em banco
de dados

1
Objetivos
Entendendo o mecanismo de Lock em um
banco de dados

Entendendo o processo de bloqueio (Block)

de uma sessão de banco de dados em
relação a outra.

O que é deadlock e quais são suas

consequências

O que é uma transação de banco de dados

Quais tipos de transações de banco de

dados existem

2
bloqueio (Lock)
• O bloqueio (LOCK) é um mecanismo desenvolvido para evitar a ocorrência de
problemas de manipulação concorrente das informações. Funciona como um
bloqueio no acesso aos recursos dentro de um ambiente cliente/servidor.

• Por conta dos bloqueios, um mesmo dado não pode ser utilizado
simultaneamente pelos usuários. Assim, um usuário não poderá ler e alterar
dados que estão sendo processados por outro usuário, ou seja, não haverá
conflitos de atualização.

• Os bloqueios podem ser de leitura (que impedem que os usuários alterem

dados que estejam sendo lidos, mas permitem que eles leiam os dados) ou
de escrita (que impedem que os usuários leiam ou atualizem dados que já
estiverem sendo atualizados por outro usuário).

O mecanismo de lock em um banco de dados é utilizado para controlar o acesso

concorrente aos dados por várias transações. Existem dois conceitos principais
relacionados ao mecanismo de lock: concorrência otimista e concorrência pessimista.

A concorrência pessimista envolve a utilização de locks para evitar conflitos entre

transações concorrentes. Nesse modelo, quando uma transação acessa um objeto de
dados, ela adquire um lock exclusivo sobre esse objeto, impedindo que outras
transações acessem ou modifiquem os mesmos dados simultaneamente. Esse tipo de
lock é considerado pessimista porque presume-se que ocorrerão conflitos e
bloqueios, e o sistema toma medidas para evitá-los.

Por exemplo, quando uma transação realiza uma operação de escrita (como um
UPDATE), ela adquire um lock exclusivo na linha ou tabela afetada. Outras transações
que tentam acessar esses dados ao mesmo tempo terão que esperar até que o lock
seja liberado.

A concorrência otimista, por outro lado, não utiliza locks exclusivos para evitar
conflitos. Em vez disso, ela assume que os conflitos são raros e que a maioria das

3
transações pode ser executada simultaneamente sem causar problemas. Nesse
modelo, as transações não bloqueiam uns aos outros, mas podem detectar conflitos
de forma retroativa e tomar medidas apropriadas para resolvê-los.

A concorrência otimista é frequentemente utilizada em cenários onde o acesso

concorrente aos dados é comum e os conflitos são raros. Em vez de adquirir locks
exclusivos, as transações podem utilizar mecanismos como marcas de tempo
(timestamps) ou controle de versão (versioning) para rastrear as modificações e
resolver conflitos posteriormente, se necessário.

Por exemplo, em um sistema de controle de versão, cada transação pode receber

uma versão dos dados com a qual ela trabalha. Se uma transação tentar modificar
uma versão obsoleta dos dados, será detectado um conflito e a transação precisará
ser reexecutada ou as alterações serão descartadas.

A escolha entre concorrência otimista e pessimista depende do contexto e dos

requisitos do sistema. A concorrência pessimista é mais conservadora e evita
conflitos garantindo a exclusividade de acesso, mas pode levar a bloqueios e reduzir o
desempenho em ambientes com muitas transações concorrentes. Já a concorrência
otimista é mais flexível e permite um maior grau de paralelismo, mas requer
mecanismos adicionais para detecção e resolução de conflitos.

3
 DeadLock
• Deadlock é um mecanismo de banco de dados quando
ocorre um bloqueio realizado de forma cruzada, e deve
ocorrer entre duas sessões que estejam transacionando os
mesmos dados em dois comandos distintos e haja um
bloqueio mútuo cruzado.
• Para que possa ocorrer devemos ter duas sessões distintas
em que a primeira imponha um bloqueio em um conjunto
de registros (A), Já a sessão 2 deve impor bloqueio em um
conjunto de registros (B), novamente a primeira sessão
deve tentar impor um bloqueio a um conjunto de registros
transacionados pela sessão secundária(pode ser apenas 1
registro) e com isso a sessão inicial ficará bloqueada pela
sessão secundária. Por fim para completar a sessão
secundária caso tente manipular algum registro bloqueado
pela sessão inicial também ficará bloqueada (bloqueio
mútuo) também conhecido por Deadlock
• O mecanismo de banco de dados terá de atuar para liberar
a sessão que iniciou a transação para que a mesma possa
efetivar a transação inicial .
•

Deadlock, em um banco de dados, é uma situação em que duas ou mais transações

ficam bloqueadas esperando uma pela outra, resultando em um impasse (lock) e
impedindo que qualquer uma das transações possa prosseguir.

Cada transação está aguardando a liberação de um recurso que é mantido pela outra
transação, criando um ciclo de bloqueio.

Causas do Deadlock: Existem várias causas comuns de deadlocks:

1.Competição por recursos: Quando duas ou mais transações precisam acessar os

mesmos recursos do banco de dados, como tabelas, linhas específicas ou objetos
compartilhados, elas podem entrar em conflito e bloquear uns aos outros.

2.Ordem de aquisição de bloqueio: Se as transações não adquirirem os bloqueios na

mesma ordem, pode ocorrer um deadlock. Por exemplo, se a Transação A adquirir
um bloqueio na Tabela X e, em seguida, tentar adquirir um bloqueio na Tabela Y,
enquanto a Transação B já adquiriu um bloqueio na Tabela Y e está tentando adquirir
um bloqueio na Tabela X, ocorrerá um impasse.

4
3. Uso excessivo de bloqueios exclusivos: Se as transações adquirirem bloqueios
exclusivos por um longo período ou em muitos recursos, a probabilidade de ocorrer
um deadlock aumenta. Transações que retêm bloqueios exclusivos por muito tempo
podem criar uma situação em que outras transações ficam bloqueadas esperando a
liberação desses bloqueios.

Efeitos do Deadlock: Os efeitos do deadlock incluem:

1.Paralisação das transações envolvidas: As transações que estão em deadlock ficam

bloqueadas e não podem ser concluídas. Isso pode resultar em atrasos significativos
na execução das transações e no processamento de outras transações que dependem
dos recursos bloqueados.

2.Consumo de recursos: As transações em deadlock podem continuar ocupando

recursos do sistema, como memória e processamento, enquanto permanecem
bloqueadas. Isso pode levar a uma utilização ineficiente dos recursos do banco de
dados e afetar negativamente o desempenho geral.

Tratamento do Deadlock: Para tratar deadlocks, podem ser adotadas as seguintes

abordagens:

1.Detecção de deadlock: Os sistemas de gerenciamento de banco de dados

geralmente possuem mecanismos de detecção de deadlock embutidos que podem
identificar quando um deadlock ocorre. Eles podem gerar informações sobre as
transações envolvidas e os recursos bloqueados.

2.Resolução manual: Em alguns casos, é possível analisar manualmente os deadlocks

identificados para determinar a causa raiz e implementar ajustes, como reordenar as
operações das transações ou ajustar a ordem de aquisição de bloqueio.

3.Implementação de timeout: É possível configurar um timeout para transações, de

modo que, se uma transação ficar bloqueada por um tempo especificado, ela seja
automaticamente cancelada e revertida. Isso pode liberar os recursos bloqueados e
permitir que as transações continuem.

Tratamento específico em SQL Server, Oracle e PostgreSQL:

•SQL Server:
No SQL Server, a detecção de deadlock é realizada automaticamente pelo mecanismo
de banco de dados. O SQL Server escolhe uma das transações envolvidas como a
vítima do deadlock e a finaliza, liberando os recursos bloqueados. É possível
monitorar e analisar os registros de eventos do SQL Server para identificar deadlocks

4
e ajustar o design de consultas, índices ou a configuração do isolamento das
transações para reduzir a probabilidade de ocorrência de deadlocks.

•Oracle:
No Oracle, a detecção de deadlock é feita por meio de um algoritmo que analisa as
relações de bloqueio entre as transações. Quando um deadlock é detectado, o Oracle
seleciona uma das transações como a vítima e a finaliza para resolver o deadlock. É
possível utilizar consultas, como o V$LOCK e o V$SESSION, para identificar e analisar
deadlocks. A otimização de consultas, o uso adequado de índices e o ajuste da
configuração de bloqueio podem ajudar a mitigar a ocorrência de deadlocks.

PostgreSQL:
No PostgreSQL, a detecção de deadlock é realizada automaticamente pelo
mecanismo de banco de dados. Quando um deadlock é detectado, uma das
transações é escolhida como a vítima e é automaticamente cancelada. O PostgreSQL
registra informações sobre os deadlocks no arquivo de log do servidor. Para
identificar deadlocks, é possível consultar as visualizações do sistema, como a
pg_stat_activity e a pg_locks. A otimização de consultas, a definição adequada de
índices e a configuração apropriada dos parâmetros de bloqueio podem ajudar a
evitar a ocorrência de deadlocks.

4
 DeadLock – Efeitos
no banco de dados
• Deadlocks podem ter consequências graves na
performance do banco de dados, e antes de tudo
consomem muito processamento do mesmo para que
possam ser identificados e as respectivas sessões sejam
liberadas.
• As causas do deadlock podem ser consideradas de
infraestrutura, de configuração do banco de dados ou
ainda ligadas a falhas na programação do banco de dados,
esta é geralmente a causa mais comum entre todas
apresentadas.
• Deadlocks podem ocorrer esporadicamente e neste caso
não necessariamente representam um problema, a
quantidade , incidência e volume é que determinam o seu
grau de nocividade para a operação do banco de dados.
•

A alta ocorrência de deadlocks em um banco de dados pode ter efeitos nocivos

significativos no desempenho, na disponibilidade e na confiabilidade do sistema.
Alguns dos impactos negativos da alta ocorrência de deadlocks são:

1.Atrasos e bloqueios de transações: Os deadlocks resultam na paralisação de

transações, pois elas ficam bloqueadas aguardando a liberação de recursos que estão
sendo mantidos por outras transações. Isso causa atrasos no processamento das
transações afetadas, podendo levar a interrupções nos fluxos de trabalho e a um
tempo de resposta mais lento para os usuários.

2.Diminuição do desempenho: Os deadlocks consomem recursos do sistema, como

CPU, memória e tempo de processamento, mesmo quando as transações estão
bloqueadas. Isso pode levar a uma utilização ineficiente dos recursos do banco de
dados, resultando em uma diminuição geral do desempenho do sistema. O
processamento adicional necessário para detectar e resolver os deadlocks também
pode impactar negativamente o desempenho.

3.Instabilidade e indisponibilidade: Se a ocorrência de deadlocks for muito alta e

frequente, pode levar a uma instabilidade do sistema e até mesmo à

5
indisponibilidade temporária do banco de dados. Os deadlocks podem causar uma
interrupção significativa nos fluxos de trabalho e nas operações críticas do sistema,
resultando em uma redução da produtividade e na insatisfação dos usuários.

4.Impacto nas transações e integridade dos dados: Quando uma transação é

cancelada como resultado de um deadlock, todas as alterações não confirmadas
realizadas por essa transação são revertidas. Isso pode levar a inconsistências nos
dados e exigir a necessidade de reprocessar as operações canceladas. Em casos
extremos, os deadlocks podem até mesmo causar corrupção de dados.

5.Complexidade na detecção e resolução: Lidar com a alta ocorrência de deadlocks

requer uma análise e resolução cuidadosas. A detecção e a resolução manual de
deadlocks podem ser complexas e exigir esforço e conhecimento detalhados do
sistema. Isso pode aumentar a carga de trabalho dos administradores do banco de
dados e atrasar a resolução de outros problemas e tarefas.

Para mitigar os efeitos nocivos da alta ocorrência de deadlocks, é fundamental

implementar práticas recomendadas, como otimização de consultas, ajuste dos níveis
de isolamento, revisão do design de bancos de dados e monitoramento proativo para
detectar e resolver os deadlocks de maneira eficiente. Além disso, é importante
realizar testes adequados de carga e estresse para identificar e resolver problemas de
deadlock antes de implantar o sistema em produção.

Causas do Deadlock:

1.Competição por recursos: Quando duas ou mais transações precisam acessar os

mesmos recursos, como tabelas, linhas específicas ou objetos compartilhados, elas
podem entrar em conflito e bloquear umas às outras. Isso pode ocorrer quando as
transações tentam adquirir bloqueios exclusivos em recursos compartilhados ao
mesmo tempo.

2.Ordem de aquisição de bloqueio: Se as transações não adquirirem os bloqueios na

mesma ordem, pode ocorrer um deadlock. Por exemplo, se a Transação A adquirir
um bloqueio na Tabela X e, em seguida, tentar adquirir um bloqueio na Tabela Y,
enquanto a Transação B já adquiriu um bloqueio na Tabela Y e está tentando adquirir
um bloqueio na Tabela X, ocorrerá um impasse.

3.Transações longas: Transações que retêm bloqueios por um longo período podem
aumentar a probabilidade de ocorrerem deadlocks. Isso pode acontecer quando uma
transação executa várias operações complexas ou quando um ponto de salvamento é
mantido por um período prolongado.

5
4.Uso excessivo de bloqueios exclusivos: Se as transações adquirirem bloqueios
exclusivos em muitos recursos ou por um tempo prolongado, a probabilidade de
ocorrer um deadlock aumenta. Transações que retêm bloqueios exclusivos por muito
tempo podem criar uma situação em que outras transações ficam bloqueadas
esperando a liberação desses bloqueios.

5.Erros de programação: Erros de programação podem resultar em situações em que

as transações não são encadeadas corretamente ou não liberam adequadamente os
recursos que estão bloqueando. Por exemplo, uma transação pode adquirir um
bloqueio e terminar abruptamente sem liberá-lo, causando um deadlock.

5
 Concorrência otimista
1. Paralelismo: As transações podem ser executadas simultaneamente sem
bloquear umas às outras, permitindo um maior grau de paralelismo no
acesso aos dados.
2. Ausência de bloqueios: Não há bloqueios exclusivos adquiridos pelas
transações durante a leitura e gravação de dados.
3. Detecção retroativa de conflitos: Os conflitos são detectados
posteriormente, durante a validação das transações. Isso ocorre por meio
de mecanismos como marcas de tempo (timestamps) ou controle de
versão (versioning).
4. Menor contenção: Como não há bloqueios exclusivos, há menos
contenção entre transações concorrentes, o que pode melhorar o
desempenho em cenários com muitas transações simultâneas.
5. Possibilidade de reexecução de transações: Se um conflito for detectado,
a transação pode ser reexecutada ou as alterações podem ser
descartadas e revertidas.

Paralelismo: Na concorrência otimista, as transações podem ser executadas

simultaneamente, sem bloquear umas às outras. Isso permite um maior grau de
paralelismo no acesso aos dados. Por exemplo, suponha que duas transações estejam
lendo diferentes partes de uma tabela. Ambas as transações podem prosseguir sem
bloqueios, acessando os dados simultaneamente.

Ausência de bloqueios: Na concorrência otimista, não são adquiridos bloqueios

exclusivos durante a leitura e gravação de dados. Em vez disso, os mecanismos de
controle são utilizados para evitar conflitos posteriores. Por exemplo, ao executar
uma consulta SELECT em uma tabela, as transações não bloqueiam a tabela ou as
linhas específicas que estão lendo. Isso permite que outras transações acessem os
mesmos dados simultaneamente, sem esperar pela liberação de bloqueios.

Detecção retroativa de conflitos: Na concorrência otimista, os conflitos são

detectados posteriormente, durante a validação das transações. Isso é feito por meio
de mecanismos como marcas de tempo (timestamps) ou controle de versão
(versioning). Por exemplo, se duas transações modificarem a mesma linha de uma
tabela, a validação retroativa identificará o conflito e tomará as medidas apropriadas
para resolvê-lo. Isso pode envolver a reexecução de uma das transações ou o

6
descarte de suas alterações.

Menor contenção: Devido à ausência de bloqueios exclusivos, a concorrência otimista

resulta em menor contenção entre transações concorrentes. Isso ocorre porque as
transações não bloqueiam umas às outras durante a execução. Por exemplo, várias
transações podem ler e modificar diferentes partes de uma tabela simultaneamente,
sem esperar pela liberação de bloqueios. Isso aumenta o desempenho em cenários
com muitas transações concorrentes.

Possibilidade de reexecução de transações: Na concorrência otimista, se um conflito

for detectado durante a validação, as transações podem ser reexecutadas ou suas
alterações podem ser descartadas e revertidas. Por exemplo, se uma transação tentar
modificar dados que foram alterados por outra transação, ocorrerá um conflito.
Nesse caso, a transação pode ser reexecutada com base nos dados atualizados ou
pode desfazer suas alterações e reiniciar.

6
 Concorrência Pessimista
1. Exclusividade de acesso: As transações adquirem bloqueios exclusivos
para garantir a exclusividade do acesso aos objetos de dados.
2. Contenção e bloqueios: Os bloqueios são adquiridos para evitar conflitos
entre transações concorrentes. Isso pode resultar em contenção, onde as
transações precisam esperar pela liberação dos bloqueios para acessar
ou modificar os dados.
3. Garantia de consistência: A concorrência pessimista garante a
consistência e a integridade dos dados, pois impede que múltiplas
transações modifiquem o mesmo objeto simultaneamente.
4. Maior segurança: Através dos bloqueios exclusivos, a concorrência
pessimista evita a ocorrência de situações de leitura suja (dirty reads),
leitura não repetível (non-repeatable reads) e escrita fantasma (phantom
writes).
5. Menor risco de conflitos: Ao garantir a exclusividade do acesso, a
concorrência pessimista reduz a probabilidade de ocorrerem conflitos
entre transações concorrentes.

Exclusividade de acesso: Na concorrência pessimista, as transações adquirem

bloqueios exclusivos para garantir a exclusividade do acesso aos objetos de dados.
Isso significa que apenas uma transação por vez pode modificar um objeto específico.
Por exemplo, se uma transação adquirir um bloqueio exclusivo em uma tabela, outras
transações precisarão aguardar a liberação desse bloqueio antes de poderem acessar
ou modificar a tabela.

Contenção e bloqueios: A concorrência pessimista envolve a utilização de bloqueios

para evitar conflitos entre transações concorrentes. Isso pode resultar em contenção,
onde as transações precisam esperar pela liberação dos bloqueios para acessar ou
modificar os dados. Por exemplo, se uma transação está realizando uma atualização
em uma linha específica de uma tabela, outras transações que tentarem acessar ou
modificar essa mesma linha serão bloqueadas até que a transação em andamento
seja concluída e libere o bloqueio.

Garantia de consistência: A concorrência pessimista visa garantir a consistência e a

integridade dos dados, pois impede que múltiplas transações modifiquem o mesmo
objeto simultaneamente. Ao adquirir bloqueios exclusivos, a concorrência pessimista
evita situações de leitura suja (dirty reads), leitura não repetível (non-repeatable

7
reads) e escrita fantasma (phantom writes). Isso garante que as transações vejam
dados consistentes e evita resultados indesejáveis.

Maior segurança: A utilização de bloqueios exclusivos na concorrência pessimista

oferece uma maior segurança nos dados. Isso significa que as transações podem
realizar modificações nos objetos de dados sem interferência de outras transações.
Isso evita conflitos e garante que as modificações sejam concluídas de forma
consistente e segura.

Menor risco de conflitos: A concorrência pessimista, devido à sua natureza de

bloqueios exclusivos, reduz o risco de conflitos entre transações concorrentes. Isso
ocorre porque as transações aguardam pela liberação de bloqueios antes de
acessarem ou modificarem os mesmos objetos. Essa abordagem minimiza a
ocorrência de situações em que várias transações tentam modificar os mesmos
dados simultaneamente, evitando assim conflitos e preservando a integridade dos
dados.

Essas características da concorrência pessimista visam garantir a consistência e a

integridade dos dados, mas podem resultar em bloqueios, o que pode afetar o
desempenho em cenários com muitas transações concorrentes. No entanto, a
concorrência pessimista oferece maior segurança e controle no acesso aos dados,
evitando conflitos e garantindo resultados consistentes.

7
 Tipo de bloqueio Descrição

Tipos de Compartilhado Shared Lock

Permite leitura simultânea, mas impede escrita
concorrente.

bloqueio Exclusivo

Atualização
Exclusive Lock

Update Lock
Permite acesso exclusivo para leitura e escrita,
bloqueando outros acessos.

Indica intenção de atualização, permitindo leitura, mas

Padrão Intenção Intent Lock

bloqueando bloqueios exclusivos.

Sinaliza intenção de adquirir bloqueios em níveis

hierárquicos mais baixos.

ANSI Leitura
Shared Read
Lock
Permite leitura simultânea, mas impede escrita
concorrente.

Exclusive Write Permite acesso exclusivo para leitura e escrita,

Escrita
Lock bloqueando outros acessos.

Exclusive Share Permite leitura simultânea, mas impede bloqueios

Compartilhamento Exclusivo
Lock exclusivos.

Update Share Indica intenção de atualização, permitindo leitura, mas

Compartilhamento de Atualização
Lock bloqueando bloqueios exclusivos.

O padrão ANSI SQL define diferentes tipos de bloqueio (lock) que podem ser
utilizados em sistemas de banco de dados. Esses tipos de bloqueio são usados para
controlar o acesso concorrente aos dados e garantir a consistência e a integridade
das transações. Abaixo estão alguns dos principais tipos de bloqueio definidos pelo
padrão ANSI SQL:

bloqueio Compartilhado (Shared Lock):

Descrição: Também conhecido como “bloqueio de leitura", permite que várias

transações acessem um recurso simultaneamente para leitura, mas impede que
outras transações realizem alterações no recurso enquanto o bloqueio estiver ativo.

Funcionamento: O bloqueio compartilhado permite leitura simultânea, mas impede a

escrita concorrente, ou seja, outras transações podem ler o recurso
simultaneamente, mas não podem escrever nele até que o bloqueio compartilhado
seja liberado.

bloqueio Exclusivo (Exclusive Lock):

8
Descrição: Também conhecido como "bloqueio de escrita", permite que uma única
transação acesse um recurso exclusivamente para leitura e escrita, bloqueando o
acesso de outras transações ao recurso enquanto o bloqueio estiver ativo.

Funcionamento: O bloqueio exclusivo impede tanto a leitura quanto a escrita

concorrente. Apenas a transação que adquiriu o bloqueio exclusivo tem permissão
para ler e escrever no recurso bloqueado, enquanto outras transações devem
aguardar até que o bloqueio seja liberado.

bloqueio de Atualização (Update Lock):

Descrição: Também conhecido como "bloqueio de leitura com intenção de

atualização", é um tipo de bloqueio intermediário que indica a intenção de uma
transação de atualizar um recurso. Ele permite que outras transações leiam o recurso,
mas impede que elas obtenham um bloqueio exclusivo para atualizá-lo.

Funcionamento: O bloqueio de atualização é usado quando uma transação deseja

indicar sua intenção de atualizar um recurso, mas ainda permite que outras
transações o leiam. No entanto, se outra transação tentar obter um bloqueio
exclusivo no mesmo recurso, ela terá que esperar até que o bloqueio de atualização
seja liberado.

bloqueio de Intenção (Intent Lock):

Descrição: Os bloqueios de intenção são usados para sinalizar a intenção de uma

transação em obter bloqueios em níveis hierárquicos mais baixos. Eles não
bloqueiam diretamente o recurso em si, mas informam às outras transações sobre as
intenções de bloqueio em níveis mais granulares.

Funcionamento: Os bloqueios de intenção são adquiridos antes dos bloqueios

compartilhados, exclusivos ou de atualização. Eles servem como um aviso para outras
transações de que uma transação pode adquirir bloqueios em níveis mais granulares
posteriormente, garantindo assim a consistência e a integridade das transações.

Esses são alguns dos tipos de bloqueio definidos pelo padrão ANSI SQL. É importante
observar que a implementação exata dos tipos de bloqueio pode variar entre os
diferentes sistemas de gerenciamento de banco de dados, mas os conceitos gerais
permanecem

8
 Nível de Tipo de
Granularidade bloqueio Descrição
bloqueio de Bloqueia uma chave específica em um índice, permitindo que outras
Chave (Key)
Leitura transações leiam outras chaves simultaneamente.

bloqueio de Bloqueia uma página específica de dados, permitindo que outras

Página (Page)
Página transações acessem ou modifiquem outras páginas simultaneamente.

RID (Identificador de bloqueio de Bloqueia uma linha específica em uma página de dados, permitindo que

Granularidade Linha)

Extent
Linha

bloqueio de
Extensão
outras transações acessem outras linhas simultaneamente.

Bloqueia um intervalo contíguo de páginas de dados no banco de dados,

permitindo que apenas uma transação acesse esse intervalo.

de bloqueios HOBT (Heap or B-tree)

bloqueio de
Leitura
Bloqueia uma estrutura de dados específica, como um heap ou uma
árvore B, permitindo que outras transações leiam simultaneamente.

SQL Server
bloqueio de Bloqueia uma tabela inteira, permitindo que outras transações leiam
Tabela (Table)
Leitura simultaneamente.
bloqueio de Bloqueia todo o arquivo de banco de dados, permitindo que apenas uma
Arquivo (File)
Leitura transação acesse o arquivo por vez.
bloqueio de Bloqueia recursos específicos de um aplicativo, permitindo que apenas
Aplicativo (Application)
Leitura uma transação acesse esses recursos por vez.

bloqueio de Bloqueia os metadados do banco de dados, impedindo que outras

Metadados (Metadata)
Leitura transações modifiquem as informações sobre a estrutura dos objetos.

Unidade de Alocação bloqueio de Bloqueia uma unidade de alocação específica, que é uma estrutura de
(Allocation Unit) Leitura armazenamento lógica usada pelo SQL Server.
Banco de Dados bloqueio de Bloqueia todo o banco de dados, permitindo que apenas uma transação
(Database) Leitura acesse o banco de dados por vez.

Chave (Key):

Descrição: O bloqueio de chave é aplicado em uma chave específica de um índice.

Permite que outras transações leiam outras chaves simultaneamente.
Exemplo: Se uma transação está lendo a chave "123" em um índice, outras
transações podem ler as chaves "456", "789" e assim por diante.

Página (Page):

Descrição: O bloqueio de página é aplicado em uma página específica de dados.

Permite que outras transações acessem ou modifiquem a página inteira
simultaneamente.
Exemplo: Se uma transação está modificando uma página que contém várias linhas
de uma tabela, outras transações podem ler ou modificar outras páginas da mesma
tabela.

RID (Identificador de Linha):

Descrição: O bloqueio de RID é aplicado em uma linha específica dentro de uma

9
página de dados. Permite que outras transações acessem outras linhas
simultaneamente.
Exemplo: Se uma transação está modificando a linha com o RID "123" dentro de uma
página, outras transações podem ler ou modificar as linhas com os RIDs "456", "789"
e assim por diante.

Extent:

Descrição: O bloqueio de extent é aplicado em um intervalo contíguo de páginas

(normalmente 8 páginas) no banco de dados. Permite que apenas uma transação
acesse esse intervalo.
Exemplo: Se uma transação está acessando um conjunto de páginas que compreende
um extent, outras transações não podem acessar as páginas dentro desse extent.

HOBT (Heap or B-tree):

Descrição: O bloqueio de HOBT é aplicado em uma estrutura de dados específica,

como um heap (tabela sem índices) ou uma árvore B. Permite que outras transações
leiam simultaneamente.
Exemplo: Se uma transação está lendo um heap (tabela sem índices), outras
transações podem ler outras tabelas ou estruturas de dados semelhantes
simultaneamente.

Tabela (Table):

Descrição: O bloqueio de tabela é aplicado na tabela inteira. Permite que outras

transações leiam simultaneamente.
Exemplo: Se uma transação está lendo ou modificando uma tabela específica, outras
transações podem ler ou modificar outras tabelas simultaneamente.

Arquivo (File):

Descrição: O bloqueio de arquivo é aplicado em todo o arquivo de banco de dados.

Permite que apenas uma transação acesse o arquivo por vez.
Exemplo: Se uma transação está acessando um arquivo de banco de dados para
leitura ou gravação, outras transações não podem acessar esse arquivo
simultaneamente.

Aplicativo (Application):

Descrição: O bloqueio de aplicativo é aplicado em recursos específicos de um

aplicativo. Permite que apenas uma transação acesse esses recursos por vez.

9
Exemplo: Se uma transação está acessando recursos específicos de um aplicativo,
como um arquivo de configuração, outras transações não podem acessar esses
recursos simultaneamente.

Metadados (Metadata):

Descrição: O bloqueio de metadados é aplicado nos metadados do banco de dados,

impedindo que outras transações modifiquem as informações sobre a estrutura dos
objetos.
Exemplo: Se uma transação está modificando a estrutura de uma tabela, outros
metadados relacionados, como a definição de índices, não podem ser modificados
simultaneamente.

Unidade de Alocação (Allocation Unit):

Descrição: O bloqueio de unidade de alocação é aplicado em uma unidade de

alocação específica, que é uma estrutura de armazenamento lógica usada pelo SQL
Server.
Exemplo: Se uma transação está acessando uma unidade de alocação, outras
transações não podem acessar essa mesma unidade simultaneamente.

Banco de Dados (Database):

Descrição: O bloqueio de banco de dados é aplicado em todo o banco de dados,

permitindo que apenas uma transação acesse o banco de dados por vez.
Exemplo: Se uma transação está acessando um banco de dados específico para
leitura ou gravação, outras transações não podem acessar esse banco de dados
simultaneamente.

9
 Tipo de bloqueio Descrição
Permite que várias transações leiam simultaneamente um objeto
bloqueio de Leitura
específico, mas impede que outras transações façam alterações.
Permite que apenas uma transação tenha acesso exclusivo a um objeto,
bloqueio de Escrita
impedindo que outras transações leiam ou escrevam.
É uma forma especial de bloqueio de leitura que é convertido em um
bloqueio de Atualização

Tipos de bloqueio de Linha

bloqueio de escrita quando uma transação modifica os dados.
Bloqueia uma linha específica em uma tabela, permitindo que outras
transações leiam outras linhas simultaneamente.
Bloqueia uma página específica de dados, impedindo que outras

bloqueios bloqueio de Página

bloqueio de Extensão
transações acessem ou modifiquem essa página.
Bloqueia um intervalo contíguo de páginas de dados no banco de dados,
permitindo que apenas uma transação acesse essas páginas.

SQL Server bloqueio de Esquema

bloqueio de Arquivo
Bloqueia um esquema inteiro de objetos, como uma tabela ou exibição,
impedindo que outras transações modifiquem a estrutura.
Bloqueia todo o arquivo de banco de dados, permitindo que apenas uma
transação acesse o arquivo por vez.
Bloqueia recursos específicos de um aplicativo, impedindo que outras
bloqueio de Aplicativo
transações acessem esses recursos simultaneamente.
Bloqueia os metadados do banco de dados, impedindo que outras
bloqueio de Metadados
transações modifiquem as informações sobre a estrutura dos objetos.
bloqueio de Unidade de Bloqueia uma unidade de alocação específica, que é uma estrutura de
Alocação armazenamento lógica usada pelo SQL Server.
Bloqueia todo o banco de dados, permitindo que apenas uma transação
bloqueio de Banco de Dados
acesse o banco de dados por vez.

Os shared locks (bloqueios compartilhados) são aplicados em operações que são

apenas para leitura (alteração e mudança de dados não é permitida), como a
utilização do comando SELECT, e permitem que duas transações possam utilizar um
mesmo recurso.

Duas transações podem ter um shared lock em um mesmo recurso, mesmo que uma
das transações ainda não tenha sido finalizada. Enquanto todas as linhas que irão
satisfazer a query não forem enviadas para o cliente, os shared locks serão mantidos.

Lembramos que o shared lock de um registro será liberado assim que o próximo
registro for lido.

10
 Nivel de Granularidade Descrição

Bloqueia uma linha específica dentro de uma tabela no Oracle.

bloqueio de Linha (Row) Garante a exclusividade de acesso à linha, evitando modificações
concorrentes.

Granularidade bloqueio de Tabela (Table)

Bloqueia uma tabela inteira no Oracle. Impede que outras
transações acessem ou modifiquem a tabela simultaneamente.

de bloqueios
bloqueio de Extensão Bloqueia uma extensão, que é um conjunto contíguo de blocos,
Oracle (Extent) no Oracle. Garante a exclusividade de acesso à extensão.

Bloqueia um segmento específico no Oracle, que pode ser uma

bloqueio de Segmento
tabela, índice, partição ou subpartição. Impede o acesso
(Segment)
concorrente ao segmento.

bloqueio de Banco de Bloqueia o banco de dados inteiro no Oracle. Permite apenas

Dados (Database) uma transação de acesso ao banco de dados por vez.

bloqueio de Linha (Row):

Descrição: O bloqueio de linha é aplicado em uma linha específica dentro de uma

tabela no Oracle. Ele garante a exclusividade de acesso à linha, evitando modificações
concorrentes. Quando uma transação adquire um bloqueio de linha em uma
determinada linha, outras transações não podem modificar a mesma linha até que o
bloqueio seja liberado.

Exemplo: Suponha que duas transações (T1 e T2) estejam lendo e modificando a
mesma linha em uma tabela de clientes. Se a transação T1 adquirir um bloqueio de
linha em uma linha específica enquanto está atualizando os dados, a transação T2
não poderá modificar essa mesma linha até que T1 libere o bloqueio.

bloqueio de Tabela (Table):

Descrição: O bloqueio de tabela é aplicado em uma tabela inteira no Oracle. Ele

impede que outras transações acessem ou modifiquem a tabela simultaneamente.
Quando uma transação adquire um bloqueio de tabela, outras transações não podem

11
ler nem modificar os dados dessa tabela até que o bloqueio seja liberado.

Exemplo: Se uma transação T1 estiver realizando uma atualização em uma tabela de

pedidos, ela pode adquirir um bloqueio de tabela, impedindo que outras transações
(por exemplo, T2, T3) leiam ou modifiquem os dados dessa tabela até que a
transação T1 libere o bloqueio.

bloqueio de Extensão (Extent):

Descrição: O bloqueio de extensão é aplicado em uma extensão no Oracle, que é um

conjunto contíguo de blocos. Ele garante a exclusividade de acesso à extensão.
Quando uma transação adquire um bloqueio de extensão, outras transações não
podem acessar ou modificar os blocos contidos nessa extensão até que o bloqueio
seja liberado.

Exemplo: Se uma transação T1 estiver lendo os dados contidos em uma extensão

específica em uma tabela, ela pode adquirir um bloqueio de extensão para garantir
que nenhuma outra transação (por exemplo, T2) possa acessar ou modificar os
blocos dessa extensão simultaneamente.

bloqueio de Segmento(Segment):

Descrição: O bloqueio de segmento é aplicado em um segmento específico no

Oracle. Um segmento pode ser uma tabela, um índice, uma partição ou uma
subpartição. Ele impede o acesso concorrente ao segmento, garantindo a
exclusividade de acesso. Quando uma transação adquire um bloqueio de segmento
em um segmento específico, outras transações não podem acessar ou modificar os
dados desse segmento até que o bloqueio seja liberado.

Exemplo: Se uma transação T1 estiver executando uma operação de exclusão em

uma partição específica de uma tabela, ela pode adquirir um bloqueio de segmento
para essa partição, impedindo que outras transações (por exemplo, T2) acessem ou
modifiquem os dados dessa partição simultaneamente.

bloqueio de Banco de Dados (Database):

Descrição: O bloqueio de banco de dados é aplicado em todo o banco de dados no

Oracle. Ele permite que apenas uma transação acesse o banco de dados por vez,
garantindo a exclusividade de acesso. Quando uma transação adquire um bloqueio
de banco de dados, nenhuma outra transação pode acessar ou modificar os dados do
banco de dados até que o bloqueio seja liberado.

11
Exemplo: Se uma transação T1 estiver realizando uma operação crítica em um banco
de dados específico, ela pode adquirir um bloqueio de banco de dados, garantindo
que nenhuma outra transação (por exemplo, T2) possa acessar ou modificar qualquer
dado nesse banco de dados até que T1 libere o bloqueio.

11
 Nível de Tipo de
Granularidade bloqueio Descrição
Bloqueio de Linha
(Row) Registro Aplicado a um registro específico em uma tabela.

Evita que outras transações modifiquem o mesmo registro.

Bloqueio de
Granularidade Página(Page)
Página Aplicado a uma página física no armazenamento do banco de dados.

Afeta vários registros dentro da página.

de bloqueios Bloqueio de tabela

(Table)
Tabela Aplicado a toda a tabela.

PostgreSQL Bloqueio de Banco de

Impede o acesso de outras transações à tabela.

Banco de Dados Aplicado a todo o banco de dados.

dados (Database)

Impede o acesso a qualquer objeto dentro do banco de dados.

Bloqueio de objeto
Objeto Aplicado a objetos específicos no banco de dados, como funções,
(object)

visões e sequências.

No PostgreSQL, existem vários tipos de bloqueios que podem ocorrer durante as

transações. Aqui estão os principais tipos de bloqueios:

1.Bloqueio de Registro (Row-Level Lock):

Descrição: O bloqueio de registro é aplicado a um registro específico em uma
tabela.

Funcionamento: Quando uma transação atualiza, insere ou exclui um registro,

ela adquire um bloqueio de registro exclusivo (bloqueio de gravação) para
garantir que outras transações não possam modificar o mesmo registro
simultaneamente. Outras transações podem adquirir bloqueios de leitura para
ler o registro, desde que não haja bloqueio de gravação.

Exemplo: Uma transação T1 atualiza um registro em uma tabela, adquirindo

um bloqueio de gravação exclusivo para esse registro. Se outra transação T2
tentar atualizar o mesmo registro ao mesmo tempo, ela será bloqueada até
que o bloqueio de gravação de T1 seja liberado.

2.Bloqueio de Página (Page-Level Lock):

12
 Descrição: O bloqueio de página é aplicado a uma página física no
armazenamento do banco de dados, que contém vários registros.

Funcionamento: Quando uma transação requer um bloqueio em uma página,

ela pode bloquear toda a página para outras transações que desejam acessar
qualquer registro dentro dessa página. Isso pode resultar em bloqueios mais
amplos e pode afetar o desempenho em situações de alta concorrência.

Exemplo: Uma transação T1 adquire um bloqueio de gravação em uma página

contendo vários registros. Isso impede que outras transações leiam ou
escrevam em qualquer registro nessa página até que o bloqueio seja liberado
por T1.

1.Bloqueio de Tabela (Table-Level Lock):

Descrição: O bloqueio de tabela é aplicado a toda a tabela.

Funcionamento: Quando uma transação adquire um bloqueio de tabela, ela

impede que outras transações modifiquem ou leiam qualquer dado da tabela
até que o bloqueio seja liberado. O bloqueio de tabela é menos granular e
pode causar contenção se várias transações precisarem acessar a mesma
tabela ao mesmo tempo.

Exemplo: Uma transação T1 adquire um bloqueio de tabela exclusivo para a

tabela A. Isso impede que outras transações modifiquem ou leiam qualquer
dado da tabela A até que o bloqueio seja liberado por T1.

2.Bloqueio de Banco de Dados (Database-Level Lock):

Descrição: O bloqueio de banco de dados é aplicado a todo o banco de dados.

Funcionamento: Quando uma transação adquire um bloqueio de banco de

dados, ela impede que outras transações acessem qualquer objeto no banco
de dados. O bloqueio de banco de dados é um nível de bloqueio mais alto e é
usado para situações em que é necessário impedir o acesso geral ao banco de
dados.

Exemplo: Uma transação T1 adquire um bloqueio exclusivo no banco de

dados inteiro. Isso impede que outras transações acessem qualquer objeto
dentro do banco de dados até que o bloqueio seja liberado por T1.

12
Além desses bloqueios, também existem bloqueios de objeto, como bloqueios de
função, bloqueios de visão e bloqueios de sequência

12
Contenção de banco de dados
• Contenção é uma ação que ocorre em banco de dados que
provoca um evento denominado espera (Wait), neste caso um
processo que esteja ocasionando contenção do banco de dados
durante a sua execução , irá provocar à espera (wait) de um ou
mais outros processos.
• Contenções podem ocorrer de forma ocasional e muitas vezes não
poderá ser evitada, mas Podemos identifica-la e quando a sua
origem for algo que Podemos controlar ou ajustar , devemos faze-
lo sob pena de provocação de lentidão para um ou todas as
demais sessões de banco de dados em andamento.
• Contenções podem ocorrer o problema é a intensidade das
esperas que possa provocar e o tempo de duração das mesmas.
• Contenções são a causa de problemas e as esperas são os efeitos,
por isso todo processo de tuning visando a eliminação de gargalos
de performance passa pela identificação das contenções

13
 Categorias de
contenção de banco
de dados

As contenções pode advir de diversas

circunstâncias , inclusive de causas
múltiplas , porem normalmente de uma
causa maior.
A seguir listaremos os principais
categotias de contenção de banco de
dados:
• Contenção de Memória
• Contenção de I/O
• Contenção de Processador
• Contenção de Rede

De forma geral as contenções de banco de dados devem ser tratadas de forma mais
genérica para a mais específica, especialmente quando os problemas de performance
ocorram de maneira constante e não haja processos regulares de análise de
performance.

A lista acima não determina nenhuma hierarquia de contenções de banco de dados, a

hierarquia seria no primeiro nível as contenções de hardware (memória, I/O ,
processador e rede)

1.Contenção de Memória (Memory Contetion): A contenção de memória ocorre

quando há uma competição por recursos de memória no banco de dados. Pode
acontecer quando o banco de dados está configurado com uma quantidade
insuficiente de memória para lidar com a carga de trabalho exigida. A contenção de
memória pode resultar em diminuição do desempenho, aumento da latência das
transações e possíveis falhas devido à falta de memória para executar as operações
necessárias. Para mitigar a contenção de memória, é necessário monitorar o uso de
memória, ajustar os parâmetros de configuração relacionados à alocação de memória
e, se necessário, adicionar mais memória física ao sistema.

14
2. Contenção de E/S (entrada e saída) (I/O Contention): A contenção de E/S ocorre
quando várias operações de leitura e gravação competem por recursos de E/S, como
discos rígidos ou unidades de estado sólido (SSDs). Isso pode acontecer quando há
um número excessivo de transações simultâneas que requerem acesso a dados
armazenados em dispositivos de armazenamento. A contenção de E/S pode levar a
atrasos nas operações de leitura e gravação, resultando em uma diminuição no
desempenho do banco de dados. Para lidar com a contenção de E/S, é possível
adotar técnicas como o uso de armazenamento em cache, otimização de consultas,
particionamento de tabelas ou distribuição de dados em diferentes dispositivos de
armazenamento.

3.Contenção de Processamento (Processing Contention): A contenção de

processamento ocorre quando há uma competição pelos recursos de CPU disponíveis
no sistema. Isso pode ocorrer quando há um número excessivo de transações ou
consultas concorrentes sendo executadas simultaneamente. A contenção de
processamento pode levar a atrasos no processamento de consultas, tempo de
resposta mais lento e diminuição do desempenho geral do banco de dados. Para
mitigar a contenção de processamento, é necessário otimizar consultas, implementar
índices apropriados, ajustar os parâmetros de configuração relacionados à alocação
de recursos de CPU e, se necessário, considerar a escalabilidade horizontal ou vertical
do sistema.

4.Contenção de Redes (Network Contention): A contenção de redes ocorre quando

há uma competição por recursos de rede, como largura de banda ou capacidade de
transferência de dados. Isso pode acontecer quando há uma grande quantidade de
tráfego de rede entre clientes e o banco de dados, especialmente em ambientes
distribuídos ou com alto número de conexões simultâneas. A contenção de redes
pode resultar em atrasos nas comunicações entre os componentes do banco de
dados, o que pode afetar o desempenho e a escalabilidade do sistema. Para mitigar a
contenção de redes, é necessário avaliar a infraestrutura de rede, considerar a
otimização de consultas e a minimização da transferência desnecessária de dados
pela rede, além de dimensionar adequadamente os recursos de rede para atender à
demanda.

14
 Tipos de contenção
de banco de dados
As contenções pode advir de diversas circunstâncias , inclusive de causas
múltiplas , porem normalmente de uma causa maior.
A seguir listaremos os principais tipos de contenção de banco de dados:
• Contenção de bloqueio (Lock Contention)
• Contenção de Página/Bloco (Page/Block Contention)
• Contenção de Tabela (Table Contention)
• Contenção de Índice (Index Contention)
• Contenção por Checkpoint (Checkpoint Contention)
• Contenção por Gravação de Log (Log Writing Contention)
• Contenção por Gravação de Datafile (Datafile Writing Contention)
• Contenção por Arquivamento (Archiving Contention)
• Contenção de Tablespace/Filegroup
• Contenção de Datafile
• Contenção de Memória/Instancia
• Contenção de Processos Background
• Contenção de Processos Server ou Worker

A contenção em bancos de dados ocorre quando várias transações ou processos

tentam acessar simultaneamente os mesmos recursos de dados, resultando em
bloqueios e atrasos no processamento. Isso pode levar a uma diminuição no
desempenho do banco de dados e até mesmo causar falhas nas transações. Existem
diferentes tipos de contenção que podem ocorrer:

1.Contenção de bloqueio (Lock Contention): Esse tipo de contenção ocorre quando

duas transações ou processos tentam acessar o mesmo objeto de dados ao mesmo
tempo e uma transação precisa esperar que a outra seja concluída antes de poder
prosseguir. Existem diferentes níveis de bloqueio, como bloqueio exclusivo (X-lock) e
bloqueio compartilhado (S-lock), e a contenção ocorre quando duas transações têm
bloqueios incompatíveis no mesmo objeto de dados.

2.Contenção de página (Page Contention): A contenção de página ocorre quando

várias transações ou processos estão tentando acessar simultaneamente páginas de
dados específicas em um banco de dados. Se várias transações estiverem tentando
acessar a mesma página ao mesmo tempo, isso pode resultar em bloqueios e
atrasos.

15
3. Contenção de tabela (Table Contention): Esse tipo de contenção ocorre quando
várias transações estão tentando acessar a mesma tabela de banco de dados ao
mesmo tempo. Pode acontecer quando há uma alta concorrência para acessar uma
tabela específica, o que pode levar a bloqueios e atrasos.

4.Contenção de índice (Index Contention): A contenção de índice ocorre quando

várias transações estão tentando acessar simultaneamente o mesmo índice de banco
de dados. Os índices são usados para acelerar as consultas e, quando várias
transações estão atualizando ou acessando o mesmo índice, pode haver bloqueios e
atrasos.

5.Contenção por Checkpoint (Checkpoint Contention): A contenção por checkpoint

ocorre durante o processo de checkpoint em um banco de dados. Um checkpoint é
um ponto de sincronização em que os dados modificados são gravados nos arquivos
de dados permanentes. Durante um checkpoint, as transações podem ser
temporariamente suspensas para permitir que os dados sejam gravados em disco. A
contenção ocorre quando várias transações estão competindo para gravar os dados
modificados nos arquivos de dados, o que pode resultar em atrasos e bloqueios.

6.Contenção por Gravação de Log (Log Writing Contention): A contenção por

gravação de log ocorre durante o processo de gravação das informações de log de
transações no log de transações do banco de dados. O log de transações é usado para
registrar todas as operações realizadas no banco de dados. Quando várias transações
estão tentando gravar simultaneamente no log de transações, pode haver contenção,
resultando em bloqueios e atrasos.

7.Contenção por Gravação de Datafile (Datafile Writing Contention): A contenção por

gravação de datafile ocorre durante a gravação de dados modificados nos arquivos de
dados permanentes do banco de dados. Quando várias transações estão competindo
para gravar simultaneamente nos mesmos datafiles, pode haver contenção, causando
bloqueios e atrasos nas operações de gravação de dados.

8.Contenção por Arquivamento (Archiving Contention): A contenção por

arquivamento ocorre durante o processo de arquivamento de dados antigos ou
inativos do banco de dados. O arquivamento é importante para manter o
desempenho do banco de dados e garantir a integridade dos dados. A contenção
ocorre quando várias transações estão competindo para acessar os arquivos de
backup ou de histórico durante o processo de arquivamento, o que pode resultar em
bloqueios e atrasos nas operações de arquivamento.

9.Contenção de Tablespace: A contenção de tablespace ocorre quando várias

transações ou operações estão competindo pelo acesso ou espaço disponível dentro

15
de um tablespace específico. Pode ocorrer quando há um aumento significativo na
atividade de gravação ou quando uma tabela ou índice específico está sendo
acessado por muitas transações simultaneamente. A contenção de tablespace pode
levar a bloqueios, atrasos na execução de consultas e diminuição do desempenho do
banco de dados.

10.Contenção de Datafile: A contenção de datafile ocorre quando várias operações

estão competindo pelos recursos de gravação ou leitura nos arquivos de dados do
banco de dados. Isso pode acontecer quando há um número excessivo de transações
simultâneas ou quando os arquivos de dados estão mal dimensionados para lidar
com a carga de trabalho. A contenção de datafile pode resultar em atrasos nas
operações de leitura e gravação, afetando o desempenho geral do banco de dados.

11.Contenção de Memória: A contenção de memória ocorre quando várias

transações ou processos competem pelos recursos de memória disponíveis no
sistema. Isso pode acontecer quando o banco de dados está configurado com uma
quantidade insuficiente de memória para atender à carga de trabalho exigida. A
contenção de memória pode resultar em diminuição do desempenho, aumento da
latência das transações e possíveis falhas devido à falta de memória para executar as
operações necessárias.

12.Contenção de Instância: A contenção de instância ocorre quando várias transações

ou operações estão competindo pelos recursos disponíveis na instância do banco de
dados. Isso pode incluir bloqueios, buffer cache, gerenciamento de espaço em disco,
entre outros. A contenção de instância pode ser causada por um número excessivo
de conexões simultâneas, configurações inadequadas de parâmetros ou um design de
banco de dados mal otimizado.

13.Contenção de Processos Background: A contenção de processos background

ocorre quando os processos em segundo plano responsáveis por tarefas
administrativas e operacionais competem por recursos, como CPU, memória ou E/S
de disco, com as transações ativas no banco de dados. Isso pode levar a atrasos nas
tarefas de manutenção do banco de dados e afetar o desempenho geral do sistema.

14.Contenção de Processos Server ou Worker: A contenção de processos server ou

worker ocorre em ambientes cliente-servidor, quando várias solicitações de clientes
estão competindo pelos recursos do servidor. Isso inclui threads de processamento,
conexões com o banco de dados, recursos de CPU e memória. A contenção de
processos server ou worker pode ser causada por uma sobrecarga de solicitações de
clientes, consultas ineficientes ou configurações inadequadas de parâmetros.

15
 Contenção de
bloqueio (Lock
contention)

• A contenção por bloqueio ocorre quando duas

ou mais transações competem pelo acesso a
recursos de dados no banco de dados e uma
transação precisa esperar que a outra seja
concluída antes de poder prosseguir. Esse tipo
de contenção pode ter várias causas e
impactos significativos.
• As possíveis causas poderiam ser:
• Conflitos de bloqueio
• Transações Longas
• Seleção correta do nível de isolamento
de uma transação
• Design inadequado do banco de dados

Causas da contenção por bloqueio:

1.Conflitos de bloqueio: Quando duas ou mais transações tentam adquirir bloqueios

incompatíveis em um recurso de dados específico, ocorre um conflito de bloqueio.
Por exemplo, se uma transação adquiriu um bloqueio exclusivo (X-lock) em uma
tabela e outra transação tentar adquirir um bloqueio compartilhado (S-lock) na
mesma tabela, haverá um conflito.

2.Transações longas: Transações que executam operações complexas ou envolvem

grandes quantidades de dados podem manter bloqueios por um longo período,
bloqueando assim outros processos que desejam acessar os mesmos recursos.

3.Seleção incorreta de nível de isolamento: O nível de isolamento de uma transação

determina o grau de visibilidade das alterações realizadas por outras transações.
Selecionar um nível de isolamento mais restrito do que o necessário pode resultar
em bloqueios desnecessários.

4.Design de banco de dados inadequado: Um design de banco de dados mal

otimizado, como a falta de índices apropriados ou tabelas mal estruturadas, pode

16
aumentar a probabilidade de contenção por bloqueio.

Impactos da contenção por bloqueio:

1.Diminuição do desempenho: A contenção por bloqueio pode levar a atrasos

significativos no processamento de transações, resultando em uma diminuição geral
do desempenho do banco de dados. As transações precisam esperar pela liberação
de bloqueios antes de prosseguir, o que aumenta o tempo de resposta e pode causar
gargalos.

2.Deadlocks: Um deadlock ocorre quando duas ou mais transações ficam bloqueadas

mutuamente, aguardando recursos que a outra transação possui. Isso pode levar a
uma situação em que as transações não podem avançar e requerem intervenção
externa para resolver o impasse.

3.Falhas nas transações: Em casos extremos, a contenção por bloqueio pode resultar
em falhas nas transações. Se uma transação atingir o limite de tempo máximo de
espera para adquirir um bloqueio, pode ser forçada a ser encerrada, resultando em
uma transação não confirmada e possível perda de dados.

4.Inconsistência de dados: Quando ocorrem bloqueios, as transações podem ler ou

escrever dados parcialmente atualizados ou inconsistentes, dependendo do
momento em que adquirem os bloqueios. Isso pode levar a resultados inesperados e
comprometer a integridade dos dados.

16
 Contenção por página /Bloco (Page/Block)
contention
• A contenção por página (SQL Server e PostgreSQL) ou de bloco
(Oracle) podem ocorrer por excesso de transações concorrentes
em uma mesma página ou Bloco, especialmente comandos
Update, embora também possam ocorrer com insert e delete
também. Outra causa de contenção por página pode ser a questão
de imposição de bloqueios (automáticos ou manuais) as páginas,
no que se refere a blocos (Oracle) não é possível isso, pois não
possui este tipo de granularidade para bloqueios
• Possíveis causas:
• Acesso concorrente a página/Bloco
• Tipo de bloqueio incompatível (SQL Server e PostgreSQL)
• Fragmentação em disco (Discos SAS rígidos)
• Ineficiência das consultas

A contenção de página/bloco ocorre quando várias transações ou processos estão

competindo pelo acesso a páginas ou blocos específicos de dados em um banco de
dados. Isso pode causar bloqueios e atrasos nas operações. Aqui está uma explicação
detalhada sobre suas causas e impactos:

Causas da contenção de página/bloco:

1.Acesso concorrente a páginas/blocos: Quando várias transações ou processos estão
tentando acessar simultaneamente as mesmas páginas ou blocos de dados, pode
ocorrer a contenção. Isso pode ocorrer quando diferentes transações estão
acessando a mesma tabela, índice ou região de dados.

2.bloqueio incompatível: Se uma transação tiver adquirido um bloqueio exclusivo (X-

lock) em uma página ou bloco, outras transações que desejam adquirir um bloqueio
compartilhado (S-lock) ou um bloqueio exclusivo na mesma página ou bloco terão
que esperar, resultando em contenção.

3.Fragmentação do espaço em disco: Se os dados estiverem fragmentados em

diferentes páginas ou blocos devido a inserções, exclusões ou atualizações
frequentes, várias transações podem acabar competindo pelo acesso a diferentes

17
páginas ou blocos, resultando em contenção.

4.Ineficiência nas consultas: Consultas ineficientes que exigem acesso a muitas

páginas ou blocos de dados podem aumentar a contenção de página/bloco. Isso pode
ocorrer quando consultas realizam varreduras completas em grandes tabelas ou
quando consultas mal projetadas resultam em acesso indiscriminado a
páginas/blocos desnecessários.

Impactos da contenção de página/bloco:

1.Diminuição do desempenho: A contenção de página/bloco pode levar a atrasos no

processamento de transações, resultando em uma diminuição geral do desempenho
do banco de dados. As transações precisam esperar pela liberação dos bloqueios nas
páginas/blocos antes de poderem continuar, aumentando o tempo de resposta.

2.bloqueios prolongados: Se uma transação mantiver um bloqueio em uma

página/bloco por um longo período, outras transações que desejam acessar a mesma
página/bloco podem enfrentar atrasos significativos. Isso pode levar a um efeito
cascata de bloqueios prolongados, impactando negativamente o desempenho e a
escalabilidade do sistema.

3.Deadlocks: Em alguns casos, a contenção de página/bloco pode levar a deadlocks,

em que duas ou mais transações ficam bloqueadas mutuamente, esperando por
recursos que a outra transação possui. Isso pode paralisar completamente o
processamento e requerer intervenção manual para resolver a situação.

4.Inconsistência de dados: A contenção de página/bloco pode resultar em leituras ou

gravações parciais ou inconsistentes, dependendo do momento em que as transações
adquirem os bloqueios. Isso pode levar a resultados inesperados e comprometer a
integridade dos dados.

Para Oracle a contenção de bloco pode ser resolvida mediante o aumento de

transações simultâneas ao bloco até 255, ou a diminuição do tamanho do bloco para
tentar dimunuir o numero de transações simultâneas em um bloco menor.

Para SQL Server a contenção de página pode ser resolvida entendendo o volume
transacional por página e o tempo de bloqueio da página. Veremos nos próximos
capítulos como identificar este tipo de contenção em SQL Server.

17
 Contenção de Tabela - (Table contention)
• A contenção de índice pode ser uma causa de problemas de performance, pois ações de
inserção, atualização e exclusão podem ser diretamente afetadas em função deste tipo
de contenção, em casos mais severos até mesmo consultas podem ser afetadas.
• Este tipo de contenção pode ser provocado por armazenamento de dados ineficiente
(discos mais lentos) ou por questões de excesso de demanda e bloqueios sobre o índice,
somado a um hardware potencialmente ineficiente, ou mediante um excesso de carga de
trabalho simultâneo.

• Possíveis causas:
• Tipo de bloqueio incompatível
• Atualizações Concorrentes
• Inserções Concorrentes
• Deleções concorrentes

A contenção de tabela ocorre quando várias transações estão competindo pelo

acesso a uma mesma tabela em um banco de dados. Isso pode levar a bloqueios e
atrasos no processamento das transações. Vamos explorar as causas e os impactos da
contenção de tabela:

Causas da contenção de tabela:

1.bloqueio incompatível: Se uma transação adquirir um bloqueio exclusivo (X-lock)

em uma tabela, outras transações que desejarem adquirir bloqueios incompatíveis,
como bloqueios compartilhados (S-lock), terão que esperar. Isso pode resultar em
contenção de tabela.

2.Atualizações concorrentes: Se várias transações estiverem realizando atualizações

simultâneas na mesma tabela, elas podem entrar em conflito e causar contenção.
Isso ocorre especialmente quando as atualizações estão alterando as mesmas linhas
ou regiões de dados.

3.Inserções concorrentes: Transações que estão inserindo dados em uma tabela ao

mesmo tempo podem causar contenção, especialmente se estiverem tentando

18
inserir registros nas mesmas páginas de dados.

4.Deleções concorrentes: A exclusão de registros de uma tabela por transações

concorrentes também pode resultar em contenção. Se várias transações estiverem
tentando remover registros da mesma página de dados, isso pode levar a bloqueios e
atrasos.

Impactos da contenção de tabela:

1.Diminuição do desempenho: A contenção de tabela pode levar a atrasos no

processamento de transações, resultando em uma diminuição geral do desempenho
do banco de dados. As transações precisam esperar pela liberação dos bloqueios na
tabela antes de prosseguirem, aumentando o tempo de resposta.

2.bloqueios prolongados: Se uma transação mantiver um bloqueio exclusivo em uma

tabela por um longo período, outras transações que desejarem acessar a mesma
tabela podem enfrentar atrasos significativos. Isso pode criar um efeito cascata de
bloqueios prolongados, impactando negativamente o desempenho e a escalabilidade
do sistema.

3.Deadlocks: Em casos extremos, a contenção de tabela pode levar a deadlocks, onde

duas ou mais transações ficam bloqueadas mutuamente, aguardando recursos que a
outra transação possui. Isso pode paralisar completamente o processamento e
requerer intervenção manual para resolver a situação.

4.Inconsistência de dados: A contenção de tabela pode resultar em leituras ou

gravações parciais ou inconsistentes, dependendo do momento em que as transações
adquirem os bloqueios. Isso pode levar a resultados inesperados e comprometer a
integridade dos dados.

18
 Contenção de Índice - (Index contention)
• A contenção de tabela pode ser uma causa de problemas de performance, pois ações de
inserção, atualização e exclusão podem ser diretamente afetadas em função deste tipo
de contenção, em casos mais severos até mesmo consultas podem ser afetadas.
• Este tipo de contenção pode ser provocado por armazenamento de dados ineficiente
(discos mais lentos) ou por questões de excesso de demanda e bloqueios sobre a tabela,
somado a um hardware potencialmente ineficiente, ou mediante um excesso de carga de
trabalho simultâneo.

• Possíveis causas:
• Tipo de bloqueio incompatível
• Atualizações Concorrentes
• Inserções Concorrentes
• Deleções concorrentes

Peço desculpas pelo equívoco anterior. Agora, vou explicar sobre a contenção de
índice (Index Contention) em detalhes:

A contenção de índice ocorre quando várias transações competem pelo acesso e

modificação das estruturas de um mesmo índice em um banco de dados. Isso pode
levar a bloqueios, atrasos no processamento das transações e impactar o
desempenho do sistema. Vamos explorar as causas e os impactos da contenção de
índice:

Causas da contenção de índice:

1.Atualizações simultâneas: Quando várias transações realizam atualizações ou

inserções concorrentes em uma tabela que possui um índice, elas podem precisar
modificar as mesmas páginas de índice. Isso ocorre especialmente quando as
atualizações estão relacionadas às mesmas chaves de índice, gerando competição e
contenção.

2.Inserções em uma mesma chave de índice: Se várias transações estiverem tentando

inserir registros com a mesma chave em um índice, elas podem precisar acessar a

19
mesma página de índice para realizar a operação. Isso pode resultar em bloqueios e
atrasos devido à competição pelo acesso ao mesmo recurso.

3.Remoções concorrentes: Transações que estão removendo registros de uma tabela

também podem precisar atualizar ou remover as entradas correspondentes no índice.
Se várias transações estiverem tentando remover registros com a mesma chave de
índice, isso pode gerar contenção e bloqueios.

Impactos da contenção de índice:

1.Diminuição do desempenho: A contenção de índice pode causar atrasos no

processamento de transações, resultando em uma redução geral do desempenho do
banco de dados. As transações precisam esperar pela liberação dos bloqueios nas
páginas de índice antes de prosseguirem, aumentando o tempo de resposta e
diminuindo a eficiência do sistema.

2.bloqueios prolongados: Se uma transação mantiver bloqueios exclusivos em

páginas de índice por um longo período, outras transações que desejarem acessar as
mesmas páginas podem enfrentar atrasos significativos. Isso pode gerar um efeito
cascata de bloqueios prolongados, prejudicando o desempenho e a escalabilidade do
sistema.

3.Deadlocks: Em situações extremas, a contenção de índice pode levar a deadlocks,

onde duas ou mais transações ficam bloqueadas mutuamente, aguardando recursos
que a outra transação possui. Isso paralisa completamente o processamento e requer
intervenção manual para resolver a situação.

4.Inconsistência de dados: A contenção de índice pode resultar em leituras ou

gravações parciais ou inconsistentes, dependendo do momento em que as transações
adquirem os bloqueios. Isso pode levar a resultados inesperados e comprometer a
integridade dos dados armazenados no banco de dados.

Para lidar com a contenção de índice, são necessárias estratégias adequadas de

gerenciamento de transações. Isso inclui otimizar consultas, revisar o design do
banco de dados, utilizar índices apropriados, particionar tabelas, distribuir
adequadamente a carga de trabalho, ajustar os níveis de isolamento e implementar
bloqueios corretamente para minimizar a contenção e melhorar o desempenho do
sistema. É fundamental monitorar e identificar padrões de contenção de índice para
otimizar a estrutura do índice e evitar problemas futuros.

19
 Contenção de checkpoint - (checkpoint
contention)
• A contenção de checkpoint pode indicar problemas graves em um banco de
dados, especialmente se a incidências destes problemas forem frequentes. A
contenção por checkpoint impede que as páginas de memória possam fluir dos
buffers e caches de memória para o meio físico. Checkpoints são um importante
instrumento também para a recuperação do banco de dados , pois depois de
ocorrerem criam um sincronismo entre memória e disco , mesmo que por
período de tempo muito curto. Em caso de falha as transações depositadas.

• Possíveis causas:
• Buffer cache mal dimensionado ou
inadequado
• Atividade intensa de
movimentação de banco de dados
• Configuração do tempo de
checkpoint quando possível

A contenção de checkpoint (checkpoint contention) ocorre quando várias transações

estão competindo para executar checkpoints em um banco de dados. O checkpoint é
um mecanismo que grava as páginas de dados modificadas da memória para o disco,
garantindo que as alterações sejam persistentes e duradouras. Vamos explorar as
causas e os impactos da contenção de checkpoint:

Causas da contenção de checkpoint:

1.Atividade intensa de gravação: Se houver um alto volume de operações de gravação

ocorrendo no banco de dados, muitas transações podem estar modificando páginas
de dados simultaneamente. Isso pode resultar em um grande número de checkpoints
sendo disparados e, consequentemente, em contenção.

2.Tamanho do buffer cache: O tamanho do buffer cache, que é a área de memória

usada para armazenar páginas de dados em cache, também pode desempenhar um
papel na contenção de checkpoint. Se o buffer cache for pequeno em relação à carga
de trabalho do banco de dados, as páginas de dados modificadas precisarão ser
gravadas no disco com mais frequência, aumentando a probabilidade de contenção.

20
3. Configuração do intervalo de checkpoint: O intervalo de tempo entre os
checkpoints também pode influenciar a contenção. Se o intervalo for muito curto,
haverá checkpoints frequentes, aumentando a chance de contenção. Por outro lado,
se o intervalo for muito longo, pode ocorrer uma grande quantidade de páginas de
dados modificadas na memória, resultando em checkpoints mais demorados e
possivelmente causando bloqueios.

Configuração de chekpoint em Oracle, SQL Server e PostgreSQL:

é possível configurar o tempo de execução do checkpoint em bancos de dados

Oracle, PostgreSQL e SQL Server. Esses sistemas de gerenciamento de banco de
dados oferecem recursos para ajustar o comportamento dos checkpoints de acordo
com as necessidades específicas do ambiente. Vejamos como configurar o tempo de
execução do checkpoint em cada um deles:

Oracle: No Oracle Database, o tempo de execução do checkpoint pode ser ajustado

configurando os parâmetros relacionados no banco de dados. Os principais
parâmetros envolvidos são:

FAST_START_MTTR_TARGET: Esse parâmetro controla o tempo médio para a

recuperação do banco de dados após uma falha. Aumentar esse valor pode
levar a menos checkpoints frequentes.
LOG_CHECKPOINT_INTERVAL: Define o intervalo de tempo, em segundos,
entre os checkpoints. Aumentar esse valor pode resultar em checkpoints
menos frequentes.
LOG_CHECKPOINT_TIMEOUT: Define o tempo máximo, em segundos, que um
checkpoint pode durar. Se um checkpoint não for concluído dentro desse
tempo, o Oracle forçará a conclusão.

PostgreSQL: No PostgreSQL, o tempo de execução do checkpoint pode ser ajustado

por meio de configurações relacionadas aos parâmetros de checkpoint. Os principais
parâmetros envolvidos são:
checkpoint_timeout: Define o tempo máximo, em segundos, entre os
checkpoints. Aumentar esse valor pode resultar em checkpoints menos
frequentes.
checkpoint_completion_target: Define a porcentagem do tempo entre
checkpoints no qual o sistema tentará concluir o checkpoint. Um valor mais
alto pode ajudar a diminuir o impacto do checkpoint no desempenho geral.

SQL Server: No SQL Server, o tempo de execução do checkpoint pode ser configurado

20
por meio das opções de recuperação do banco de dados. Os principais recursos
relacionados são:
recovery interval: Define o intervalo de tempo, em minutos, entre os
checkpoints. Aumentar esse valor pode resultar em checkpoints menos
frequentes.
target_recovery_time: Esse recurso permite definir o tempo médio de
recuperação do banco de dados após uma falha. Aumentar esse valor pode
levar a menos checkpoints frequentes.

É importante destacar que, ao ajustar o tempo de execução do checkpoint, deve-se

considerar o impacto na recuperação após falhas, no desempenho do sistema e nos
requisitos de disponibilidade dos dados. É recomendado fazer ajustes cuidadosos e
realizar testes de desempenho para avaliar o impacto das alterações antes de
implementá-las em um ambiente de produção.

Impactos da contenção de checkpoint:

1.Diminuição do desempenho: A contenção de checkpoint pode levar a atrasos na

execução de transações e operações no banco de dados. As transações podem
precisar esperar que os checkpoints sejam concluídos antes de prosseguirem,
resultando em uma diminuição geral do desempenho do sistema.

2.Aumento do tempo de recuperação: A contenção de checkpoint pode impactar o

tempo de recuperação do banco de dados. Se os checkpoints estiverem ocorrendo
com frequência e demorando mais tempo devido à contenção, a recuperação após
uma falha pode ser mais lenta e levar mais tempo para completar.

3.Risco de enfileiramento de transações: A contenção de checkpoint pode levar a um

enfileiramento de transações, onde várias transações estão aguardando para serem
executadas após um checkpoint ser concluído. Isso pode resultar em um
congestionamento do sistema e no aumento do tempo de resposta para as
transações.

4.Aumento da latência de E/S: A contenção de checkpoint pode causar um aumento

da latência de E/S, pois as páginas de dados modificadas precisam ser gravadas no
disco com mais frequência. Isso pode afetar negativamente o desempenho do
sistema, especialmente em cenários com carga de trabalho intensiva de gravação.

Para lidar com a contenção de checkpoint, podem ser adotadas várias estratégias,
como ajustar a configuração do intervalo de checkpoint, dimensionar

20
adequadamente o buffer cache, otimizar a carga de trabalho do banco de dados para
reduzir a atividade de gravação excessiva e monitorar o desempenho do sistema para
identificar e resolver problemas de contenção.

20
 Contenção de Log (Log
writing contention)

• Contenção de Log pode provocar grandes problemas de

performance em um banco de dados, inclusive outras
contenções e suas causas podem ser físicas como
hardware (controladoras e discos) , mas também
podem ser e mais frequentemente são causadas por
excesso de demanda por transações no banco de
dados.
• Podem ter causas eventuais ou podem ser causadas
por excesso de conexões simultâneas ou através da
execução de tarefas cuja função seja de gravar com
muita frequência no banco de dados.
• Não devemos confundir com a Contenção por
checkpoint .

A contenção por gravação de log (log writing contention) ocorre quando várias
transações estão competindo pelo acesso e gravação do log de transações em um
banco de dados. O log de transações é uma parte fundamental do sistema de
gerenciamento de banco de dados, responsável por registrar todas as operações
realizadas no banco de dados. Vamos explorar as causas e os impactos da contenção
por gravação de log:

Causas da contenção por gravação de log:

1.Atividade intensa de gravação: Se houver um alto volume de operações de gravação

ocorrendo no banco de dados, muitas transações podem estar gerando registros de
log simultaneamente. Isso pode resultar em um grande número de transações
competindo pelo acesso e gravação do log de transações, levando à contenção.

2.Tamanho do arquivo de log: O tamanho do arquivo de log pode desempenhar um

papel na contenção por gravação de log. Se o tamanho do arquivo de log não for
dimensionado adequadamente para lidar com a carga de trabalho do banco de
dados, as gravações frequentes no log podem levar a contenção e atrasos nas
operações.

21
3.Recuperação após falhas: Durante a recuperação do banco de dados após uma
falha, as transações precisam garantir que suas alterações sejam registradas no log de
transações. Se várias transações estiverem sendo recuperadas simultaneamente, isso
pode resultar em contenção na gravação de log.

Impactos da contenção por gravação de log:

1.Diminuição do desempenho: A contenção por gravação de log pode levar a atrasos

no processamento de transações, resultando em uma diminuição geral do
desempenho do banco de dados. As transações precisam esperar pela liberação do
acesso ao log de transações antes de prosseguirem, aumentando o tempo de
resposta e afetando a escalabilidade do sistema.

2.Atraso na recuperação após falhas: Durante a recuperação do banco de dados após

uma falha, a contenção por gravação de log pode levar a atrasos na aplicação das
alterações registradas no log. Isso pode prolongar o tempo de recuperação e afetar a
disponibilidade dos dados após uma falha.

3.Risco de perda de dados: Se a contenção por gravação de log for severa, pode
ocorrer um atraso significativo na gravação das operações de transação no log. Isso
pode aumentar o risco de perda de dados em caso de falhas no sistema ou
interrupções inesperadas.

4.Congestionamento do sistema: A contenção por gravação de log pode levar ao

congestionamento do sistema, com várias transações aguardando a gravação das
operações no log. Isso pode resultar em um aumento no tempo de resposta e uma
redução na capacidade de processamento das transações.

Para lidar com a contenção por gravação de log, é importante dimensionar

adequadamente o tamanho do arquivo de log, monitorar a atividade de gravação e
ajustar a configuração do sistema conforme necessário. Além disso, a otimização de
consultas, a revisão do design do banco de dados e o uso de técnicas de
particionamento de log podem ajudar a reduzir a contenção e melhorar o
desempenho geral do sistema.

Resolvendo problemas de contenção de gravação de Log em SQL Server , Oracle e

PostgreSQL:

SQL Server:

21
Ajuste do tamanho do arquivo de log: Verifique o tamanho do arquivo de log e
dimensione-o adequadamente para lidar com a carga de trabalho. Monitorar o
crescimento do log e ajustar o tamanho conforme necessário pode ajudar a evitar
contenção.

Configuração do modelo de recuperação: Avalie o modelo de recuperação usado no

banco de dados. Por exemplo, no modelo de recuperação completa, o log pode se
tornar grande e causar contenção. Considere usar um modelo de recuperação
diferente, como o modelo simples, se a recuperação completa não for necessária.

Backup e truncamento de log: Realize backups regulares do log de transações e

execute o truncamento adequado para manter o tamanho do log sob controle. Isso
ajudará a reduzir a contenção relacionada à gravação de log.

Oracle:

Configuração de grupos de redo log: Aumente o número de grupos de redo log para
distribuir a atividade de gravação. Isso ajuda a reduzir a contenção, permitindo que
várias sessões gravem em grupos de redo log diferentes simultaneamente.

Tamanho adequado do grupo de redo log: Dimensione adequadamente o tamanho

do grupo de redo log para acomodar a carga de trabalho do banco de dados. Um
tamanho de grupo de redo log muito pequeno pode resultar em trocas frequentes,
aumentando a contenção.

Monitoramento e ajuste do tamanho do buffer cache: Monitore o tamanho do buffer

cache e ajuste-o conforme necessário. Um tamanho de buffer cache insuficiente
pode levar a gravações frequentes no log, aumentando a contenção. Ajuste o
parâmetro DB_CACHE_SIZE para melhorar o desempenho.

PostgreSQL:

Configuração do parâmetro checkpoint_timeout: Ajuste o valor do parâmetro

checkpoint_timeout para aumentar ou diminuir a frequência dos checkpoints.
Experimente diferentes valores para encontrar um equilíbrio entre a contenção e o
desempenho.

Monitoramento do tamanho do arquivo de log: Monitore o tamanho do arquivo de

log e ajuste-o conforme necessário. Um tamanho inadequado pode resultar em
trocas frequentes de log e maior contenção.

21
Configuração de parâmetros de checkpoint: Ajuste os parâmetros de checkpoint
relacionados, como checkpoint_completion_target e checkpoint_segments, para
otimizar o processo de gravação do log. Isso pode ajudar a reduzir a contenção e
melhorar o desempenho.

Lembre-se de que cada banco de dados tem suas próprias características e opções de
configuração específicas. É importante consultar a documentação oficial do banco de
dados e realizar testes de desempenho para encontrar a melhor abordagem para
resolver problemas de contenção de log em seu ambiente específico.

21
 Contenção de gravação de
Datafile (Datafile Writing
Contention)

• A contenção por gravação de datafile (log writing

datafile) ocorre quando várias transações estão
competindo pelo acesso e gravação nos arquivos
de dados (datafiles) de um banco de dados. Essa
contenção pode ocorrer durante o processo de
gravação de alterações permanentes nos arquivos
de dados, afetando o desempenho do sistema. As
causas e os impactos da contenção por gravação
de datafile:
• Atividade intensa de gravação
• Commits em frequência inadequada
• Tamanho do buffer cache insuficiente
• Fragmentação de disco (discos rígidos)

A contenção por gravação de datafile (log writing datafile) ocorre quando várias
transações estão competindo pelo acesso e gravação nos arquivos de dados
(datafiles) de um banco de dados. Essa contenção pode ocorrer durante o processo
de gravação de alterações permanentes nos arquivos de dados, afetando o
desempenho do sistema. Vamos explorar as causas e os impactos da contenção por
gravação de datafile:

Causas da contenção por gravação de datafile:

1.Atividade intensa de gravação: Se houver um alto volume de operações de gravação

ocorrendo no banco de dados, como atualizações ou inserções em tabelas, muitas
transações podem estar competindo pelo acesso aos arquivos de dados. Isso resulta
em contenção durante o processo de gravação de datafile.

2.Tamanho do cache do buffer insuficiente: O cache do buffer é uma área de

memória onde os dados são temporariamente armazenados antes de serem
gravados nos arquivos de dados. Se o tamanho do cache do buffer for insuficiente
para a carga de trabalho do banco de dados, ocorrerá uma competição maior pelo
acesso aos arquivos de dados, levando à contenção.

22
3.Fragmentação de disco: Se os arquivos de dados estiverem fragmentados
fisicamente no disco, isso pode levar a tempos de acesso prolongados e maior
competição durante o processo de gravação. A fragmentação de disco pode resultar
em contenção e impactar o desempenho da gravação de datafile.

Impactos da contenção por gravação de datafile:

1.Diminuição do desempenho: A contenção por gravação de datafile pode causar

atrasos no processamento de transações e operações no banco de dados. As
transações precisam esperar pela liberação do acesso aos arquivos de dados antes de
prosseguirem, resultando em uma diminuição geral do desempenho do sistema.

2.Aumento do tempo de resposta: Devido à contenção, as transações podem

experimentar um aumento no tempo de resposta para operações de gravação nos
arquivos de dados. Isso pode afetar negativamente a experiência do usuário e a
eficiência das operações do banco de dados.

3.Risco de bloqueios prolongados: A contenção por gravação de datafile pode resultar

em bloqueios prolongados, em que as transações aguardam a liberação dos arquivos
de dados. Isso pode levar a um congestionamento do sistema e causar atrasos
significativos no processamento das transações.

4.Possibilidade de corrupção de dados: Se a contenção por gravação de datafile for

muito intensa, pode ocorrer um aumento no risco de corrupção de dados. Isso
acontece quando uma transação é forçada a interromper a gravação devido à
contenção, resultando em alterações parciais ou inconsistentes nos arquivos de
dados.

Para resolver a contenção por gravação de datafile, podem ser adotadas algumas
estratégias, como:

•Aumentar o tamanho do cache do buffer para lidar com a carga de trabalho e reduzir
a competição por acesso aos arquivos de dados.

•Avaliar a necessidade de realizar a desfragmentação dos arquivos de dados para

melhorar o desempenho de acesso e reduzir a contenção

Para resolver problemas de contenção de escrita de datafiles em SQL Server, Oracle e

PostgreSQL:

22
Para resolver problemas de contenção de datafile no SQL Server, Oracle e PostgreSQL,
é importante considerar as melhores práticas e técnicas específicas de cada banco de
dados. Abaixo estão algumas abordagens gerais para resolver problemas de
contenção de datafile em cada um deles:

SQL Server:

1.Ajuste do tamanho do arquivo de dados: Verifique o tamanho dos arquivos de

dados e dimensione-os adequadamente para lidar com a carga de trabalho. Um
tamanho inadequado pode levar a contenção devido à competição pelo acesso aos
arquivos.

2.Distribuição de arquivos de dados em diferentes discos: Considere distribuir os

arquivos de dados em diferentes discos físicos para distribuir a atividade de gravação.
Isso pode ajudar a reduzir a contenção, permitindo que várias transações gravem em
arquivos diferentes simultaneamente.

3.Monitoramento e ajuste do cache do buffer: Monitore o tamanho e a eficácia do

cache do buffer. Ajuste o parâmetro 'max server memory' para otimizar o uso da
memória pelo cache do buffer e reduzir a contenção relacionada à gravação de
datafile.

Oracle:

1.Distribuição de tablespaces em diferentes discos: Considere distribuir tablespaces e

arquivos de dados em diferentes discos físicos. Isso pode ajudar a distribuir a carga de
gravação e reduzir a contenção.

2.]Ajuste do tamanho do cache do buffer: Ajuste os parâmetros relacionados ao

cache do buffer, como DB_CACHE_SIZE e DB_KEEP_CACHE_SIZE, para otimizar o uso
da memória e reduzir a contenção relacionada à gravação de datafile.

3.Monitoramento e ajuste dos parâmetros de gravação: Ajuste os parâmetros

relacionados à gravação, como DB_WRITER_PROCESSES e DB_WRITER_INTERVAL,
para otimizar o processo de gravação e reduzir a contenção.

PostgreSQL:

1.Distribuição de tabelas em diferentes tablespaces: Considere distribuir tabelas em

22
diferentes tablespaces e arquivos de dados em diferentes discos físicos. Isso ajuda a
distribuir a atividade de gravação e reduzir a contenção.

2.Ajuste do tamanho do cache compartilhado: Ajuste o parâmetro 'shared_buffers'

para otimizar o uso da memória pelo cache compartilhado e reduzir a contenção
relacionada à gravação de datafile.

3.Monitoramento e ajuste dos parâmetros de gravação: Ajuste os parâmetros

relacionados à gravação, como 'checkpoint_timeout' e
'checkpoint_completion_target', para otimizar o processo de gravação e reduzir a
contenção.

Lembre-se de que cada banco de dados tem suas próprias características e opções de
configuração específicas. É importante consultar a documentação oficial do banco de
dados e realizar testes de desempenho para encontrar a melhor abordagem para
resolver problemas de contenção de datafile em seu ambiente específico.

22
 Contenção por Arquivamento
(Archiving Contention)

• A contenção por arquivamento (archiving contention) ocorre

quando várias transações competem pelo acesso e gravação de
arquivos de arquivamento (archive logs) em um banco de dados.
O arquivamento é o processo de mover os registros de log antigos
do log de transações para arquivos de arquivamento, garantindo a
recuperação e a preservação dos dados.
• Aplicável apenas a PostgreSQL e Oracle
• Possíveis causas
• Atividade intensa de gravação
• Configuração inadequada do arquivamento
• Problemas de I/O

Figura 1 desta página: Mecanismo de Archiving Oracle

Esta contenção se aplica a Oracle e PostgreSQL.

A contenção por arquivamento (archiving contention) ocorre quando várias

transações competem pelo acesso e gravação de arquivos de arquivamento (archive
logs) em um banco de dados. O arquivamento é o processo de mover os registros de
log antigos do log de transações para arquivos de arquivamento, garantindo a
recuperação e a preservação dos dados.

Causas da contenção por arquivamento:

1.Atividade intensa de gravação: Se houver um alto volume de operações de gravação

ocorrendo no banco de dados, como atualizações ou inserções em tabelas, muitas
transações podem estar gerando registros de log simultaneamente. Isso pode resultar
em um grande número de transações competindo pelo acesso e gravação dos
arquivos de arquivamento, levando à contenção.

23
2. Configuração inadequada do arquivamento: Uma configuração inadequada do
processo de arquivamento, como um intervalo de arquivamento muito curto ou uma
localização de arquivo de arquivamento lenta, pode levar a contenção. Isso ocorre
porque o sistema precisa lidar com um grande número de transações simultâneas
tentando arquivar os registros de log.

3.Problemas de E/S: Problemas relacionados à velocidade de leitura/gravação de

disco ou à disponibilidade de espaço em disco podem causar contenção por
arquivamento. Se o sistema de arquivos não conseguir acompanhar a taxa de geração
de registros de log, ocorrerão atrasos e contenção.

Impactos da contenção por arquivamento:

1.Diminuição do desempenho: A contenção por arquivamento pode causar atrasos

no processamento de transações e operações no banco de dados. As transações
precisam esperar pela liberação do acesso aos arquivos de arquivamento antes de
prosseguirem, resultando em uma diminuição geral do desempenho do sistema.

2.Aumento do espaço em disco: Se a contenção por arquivamento for severa e

ocorrerem atrasos no processo de arquivamento, o espaço em disco necessário para
armazenar os registros de log não arquivados pode aumentar consideravelmente.
Isso pode levar a problemas de espaço em disco e requerer um gerenciamento
cuidadoso.

3.Possibilidade de perda de dados: Se a contenção por arquivamento for muito

intensa e a gravação dos registros de log for comprometida, há um risco de perda de
dados em caso de falhas no sistema ou interrupções inesperadas.

4.Risco de congestionamento do sistema: A contenção por arquivamento pode levar

ao congestionamento do sistema, com várias transações aguardando a gravação dos
registros de log. Isso pode resultar em um aumento no tempo de resposta e uma
redução na capacidade de processamento das transações.

Para resolver a contenção por arquivamento, podem ser adotadas algumas

estratégias, como:

•Revisar e ajustar a configuração do processo de arquivamento, considerando o

intervalo de arquivamento, a localização dos arquivos de arquivamento e a
capacidade de E/S do sistema.

23
•Monitorar o desempenho do sistema e ajustar os recursos de E/S, como velocidade
de disco e configurações de armazenamento, para garantir que possam lidar
adequadamente com a taxa de geração de registros de log.

•Avaliar a possibilidade de usar soluções de armazenamento mais robustas, como

discos de alto desempenho ou arrays de armazenamento dedicados, para melhorar o
desempenho do arquivamento e reduzir a contenção.

Para resolver problemas de arquivamento em SQL Server, Oracle e PostgreSQL:

SQL Server:

No SQL Server, a prática comum é realizar backups regulares dos bancos de dados,
incluindo os logs de transações, para garantir a recuperação e a preservação dos
dados. Os backups podem ser configurados para reter os logs antigos e, assim,
fornecer um histórico de alterações. No entanto, o SQL Server não tem um processo
de arquivamento específico como os outros bancos de dados mencionados.

Para resolver problemas relacionados ao crescimento excessivo do log de transações

no SQL Server, algumas abordagens incluem:

1.Ajustar o modelo de recuperação: O SQL Server oferece três modelos de

recuperação - simples, completa e bulk-logged. Verifique se o modelo de recuperação
está configurado adequadamente para atender às necessidades do seu banco de
dados.

2.Realizar backups frequentes: Realize backups regulares do banco de dados e dos

logs de transações para manter o tamanho do log sob controle. Isso ajudará a liberar
espaço no log e reduzir a contenção relacionada à gravação.

3.Redimensionar o log de transações: Caso o log de transações esteja crescendo

desproporcionalmente, você pode redimensioná-lo manualmente, ajustando seu
tamanho inicial e a taxa de crescimento automática.

4.Monitorar e otimizar consultas: Transações demoradas ou consultas ineficientes

podem contribuir para o crescimento excessivo do log de transações. Monitore o
desempenho do sistema e otimize consultas problemáticas para minimizar a
quantidade de dados gravados no log.

Oracle:

23
1.Avaliação e ajuste da configuração do processo de arquivamento: Avalie a
configuração do processo de arquivamento no Oracle, incluindo o intervalo de
arquivamento, os modos de arquivamento e os parâmetros relacionados. Ajuste
essas configurações para melhorar o desempenho e reduzir a contenção.

2.Monitoramento e ajuste dos recursos de E/S: Monitore e ajuste os recursos de E/S,

como velocidade de disco e configurações de armazenamento, para garantir que
possam lidar adequadamente com a taxa de geração de registros de log. Considere o
uso de discos de alto desempenho ou arranjos de armazenamento dedicados para
melhorar o desempenho do arquivamento.

PostgreSQL:

1.Revisão e ajuste das configurações de arquivamento: Avalie as configurações

relacionadas ao processo de arquivamento no PostgreSQL, como o intervalo de
arquivamento e as opções de arquivamento. Ajuste essas configurações para otimizar
o processo de arquivamento e reduzir a contenção.

2.Monitoramento e ajuste dos recursos de E/S: Monitore e ajuste os recursos de E/S,

como velocidade de disco e configurações de armazenamento, para garantir que
possam lidar adequadamente com a taxa de geração de registros de log. Considere o
uso de discos de alto desempenho ou arranjos de armazenamento dedicados para
melhorar o desempenho do arquivamento.

23
 Contenção por Filegroup /
Tablespace
(Filegroup/Tablespace
Contention)

• A contenção de tablespace/filegroup ocorre quando

várias transações estão competindo pelo acesso e uso
dos espaços de armazenamento no banco de dados. Um
tablespace (no Oracle) ou filegroup (no SQL Server) é
uma estrutura lógica que armazena os objetos de banco
de dados, como tabelas, índices e outros dados.
• Possíveis causas
• Alto volume de atividade de Gravação
• Desbalanceamento de objetos
• Fragmentação de espaço

A contenção de tablespace/filegroup ocorre quando várias transações estão

competindo pelo acesso e uso dos espaços de armazenamento no banco de dados.
Um tablespace (no Oracle) ou filegroup (no SQL Server) é uma estrutura lógica que
armazena os objetos de banco de dados, como tabelas, índices e outros dados.

Causas da contenção de tablespace/filegroup:

1.Alto volume de atividade de gravação: Se houver um grande número de transações

realizando operações de gravação simultaneamente no mesmo tablespace/filegroup,
pode ocorrer uma competição pelo acesso e gravação dos dados, resultando em
contenção.

2.Desbalanceamento de objetos: Se os objetos do banco de dados, como tabelas ou

índices, estiverem distribuídos de forma desigual pelos tablespaces/filegroups, pode
ocorrer contenção. Por exemplo, se várias transações estiverem acessando
intensivamente um único tablespace/filegroup, enquanto outros estão subutilizados,
isso pode levar a contenção no tablespace/filegroup mais movimentado.

3.Fragmentação de espaço: A fragmentação de espaço ocorre quando o espaço

24
alocado para os objetos no tablespace/filegroup está fragmentado, com espaços
vazios entre os objetos. Isso pode levar a uma utilização ineficiente do espaço e
resultar em contenção.

Impactos da contenção de tablespace/filegroup:

1.Diminuição do desempenho: A contenção de tablespace/filegroup pode causar

atrasos no processamento de transações e operações no banco de dados. As
transações podem precisar esperar pela liberação do acesso ao tablespace/filegroup
antes de prosseguirem, resultando em uma diminuição geral do desempenho do
sistema.

2.Aumento do tempo de resposta: Devido à contenção, as transações podem

experimentar um aumento no tempo de resposta para operações de leitura e
gravação nos objetos armazenados no tablespace/filegroup. Isso pode afetar
negativamente a experiência do usuário e a eficiência das operações do banco de
dados.

3.Congestionamento do sistema: A contenção de tablespace/filegroup pode levar ao

congestionamento do sistema, com várias transações aguardando o acesso e uso do
tablespace/filegroup. Isso pode resultar em um aumento no tempo de resposta e
uma redução na capacidade de processamento das transações.

4.Utilização ineficiente do espaço: Se a contenção ocorrer em um

tablespace/filegroup específico, pode haver uma utilização ineficiente do espaço de
armazenamento. Alguns objetos podem estar ocupando mais espaço do que o
necessário, enquanto outros não estão sendo plenamente utilizados.

Para resolvermos problemas de contenção por filegroup/ tablespace em SQL Server,

Oracle e PostgreSQL:

SQL Server:

1.Distribuição de objetos em diferentes filegroups: Considere distribuir os objetos do

banco de dados em diferentes filegroups para distribuir a carga de acesso e gravação.
Isso pode ajudar a reduzir a contenção, permitindo que várias transações acessem e
gravem em filegroups diferentes simultaneamente.

2.Monitoramento e ajuste do tamanho do filegroup: Monitore o tamanho do

filegroup e ajuste-o conforme necessário. Se um filegroup estiver ficando cheio, pode
ser necessário aumentar seu tamanho ou redistribuir os objetos para outros
filegroups.

24
3.Reorganização e compactação de objetos: Realize a reorganização e a compactação
de objetos nos filegroups para reduzir a fragmentação de espaço e melhorar a
utilização do espaço de armazenamento. Isso pode ajudar a evitar a contenção
causada pela alocação ineficiente de espaço.

Oracle:

1.Distribuição de tabelas em diferentes tablespaces: Considere distribuir as tabelas

em diferentes tablespaces para distribuir a carga de acesso e gravação. Isso pode
ajudar a reduzir a contenção, permitindo que várias transações acessem e gravem em
tablespaces diferentes simultaneamente.

2.Ajuste do tamanho do tablespace: Monitore o tamanho do tablespace e ajuste-o

conforme necessário. Se um tablespace estiver ficando cheio, pode ser necessário
aumentar seu tamanho ou redistribuir as tabelas para outros tablespaces.

3.Reorganização e compactação de tabelas: Realize a reorganização e a compactação

de tabelas nos tablespaces para reduzir a fragmentação de espaço e melhorar a
utilização do espaço de armazenamento. Isso pode ajudar a evitar a contenção
causada pela alocação ineficiente de espaço.

PostgreSQL:

1.Distribuição de tabelas em diferentes tablespaces: Considere distribuir as tabelas

em diferentes tablespaces para distribuir a carga de acesso e gravação. Isso pode
ajudar a reduzir a contenção, permitindo que várias transações acessem e gravem em
tablespaces diferentes simultaneamente.

2.Monitoramento e ajuste do tamanho do tablespace: Monitore o tamanho do

tablespace e ajuste-o conforme necessário. Se um tablespace estiver ficando cheio,
pode ser necessário aumentar seu tamanho ou redistribuir as tabelas para outros
tablespaces.

3.Reorganização e compactação de tabelas: Realize a reorganização e a compactação

de tabelas nos tablespaces para reduzir a fragmentação de espaço e melhorar a
utilização do espaço de armazenamento. Isso pode ajudar a evitar a contenção
causada pela alocação ineficiente de espaço.

24
 Contenção de memória
(Memory Contention)

• A contenção de memória (contention memory) em um

banco de dados ocorre quando várias transações ou
processos competem pelo acesso e uso dos recursos
de memória do sistema. Isso pode resultar em
atrasos, bloqueios ou até mesmo falhas na execução
de consultas, operações de gravação ou outras
atividades relacionadas ao banco de dados.
• Possíveis causas
• Configuração inadequada de memória
• Consultas ou operações de grande volume
• Má gestão do cache
• Falta de índices

A contenção de memória (contention memory) em um banco de dados ocorre

quando várias transações ou processos competem pelo acesso e uso dos recursos de
memória do sistema. Isso pode resultar em atrasos, bloqueios ou até mesmo falhas
na execução de consultas, operações de gravação ou outras atividades relacionadas
ao banco de dados.

Causas da contenção de memória:

1.Configuração inadequada da memória: Se a alocação de memória para o banco de

dados não estiver configurada corretamente, pode ocorrer uma contenção de
memória. Isso pode acontecer quando a quantidade de memória alocada é
insuficiente para a carga de trabalho do banco de dados, resultando em uma
competição intensa pelos recursos disponíveis.

2.Consultas ou operações de grande escala: Consultas complexas, operações de ETL

(Extração, Transformação e Carga) ou processamentos de dados intensivos podem
exigir uma quantidade significativa de memória. Se várias dessas atividades estiverem
ocorrendo simultaneamente, pode ocorrer contenção de memória, pois todas elas
competem pelo mesmo conjunto limitado de recursos de memória.

25
3.Má gestão de cache: O cache é uma área de memória utilizada para armazenar
dados frequentemente acessados, como blocos de dados ou planos de execução de
consultas. Se o tamanho do cache não for adequado para a carga de trabalho do
banco de dados, pode ocorrer uma contenção de memória, pois as transações
competem pelo acesso ao cache.

4.A falta de índices em bancos de dados Oracle, SQL Server e PostgreSQL pode levar a
um mal gerenciamento de memória devido aos seguintes motivos:

- Varreduras de tabela completas: Sem índices adequados, o banco de dados precisa

executar varreduras completas nas tabelas para recuperar os dados desejados. Essas
varreduras consomem mais memória, pois carregam todos os dados da tabela na
memória, mesmo aqueles que não são necessários para a consulta. Isso pode resultar
em um consumo excessivo de memória, levando à contenção de memória e a uma
utilização ineficiente dos recursos.

- Uso excessivo de memória para classificação e junção de dados: Quando não há

índices apropriados para suportar operações de classificação e junção de dados, o
banco de dados precisa alocar grandes quantidades de memória para realizar essas
operações em tempo real. Isso pode levar a um aumento no uso de memória,
reduzindo a quantidade disponível para outras operações e resultando em contenção
de memória.

- Carga desnecessária no cache do buffer: O cache do buffer é uma área de memória

usada para armazenar blocos de dados frequentemente acessados. Sem índices
adequados, as consultas precisam ler e armazenar blocos de dados completos no
cache do buffer, mesmo que apenas uma pequena porção dos dados seja necessária.
Isso pode levar a uma carga desnecessária no cache do buffer, reduzindo a eficiência
do uso da memória.

-Planos de execução ineficientes: A falta de índices adequados pode resultar em

planos de execução ineficientes. Os planos de execução determinam a forma como as
consultas são executadas e podem afetar diretamente o uso de memória. Sem
índices apropriados, o otimizador de consulta pode escolher planos de execução que
requerem mais memória para operações de classificação, junção ou busca de dados.
Isso pode levar a uma alocação excessiva de memória e, consequentemente, à
contenção de memória.

Impactos da contenção de memória:

25
1.Diminuição do desempenho do banco de dados: A contenção de memória pode
levar a atrasos na execução de consultas e operações, resultando em um
desempenho geral mais lento do banco de dados. As transações podem precisar
esperar pela disponibilidade de recursos de memória, causando atrasos no
processamento.

2.Aumento do tempo de resposta: Devido à contenção, as consultas e operações

podem experimentar um aumento no tempo de resposta. Isso pode afetar
negativamente a experiência do usuário e a eficiência das operações do banco de
dados.

3.Congestionamento do sistema: Se a contenção de memória for intensa, pode

ocorrer um congestionamento do sistema, com várias transações ou processos
competindo pelos recursos de memória. Isso pode resultar em bloqueios
prolongados ou falhas de execução, levando a um impacto significativo no
desempenho geral do banco de dados.

4.Risco de esgotamento de memória: Se a contenção de memória não for gerenciada

adequadamente, há um risco de esgotamento dos recursos de memória disponíveis.
Isso pode levar a falhas de execução, interrupções do sistema ou até mesmo a
paralisação completa do banco de dados.

Para resolver problemas de contenção de memória, podem ser adotadas algumas

estratégias, como:
•Ajustar a configuração de alocação de memória do banco de dados, garantindo que
haja memória suficiente para suportar a carga de trabalho.

•Otimizar consultas e operações de banco de dados para reduzir a demanda por

memória.

•Gerenciar adequadamente o tamanho e a configuração do cache, ajustando os

parâmetros relacionados ao cache para otimizar o uso da memória disponível.

•Monitorar e ajustar o dimensionamento vertical (escalabilidade) do servidor de

banco de dados, adicionando mais recursos de memória conforme necessário.

Para justar problemas de contenção de memória para SQL Server , Oracle e

PostgreSQL:

SQL Server:

25
1. Ajuste da configuração de alocação de memória: No SQL Server, é possível
configurar os limites de alocação de memória para diferentes componentes, como o
cache do buffer, cache de procedimentos e cache de consultas. Ajuste essas
configurações de acordo com a carga de trabalho e os recursos disponíveis para evitar
a contenção de memória.

2.Monitoramento e otimização de consultas: Consultas mal otimizadas podem exigir

uma quantidade excessiva de memória. Identifique e otimize consultas
problemáticas, revisando índices, estatísticas e planos de execução. Isso ajudará a
reduzir a demanda por memória e melhorar o desempenho geral do banco de dados.

3.Consideração do dimensionamento vertical: Avalie se o servidor de banco de dados

possui recursos de memória adequados para suportar a carga de trabalho. Se
necessário, aumente o dimensionamento vertical (escalabilidade) do servidor,
adicionando mais memória para reduzir a contenção.

Oracle:

1.Ajuste dos parâmetros de memória: No Oracle, existem vários parâmetros

relacionados à alocação de memória, como SGA_TARGET, PGA_AGGREGATE_TARGET
e SHARED_POOL_SIZE. Ajuste esses parâmetros com base nas necessidades da carga
de trabalho e nos recursos disponíveis para evitar a contenção de memória.

2.Monitoramento e ajuste do cache compartilhado: O Oracle utiliza o cache

compartilhado para armazenar planos de execução, áreas de trabalho e outros
objetos em memória. Monitore o cache compartilhado e ajuste os parâmetros
relacionados, como SHARED_POOL_SIZE e JAVA_POOL_SIZE, para otimizar o uso da
memória e evitar a contenção.

3.Otimização de consultas e uso eficiente de recursos de memória: Otimize as

consultas e garanta que os objetos do banco de dados estejam corretamente
indexados. Além disso, utilize recursos como particionamento de tabelas, uso de
índices adequados e agrupamento de dados para reduzir a demanda por memória.

PostgreSQL:

1.Ajuste dos parâmetros de memória: No PostgreSQL, existem parâmetros como

shared_buffers, work_mem e maintenance_work_mem que controlam a alocação de
memória. Ajuste esses parâmetros de acordo com a carga de trabalho e os recursos
disponíveis para evitar a contenção de memória.

2.Otimização de consultas e uso eficiente de recursos de memória: Realize

25
otimizações de consultas, crie índices apropriados e revise os planos de execução
para reduzir a demanda por memória. Além disso, utilize técnicas como
particionamento de tabelas e agrupamento de dados para melhorar a eficiência da
memória.

3.Monitoramento e ajuste do dimensionamento vertical: Monitore o uso de memória

do servidor PostgreSQL e ajuste o dimensionamento vertical, adicionando mais
memória conforme necessário para evitar a contenção.

25
 Contenção de processos de
Segundo plano (Process
background Contention)

Processos background Oracle

• A contenção de processos background em um banco
de dados ocorre quando vários processos em
segundo plano competem pelo acesso e uso dos
recursos do sistema. Os processos background são
responsáveis por executar tarefas essenciais para o
funcionamento do banco de dados, como
recuperação, limpeza, sincronização e manutenção
de índices.
• Possíveis causas
• Sobrecarga do Sistema
• Recursos insuficientes
• Configuração inadequada
• Falta de índices

Processos background PostgreSQL

A contenção de processos background em um banco de dados ocorre quando vários

processos em segundo plano competem pelo acesso e uso dos recursos do sistema.
Os processos background são responsáveis por executar tarefas essenciais para o
funcionamento do banco de dados, como recuperação, limpeza, sincronização e
manutenção de índices.

Causas da contenção de processos background:

1.Sobrecarga do sistema: Se o banco de dados estiver enfrentando uma carga

excessiva de trabalho ou estiver processando um grande número de transações
simultâneas, os processos background podem ficar sobrecarregados. Isso ocorre
quando há mais tarefas a serem executadas do que a capacidade do sistema pode
suportar, resultando em contenção.

2.Recursos insuficientes: A falta de recursos, como memória, CPU ou disco, pode

levar à contenção de processos background. Se os processos não tiverem acesso
suficiente a esses recursos, eles podem competir por sua disponibilidade, resultando
em atrasos e contenção.

26
3. Configuração inadequada: Uma configuração inadequada dos parâmetros
relacionados aos processos background pode levar à contenção. Por exemplo, se o
número de threads ou conexões para processos background não for suficiente para
lidar com a carga de trabalho, ocorrerá contenção.

Impactos da contenção de processos background:

1.Atrasos na recuperação e manutenção do banco de dados: Os processos

background são responsáveis por tarefas críticas, como recuperação de falhas e
manutenção de índices. Se houver contenção, essas tarefas podem ser atrasadas,
resultando em um tempo de recuperação mais longo em caso de falha e em um
desempenho mais baixo de consultas e operações envolvendo índices.

2.Aumento do tempo de resposta: Devido à contenção de processos background, as

transações e operações do banco de dados podem experimentar um aumento no
tempo de resposta. Isso ocorre porque as tarefas em segundo plano precisam esperar
pela disponibilidade dos recursos necessários para sua execução, resultando em
atrasos gerais.

3.Congestionamento do sistema: A contenção de processos background pode levar

ao congestionamento do sistema, com vários processos competindo pelos mesmos
recursos. Isso pode resultar em um aumento no tempo de resposta e em uma
redução geral na capacidade de processamento do banco de dados.

4.Instabilidade do sistema: Se a contenção de processos background for intensa,

pode levar à instabilidade do sistema. Os processos podem falhar ou ficar em um
estado de espera prolongado, causando interrupções no funcionamento normal do
banco de dados.

Para resolver problemas de contenção de processos background, algumas estratégias

incluem:

•Avaliar a capacidade de recursos do sistema, como memória, CPU e disco, e garantir

que sejam adequados para a carga de trabalho do banco de dados.

•Ajustar os parâmetros relacionados aos processos background, como o número de

threads, conexões ou intervalos de execução, para otimizar sua configuração.

•Monitorar o desempenho do sistema e identificar gargalos de recursos ou tarefas em

segundo plano com alto impacto no desempenho.

26
•Considerar a escalabilidade vertical (dimensionamento) do sistema, adicionando
mais recursos para atender às demandas de processamento dos processos
background.

26
 Contenção de processo
LGWR Oracle

• Processo LGWR (Log Writer) pode sofrer

contenção por questões ligadas ao I/O dos redo
logs, neste caso o I/O seria o agente causador
real da contenção. A contenção pode acontecer
também por causa da alta demanda pelo
processo LGWR em função de grande
quantidade de commits recebidos em um
determinado momento no tempo.
• Possíveis causas:
• Alta taxa de gravação de Logs
• Limitações de escrita nos redo logs
• Parâmetro de checkpoint inaqdequado
• Tamanho de arquivo de Redo Log inadequado

A contenção de LGWR (Log Writer) ocorre quando várias transações competem pelo
acesso e uso do processo LGWR, responsável por gravar os registros de log em disco.
Isso pode levar a atrasos na gravação do log e afetar o desempenho geral do banco
de dados.

Possíveis causas da contenção de LGWR:

1.Alta taxa de gravação de log: Se o banco de dados estiver gerando um alto volume
de registros de log devido a transações intensivas, isso pode sobrecarregar o LGWR e
causar contenção.

2.Limitações de recursos de E/S: Se o sistema de armazenamento estiver lento ou

com restrições de I/O, isso pode afetar a capacidade do LGWR de gravar os registros
de log de forma eficiente, resultando em contenção.

3.Configuração inadequada do processo LGWR: Os parâmetros de configuração

relacionados ao LGWR podem estar configurados de maneira inadequada, afetando o
desempenho e a contenção. Por exemplo, o número de threads de gravação de log
(log writer threads) pode estar configurado de forma inadequada para a carga de

27
trabalho do banco de dados.

Parâmetros de configuração que podem ser ajustados para melhorar a contenção de

LGWR:

1.LOG_BUFFER: Este parâmetro define o tamanho do buffer de log, que é usado para
armazenar temporariamente os registros de log antes que sejam gravados em disco.
Aumentar o valor desse parâmetro pode ajudar a reduzir a contenção, fornecendo
mais espaço para armazenar os registros de log.

2.LOG_CHECKPOINT_INTERVAL: Esse parâmetro controla o intervalo entre os pontos

de verificação (checkpoints) no banco de dados. Um checkpoint é um evento em que
o LGWR grava os registros de log pendentes em disco. Ajustar adequadamente esse
intervalo pode ajudar a distribuir a carga de gravação do LGWR e reduzir a contenção.
Influência da contenção de I/O sobre a contenção de LGWR: A contenção de I/O,
como lentidão ou restrições no sistema de armazenamento, pode ter um impacto
direto na contenção de LGWR. Se o LGWR não conseguir gravar os registros de log
rapidamente o suficiente devido a problemas de I/O, isso pode causar atrasos e
aumentar a contenção. Portanto, é importante monitorar e otimizar o desempenho
do sistema de armazenamento para evitar ou minimizar a contenção de I/O, o que
consequentemente melhorará a contenção de LGWR.

Passo a passo para solucionar problemas de contenção por LGWR:

1.Identifique a causa da contenção: Monitore e analise os indicadores de

desempenho do banco de dados para identificar possíveis causas da contenção de
LGWR, como alta taxa de gravação de log, restrições de I/O ou configuração
inadequada do processo LGWR.

2.Verifique a configuração do processo LGWR: Avalie os parâmetros de configuração

relacionados ao LGWR, como LOG_BUFFER e LOG_CHECKPOINT_INTERVAL, e ajuste-
os conforme necessário com base na carga de trabalho e nas necessidades do
sistema.

3.Avalie a configuração do armazenamento: Verifique se o sistema de

armazenamento está funcionando adequadamente e não apresenta restrições de I/O.
Realize ajustes ou otimizações necessárias para melhorar o desempenho do
armazenamento, como otimização do sistema de arquivos ou ajustes no subsistema
de armazenamento.

27
4. Monitore o desempenho e os indicadores do LGWR: Utilize ferramentas de
monitoramento para acompanhar o desempenho do LGWR, como a taxa de gravação
de log, o tempo de resposta e a atividade de I/O. Identifique quaisquer gargalos ou
problemas que possam estar afetando o desempenho do LGWR.

5.Ajuste os parâmetros de configuração e recursos de acordo: Com base nas análises

e monitoramento, faça ajustes nos parâmetros de configuração relevantes, como
LOG_BUFFER e LOG_CHECKPOINT_INTERVAL, e aloque recursos adequados, como
threads de gravação de log, para otimizar o desempenho do LGWR.

6.Teste e avalie os resultados: Realize testes para avaliar o impacto das mudanças
realizadas. Monitore novamente o desempenho e verifique se a contenção de LGWR
foi reduzida. Ajuste as configurações ou procedimentos, se necessário, até obter um
desempenho satisfatório.

27
 Contenção de processo
DBWR Oracle

• Processo DBWR (Database Writer) pode sofrer

contenção por questões ligadas ao I/O dos
datafiles, neste caso o I/O seria o agente
causador real da contenção. A contenção pode
acontecer também por causa da alta demanda
pelo processo DBWR em função de grande
quantidade de checkpoints realizados.
• Possíveis causas:
• Alta taxa de gravação de Logs
• Limitações de escrita nos redo logs
• Parametro de checkpoint inaqdequado
• Tamanho de arquivo de Redo Log inadequado

A contenção de DBWR (Database Writer) ocorre quando várias transações competem

pelo acesso e uso do processo DBWR, responsável por gravar blocos de dados
modificados em disco. Isso pode levar a atrasos na gravação dos dados e impactar o
desempenho geral do banco de dados.

Possíveis causas da contenção de DBWR:

1.Alto volume de gravações: Se o banco de dados estiver realizando muitas

operações de gravação, como inserções, atualizações ou exclusões em uma taxa
elevada, isso pode sobrecarregar o DBWR e causar contenção.

2.Buffer Cache insuficiente: O Buffer Cache é uma área de memória usada para
armazenar blocos de dados em memória antes de serem gravados em disco. Se o
tamanho do Buffer Cache não for suficiente para a carga de trabalho do banco de
dados, isso pode levar à contenção de DBWR.

3.Limitações de recursos de I/O: Restrições no sistema de armazenamento, como

lentidão do disco ou I/O insuficiente, podem afetar a capacidade do DBWR em gravar
os blocos de dados de forma eficiente, resultando em contenção.

28
Parâmetros de configuração que podem ser ajustados para melhorar a contenção de
DBWR:

1.DB_WRITER_PROCESSES: Este parâmetro define o número de processos DBWR que

podem ser configurados no banco de dados. Aumentar esse valor pode ajudar a
distribuir a carga de gravação entre múltiplos processos DBWR e melhorar o
desempenho.

2.DB_BLOCK_CHECKSUM: Esse parâmetro ativa a verificação de soma de verificação

nos blocos de dados gravados em disco. Desativar essa verificação pode reduzir a
carga do DBWR e melhorar o desempenho, mas com um risco potencial de corrupção
de dados em caso de falhas de I/O.
Influência da contenção de I/O sobre a contenção de DBWR:

A contenção de I/O pode ter um impacto direto na contenção de DBWR. Se o sistema

de armazenamento estiver enfrentando restrições de I/O, como baixa taxa de
transferência de dados ou alto tempo de resposta do disco, isso pode afetar a
capacidade do DBWR em gravar os blocos de dados em tempo hábil.
Consequentemente, a contenção de I/O pode causar atrasos na gravação de dados
pelo DBWR e levar à contenção geral.

Passo a passo para solucionar problemas de contenção por DBWR:

1.Identifique a causa da contenção: Monitore os indicadores de desempenho do

banco de dados, como a taxa de gravação, o tempo de resposta do DBWR e a
atividade de I/O, para identificar possíveis causas da contenção de DBWR, como alto
volume de gravações, Buffer Cache insuficiente ou restrições de I/O.

2.Verifique a configuração do DBWR: Avalie os parâmetros de configuração

relacionados ao DBWR, como DB_WRITER_PROCESSES, e ajuste-os conforme
necessário com base na carga de trabalho e nas necessidades do sistema.

3.Avalie a configuração do armazenamento: Verifique se o sistema de

armazenamento está funcionando adequadamente e não apresenta restrições de I/O.
Realize ajustes ou otimizações necessárias para melhorar o desempenho do
armazenamento, como otimização do sistema de arquivos, configuração adequada
do cache do disco ou ajustes no subsistema de armazenamento.

4.Monitore o desempenho e os indicadores do DBWR: Utilize ferramentas de

28
monitoramento para acompanhar o desempenho do DBWR, como a taxa de
gravação, o tempo de resposta e a atividade de I/O. Identifique quaisquer gargalos ou
problemas que possam estar afetando o desempenho do DBWR.

5.Ajuste os parâmetros de configuração e recursos de acordo: Com base nas análises

e monitoramento, faça ajustes nos parâmetros de configuração relevantes, como
DB_WRITER_PROCESSES, e aloque recursos adequados para otimizar o desempenho
do DBWR.

6.Teste e avalie os resultados: Realize testes para avaliar o impacto das mudanças
realizadas. Monitore novamente o desempenho e verifique se a contenção de DBWR
foi reduzida. Ajuste as configurações ou procedimentos, se necessário, até obter um
desempenho satisfatório.

Lembrando que cada banco de dados tem suas próprias características e parâmetros
de configuração específicos. Consulte a documentação oficial do seu banco de dados
e utilize as
ferramentas de monitoramento e ajuste adequadas para solucionar problemas de
contenção por DBWR de maneira eficaz.

28
 Contenção de processo
CKPT Oracle

• Processo CKPT (Checkpoint process) pode

sofrer contenção por questões ligadas ao I/O
dos control files, neste caso o I/O seria o
agente causador real da contenção. A
contenção pode acontecer também por causa
da alta demanda de checkpoints para
sincronismo da memória com o disco
• Possíveis causas:
• Atividade intensa de Gravação
• Tamanho inadequado log buffer
• Limitações de I/O
• Excesso de demanda para eventos de checkpoint

A contenção de CKPT (Checkpoint) ocorre quando várias transações competem pelo

acesso e uso do processo CKPT, responsável por gravar os dados modificados do
buffer cache em disco durante um checkpoint. Isso pode resultar em atrasos no
processo de checkpoint e impactar o desempenho geral do banco de dados.

Possíveis causas da contenção de CKPT:

1.Atividade intensa de gravação: Se o banco de dados estiver envolvido em uma alta

atividade de gravação, com muitas transações realizando modificações frequentes
nos dados, isso pode sobrecarregar o processo CKPT e causar contenção.

2.Tamanho inadequado do log buffer: O log buffer é uma área de memória usada
para armazenar os registros de log antes de serem gravados em disco durante um
checkpoint. Se o tamanho do log buffer for muito pequeno para a carga de trabalho
do banco de dados, isso pode levar à contenção de CKPT.

3.Restrições de I/O: Limitações no sistema de armazenamento, como baixa taxa de

transferência de dados ou alto tempo de resposta do disco, podem afetar a
capacidade do CKPT em gravar os dados em disco de forma eficiente, resultando em

29
contenção.

Parâmetros de configuração que podem ser ajustados para melhorar a contenção de

CKPT:

1.LOG_CHECKPOINT_TIMEOUT: Este parâmetro define o intervalo de tempo em

segundos entre os checkpoints automáticos. Aumentar esse valor pode ajudar a
reduzir a frequência de ocorrência de checkpoints, aliviando a carga do processo
CKPT.

2.LOG_CHECKPOINTS_TO_ALERT: Esse parâmetro determina o número de

checkpoints que disparam um alerta no arquivo de alerta do banco de dados.
Aumentar esse valor pode ajudar a limitar os alertas relacionados a checkpoints
frequentes e desnecessários.

Influência da contenção de I/O sobre a contenção de CKPT:

A contenção de I/O pode ter um impacto direto na contenção de CKPT. Se o sistema

de armazenamento estiver enfrentando restrições de I/O, como baixa taxa de
transferência de dados ou alto tempo de resposta do disco, isso pode afetar a
capacidade do CKPT em gravar os dados em disco durante um checkpoint.
Consequentemente, a contenção de I/O pode causar atrasos no processo de
checkpoint e levar à contenção geral de CKPT.

Passo a passo para solucionar problemas de contenção por CKPT:

1.Identifique a causa da contenção: Monitore os indicadores de desempenho do

banco de dados, como a atividade de gravação, o tempo de resposta do CKPT e a
atividade de I/O, para identificar possíveis causas da contenção de CKPT, como alta
atividade de gravação, tamanho inadequado do log buffer ou restrições de I/O.

2.Verifique a configuração do CKPT: Avalie os parâmetros de configuração

relacionados ao CKPT, como LOG_CHECKPOINT_TIMEOUT, e ajuste-os conforme
necessário com base na carga de trabalho e nas necessidades do sistema.

3.Avalie a configuração do armazenamento: Verifique se o sistema de

armazenamento está funcionando adequadamente e não apresenta restrições de I/O.
Realize ajustes ou otimizações necessárias para melhorar o desempenho do
armazenamento, como otimização do sistema de arquivos, configuração adequada
do cache do disco ou ajustes no subsistema de armazenamento.

29
4.Monitore o desempenho e os indicadores do CKPT: Utilize ferramentas de
monitoramento para acompanhar o desempenho do CKPT, como a atividade de
gravação, o tempo de resposta e a atividade de I/O. Identifique quaisquer gargalos ou
problemas que possam estar afetando o desempenho do CKPT.

5.Ajuste os parâmetros de configuração e recursos de acordo: Com base nas análises

e monitoramento, faça ajustes nos parâmetros de configuração relevantes, como
LOG_CHECKPOINT_TIMEOUT, e aloque recursos adequados para otimizar o
desempenho do CKPT.

6.Teste e avalie os resultados: Realize testes para avaliar o impacto das mudanças
realizadas. Monitore novamente o desempenho e verifique se a contenção de CKPT
foi reduzida. Ajuste as configurações ou procedimentos, se necessário, até obter um
desempenho satisfatório.

Lembrando que cada banco de dados tem suas próprias características e parâmetros
de configuração específicos. Consulte a documentação oficial do seu banco de dados
e utilize as ferramentas de monitoramento e ajuste adequadas para solucionar
problemas de contenção por CKPT de maneira eficaz.

29
 Contenção de processos
Worker SQL Server

• A contenção de processos Worker no SQL

Server ocorre quando vários processos
competem pelo acesso e uso dos
recursos do sistema, especificamente os
processos worker responsáveis por
executar tarefas em segundo plano, como
consultas paralelas e operações de ETL
(Extração, Transformação e Carga).
• Possíveis causas:
• Sobrecarga do sistema
• Recursos insuficientes
• Configuração inadequada

A contenção de processos Worker no SQL Server ocorre quando vários processos

competem pelo acesso e uso dos recursos do sistema, especificamente os processos
worker responsáveis por executar tarefas em segundo plano, como consultas
paralelas e operações de ETL (Extração, Transformação e Carga).

Possíveis causas da contenção de processos Worker:

1.Sobrecarga do sistema: Se o SQL Server estiver enfrentando uma carga de trabalho

intensa ou um grande número de consultas paralelas, os processos worker podem
ficar sobrecarregados, resultando em contenção.

2.Recursos insuficientes: A falta de recursos, como memória, CPU ou disco, pode

levar à contenção de processos Worker. Se os processos não tiverem acesso
suficiente a esses recursos, eles podem competir por sua disponibilidade, resultando
em atrasos e contenção.

3.Configuração inadequada: Uma configuração inadequada dos parâmetros

relacionados aos processos worker, como o número máximo de threads de trabalho,
pode levar à contenção. Por exemplo, se o número de threads de trabalho for

30
insuficiente para lidar com a carga de trabalho, ocorrerá contenção.

Parâmetros de configuração que podem ser ajustados para melhorar a contenção de

processos Worker:

1.Max Worker Threads: Esse parâmetro define o número máximo de threads de

trabalho que podem ser executados simultaneamente. Aumentar esse valor pode
permitir que mais processos worker sejam executados em paralelo, reduzindo a
contenção.

2.Max Degree of Parallelism: Esse parâmetro controla o número máximo de

processadores que podem ser usados para executar consultas paralelas. Ajustar
adequadamente esse valor pode ajudar a limitar a contenção de processos worker
durante consultas paralelas intensivas.

Influência da contenção de I/O sobre a contenção de processos Worker:

A contenção de I/O pode ter um impacto direto na contenção de processos Worker.

Se o sistema de armazenamento estiver enfrentando restrições de I/O, como baixa
taxa de transferência de dados ou alto tempo de resposta do disco, isso pode afetar a
capacidade dos processos worker em executar suas tarefas em segundo plano.
Consequentemente, a contenção de I/O pode causar atrasos e aumentar a contenção
de processos Worker.

Passo a passo para solucionar problemas de contenção de processos Worker:

1.Identifique a causa da contenção: Monitore os indicadores de desempenho do SQL

Server, como o uso de CPU, a utilização de memória e a atividade de I/O, para
identificar possíveis causas da contenção de processos Worker, como sobrecarga do
sistema, recursos insuficientes ou configuração inadequada.

2.Verifique a configuração dos parâmetros relacionados aos processos Worker: Avalie

os parâmetros de configuração, como Max Worker Threads e Max Degree of
Parallelism, e ajuste-os conforme necessário com base na carga de trabalho e nas
necessidades do sistema.

3.Avalie a configuração e o desempenho do armazenamento: Verifique se o sistema

de armazenamento está funcionando adequadamente e não apresenta restrições de
I/O. Realize ajustes ou otimizações necessárias para melhorar o desempenho do

30
armazenamento.

30
 Contenção de processos
Background PostgreSQL

• Podemos listar os principais processos

background PostgreSQL que podem
sofrer algum tipo de contenção, listados
abaixo:

• Autovacuum
• Background Writer (BGW)
• Checkpointer
• Walwriter

No PostgreSQL, existem vários processos background que desempenham funções

críticas para o funcionamento do banco de dados. Embora a contenção seja menos
comum no PostgreSQL em comparação com outros bancos de dados, ainda é possível
ocorrer em certas circunstâncias. Abaixo estão alguns processos background do
PostgreSQL que podem sofrer contenção:

1.Autovacuum: O processo Autovacuum é responsável por realizar a manutenção

automática das tabelas, removendo registros excluídos e atualizando as estatísticas. A
contenção pode ocorrer quando várias tabelas exigem a execução simultânea do
Autovacuum, o que pode levar a atrasos e sobrecarga do sistema.

2.Background Writer (BGW): O processo Background Writer é responsável por

escrever os buffers de dados modificados em disco. A contenção pode ocorrer
quando muitos buffers precisam ser gravados simultaneamente, resultando em
atrasos e aumento da carga de trabalho no BGW.

3.Checkpointer: O processo Checkpointer é responsável por gravar os buffers

modificados no disco durante checkpoints. A contenção pode ocorrer quando
checkpoints frequentes são ativados ou quando há muita atividade de gravação,

31
causando atrasos e pressão adicional sobre o Checkpointer.

4.WalWriter: O processo WalWriter é responsável por gravar os registros de log (WAL)

em disco. A contenção pode ocorrer quando há uma alta taxa de geração de registros
de log ou quando o sistema de armazenamento apresenta restrições de I/O,
resultando em atrasos na gravação de registros de log.

É importante observar que a contenção nos processos background do PostgreSQL

pode ser influenciada por vários fatores, como carga de trabalho, configuração do
banco de dados e recursos do sistema. Monitorar o desempenho e os indicadores
relevantes, como a atividade de I/O, taxa de gravação e latência, é fundamental para
identificar e resolver problemas de contenção.

Ao lidar com contenção nos processos background do PostgreSQL, algumas

estratégias comuns incluem:

•Ajustar a configuração do banco de dados, como o número máximo de processos

Autovacuum e parâmetros relacionados a checkpoints e gravação de logs.

•Otimizar a configuração e o desempenho do armazenamento, garantindo que não

haja restrições de I/O e ajustando as configurações do sistema de arquivos.

•Monitorar e ajustar os parâmetros de desempenho, como buffers e caches, para

otimizar o uso de recursos e minimizar a contenção.

No PostgreSQL, a contenção de processos background mais nociva é a contenção de

Autovacuum. O Autovacuum é responsável pela manutenção automática das tabelas,
removendo registros excluídos e atualizando as estatísticas. Quando ocorre
contenção no processo Autovacuum, pode afetar significativamente o desempenho
do banco de dados e causar problemas como:

1.Fragmentação de tabelas: A contenção no Autovacuum pode resultar na falta de

execução adequada das operações de VACUUM e ANALYZE, levando à fragmentação
das tabelas. Isso pode resultar em aumento do espaço em disco ocupado pelas
tabelas, tempo de consulta mais lento e degradação geral do desempenho.

2.Atrasos nas transações: Se o Autovacuum não consegue acompanhar a taxa de

modificação das tabelas, registros excluídos podem permanecer por mais tempo,
ocupando espaço e afetando a disponibilidade do espaço livre. Isso pode resultar em
atrasos nas transações que precisam adquirir bloqueios nas tabelas afetadas.

31
3. Problemas de concorrência: A contenção no Autovacuum pode levar a bloqueios
prolongados e conflitos de concorrência. Se várias transações estão aguardando a
execução do Autovacuum em uma tabela específica, isso pode levar a atrasos na
execução de outras transações que precisam acessar essa tabela.

Para mitigar a contenção de Autovacuum e minimizar seus impactos, algumas

estratégias incluem:

•Ajustar as configurações relacionadas ao Autovacuum, como o atraso (delay) entre

as execuções do Autovacuum e o número máximo de processos Autovacuum.

•Monitorar o desempenho e a taxa de modificação das tabelas para ajustar as

configurações do Autovacuum de acordo com as necessidades do banco de dados.

•Realizar um planejamento adequado do armazenamento e definir o tamanho

correto para as tabelas, a fim de minimizar a necessidade de operações de
Autovacuum frequentes.

•Dividir tabelas grandes em partições menores para facilitar o processo de

Autovacuum e limitar a contenção em tabelas individuais.

31
 Espera Contenção

Contenção x Espera

Contenção: A contenção ocorre quando duas ou mais
transações estão competindo por um recurso
compartilhado, como uma tabela, uma página de dados
ou um bloqueio. Quando uma transação precisa acessar
um recurso que está sendo usado por outra transação,
ela precisa aguardar até que o recurso esteja disponível.
Isso pode levar a atrasos no processamento das
transações e afetar o desempenho geral do sistema. A
contenção pode ocorrer devido a uma variedade de
fatores, como concorrência de acesso a dados, bloqueios
conflitantes ou configuração inadequada do banco de
dados.
Espera: A espera, por sua vez, refere-se ao estado em que
uma transação se encontra quando ela precisa aguardar a
disponibilidade de um recurso que está sendo usado por
outra transação. Quando uma transação não consegue
obter acesso imediato a um recurso necessário, ela entra
em um estado de espera até que o recurso seja liberado
pela transação que está utilizando. Durante esse período, a
transação permanece inativa e não pode prosseguir com
sua execução. As esperas podem ser causadas por
contenção, bloqueios ou outros eventos que exigem que
uma transação aguarde a disponibilidade de um recurso.

São faces da mesma moeda, ou seja estão interligados, quando temos contenção
(Cara) possivelmente teremos espera e toda a espera advém de uma contenção.

A espera representa o sintoma e a contenção representa a causa do problema ou seja

a patologia a ser tratada.

NOTA:

Podemos estabelecer uma analogia entre contenção e espera em um banco de dados

e uma patologia clínica e seus sintomas. Vamos usar como exemplo uma analogia
comum, a gripe:

•Contenção: Na analogia com a gripe, a contenção seria equivalente à causa

subjacente da doença, como o vírus da gripe. Assim como a contenção ocorre
quando várias transações competem por recursos, a presença do vírus da gripe
desencadeia uma série de eventos no corpo que resultam nos sintomas da doença.

•Espera: Na analogia, a espera seria equivalente aos sintomas observados na gripe.

32
Quando uma transação entra em espera, ela está aguardando a disponibilidade de
um recurso necessário. Da mesma forma, os sintomas da gripe, como febre, dores no
corpo, tosse e congestionamento nasal, são sinais de que o corpo está aguardando a
recuperação e a disponibilidade de recursos para combater o vírus.

Assim como a contenção e a espera estão interligadas no contexto de um banco de

dados, a causa subjacente e os sintomas estão relacionados na analogia da gripe.
Ambos são parte de um processo mais amplo e representam diferentes aspectos de
uma mesma situação.

É importante ressaltar que essa analogia é meramente ilustrativa e não deve ser
interpretada como uma descrição científica precisa de uma patologia clínica
específica. No entanto, pode ajudar a compreender as semelhanças conceituais entre
contenção e espera em um banco de dados e uma patologia clínica e seus sintomas.

32
 Bloqueios de sessões de
banco de dados

Bloqueios de tabelas, registros, paginas podem ser deveram ser atendidos na sua respectiva ordem de
criados em transações e são adquiridos por uma chegada segundo o algoritimo FIFO (First IN – First Out),
determinada sessão de banco de dados, isso poderá isso implicará no encadeamento destes bloqueios
levar a que outras sessões possam ter que aguardar os provocando em muitos casos problemas graves de
recursos demandados pela sessão que originalmente performance. Analisar a causa nestes casos é fundamental ,
solicitou os bloqueios, e isso irá provocar um bloqueio já que o bloqueio é apenas um efeito , conforme
da sessão secundária , que colocará sua solicitação de mostramos no tópico anterior de contenção e espera.
bloqueio em uma fila de solicitações e aguardará o
tempo para que possa ser atendida, esse tempo irá
provocar uma espera, caso outras sessões venham após
a sessão secundária solicitar pelo recurso preso pela
sessão originária teremos uma cascata de bloqueios que

Os bloqueios de sessões em um banco de dados podem ocorrer devido a várias

causas de contenção. Algumas das possíveis causas de bloqueios de sessões são:

1.Concorrência de acesso a recursos: Quando várias sessões tentam acessar e

modificar o mesmo recurso simultaneamente, como uma tabela ou uma linha
específica, pode ocorrer contenção devido à necessidade de adquirir bloqueios
exclusivos para realizar operações de gravação. Se uma sessão já tiver adquirido um
bloqueio exclusivo, outras sessões terão que esperar até que o bloqueio seja
liberado.

2.Transações longas: Se uma transação mantiver bloqueios por um longo período,

pode causar contenção com outras sessões que também necessitam acessar os
mesmos recursos. Isso pode ocorrer quando uma transação executa várias operações
complexas ou quando um ponto de salvamento é mantido por um período
prolongado.

3.Incompatibilidade de bloqueios: Quando duas sessões tentam adquirir bloqueios

incompatíveis em um recurso, ocorre uma situação de contenção. Por exemplo, se
uma sessão possui um bloqueio de leitura (shared lock) em uma tabela e outra

33
sessão tenta adquirir um bloqueio de escrita (exclusive lock) na mesma tabela, haverá
uma contenção até que o bloqueio de leitura seja liberado.

4.Deadlocks: Um deadlock ocorre quando duas ou mais sessões ficam bloqueadas

esperando umas pelas outras, resultando em uma situação em que nenhuma das
sessões pode prosseguir. Isso pode acontecer quando as sessões têm bloqueios em
recursos diferentes, mas cada uma delas precisa adquirir um bloqueio que está sendo
mantido pela outra sessão.

5.Configuração inadequada: Uma configuração inadequada dos parâmetros de

bloqueio do banco de dados, como o tamanho do escalonamento de bloqueio ou os
níveis de isolamento, pode levar a uma maior chance de contenção. Por exemplo, um
escalonamento de bloqueio muito pequeno pode levar a mais bloqueios exclusivos
em vez de bloqueios compartilhados, aumentando a contenção.

O QUE PODEMOS FAZER PARA RESOLVER A QUESTÃO DE BLOQUEIOS E CONTENÇÕES

EM BANCO DE DADOS:

As possíveis causas de bloqueios em SQL Server, Oracle e PostgreSQL são

semelhantes e incluem:

1.Concorrência de acesso a recursos: Quando várias transações tentam acessar e

modificar os mesmos recursos simultaneamente, ocorre contenção devido à
necessidade de adquirir bloqueios exclusivos para realizar operações de gravação.
Isso pode resultar em bloqueios mútuos, onde uma transação espera pela liberação
de um recurso que está sendo utilizado por outra transação.

2.Transações longas: Se uma transação mantiver bloqueios por um longo período,

pode causar contenção com outras transações que também necessitam acessar os
mesmos recursos. Transações longas podem aumentar o tempo de espera para a
aquisição de bloqueios e diminuir a concorrência, resultando em bloqueios e atrasos.

3.Deadlocks: Um deadlock ocorre quando duas ou mais transações ficam bloqueadas

esperando umas pelas outras, criando um ciclo de bloqueio. Isso pode ocorrer
quando as transações possuem bloqueios em recursos diferentes, mas cada uma
delas precisa adquirir um bloqueio que está sendo mantido pela outra transação.

Para identificar e resolver problemas de bloqueio de forma prática, você pode seguir
as seguintes abordagens:

33
1. Monitoramento e análise:

•Utilize ferramentas de monitoramento e diagnóstico fornecidas pelo SQL Server,

Oracle e PostgreSQL para identificar transações bloqueadas, bloqueios ativos e
deadlocks.

•Analise os logs de bloqueio e registros de eventos para obter informações sobre as

transações envolvidas, os recursos bloqueados e os bloqueios adquiridos.

•Identifique os padrões de bloqueio recorrentes, como tabelas ou consultas

específicas que são frequentemente bloqueadas.

2.Otimização de consultas:

•Analise e otimize consultas que envolvem operações intensivas de leitura e gravação

para reduzir a probabilidade de bloqueios.

•Certifique-se de que as consultas estejam utilizando índices adequados, evitando

escaneamentos de tabela desnecessários e reduzindo a contenção.

3.Níveis de isolamento:

•Ajuste os níveis de isolamento das transações conforme necessário para equilibrar a

consistência dos dados e o desempenho.

•Utilize níveis de isolamento mais restritos apenas quando necessário, para evitar
bloqueios excessivos e melhorar a concorrência.

4.Revisão de transações longas:

•Analise as transações que mantêm bloqueios por períodos prolongados e identifique

maneiras de reduzir sua duração ou dividi-las em etapas menores.

•Considere a implementação de transações com tempos de vida mais curtos ou a

utilização de commits mais frequentes para liberar bloqueios mais rapidamente.

5.Ajuste da configuração do banco de dados:

•Avalie e ajuste os parâmetros relacionados ao gerenciamento de bloqueio no SQL

Server, Oracle e PostgreSQL para atender às necessidades específicas do ambiente.

•Considere aumentar o tamanho do escalonamento de bloqueio ou ajustar os tempos

33
de espera para permitir maior concorrência.

33
 Bloqueios em SQL Server
Identificando esperas
provocadas por bloqueios

Para identificarmos esperas, podemos usar recursos

como ferramentas disponíveis no SQL SERVER Bloqueios em Oracle
MANAGEMENT STUDIO (SSMS) , no pgAdmin
(PostgreSQL) e no SQL Developer (Oracle), porem os
scripts listados permitem a identificação em qualquer
ferramenta de forma automática e sem a necessidade de
intermediários

Bloqueios em PostgreSQL

Os eventos de espera por bloqueios em bancos de dados ocorrem quando uma

transação está aguardando a liberação de um bloqueio para poder prosseguir com
sua operação. Esses eventos são registrados nos sistemas de gerenciamento de
banco de dados e podem ser identificados por meio de consultas ou comandos
específicos.

No SQL Server, um exemplo de identificação de bloqueios em andamento pode ser

feito utilizando a consulta abaixo:

SELECT
blocked.session_id AS SessionID,
blocked.wait_duration_ms AS WaitDuration,
blocked.blocking_session_id AS BlockingSessionID,
blocked.resource_type AS ResourceType,
blocked.resource_description AS ResourceDescription,
blocking.last_wait_type AS BlockingWaitType,
blocking.command AS BlockingCommand
FROM
sys.dm_os_waiting_tasks AS blocked

34
 INNER JOIN sys.dm_exec_requests AS blocking
ON blocked.blocking_session_id = blocking.session_id
WHERE
blocked.wait_type LIKE 'LCK%'

No Oracle, é possível identificar os bloqueios em andamento utilizando a seguinte

consulta:

SELECT
session_id, lock_type, mode_held, mode_requested,
lock_id1, lock_id2
FROM
v$lock
WHERE
request > 0

No PostgreSQL, a identificação de bloqueios em andamento pode ser feita com a

seguinte consulta:

SELECT
blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_query,
blocking_activity.query AS blocking_query
FROM
pg_catalog.pg_locks AS blocked_locks
JOIN pg_catalog.pg_stat_activity AS blocked_activity ON blocked_activity.pid =
blocked_locks.pid
JOIN pg_catalog.pg_locks AS blocking_locks ON blocking_locks.locktype =
blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM
blocked_locks.transactionid

34
 AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity AS blocking_activity ON blocking_activity.pid =
blocking_locks.pid
WHERE
NOT blocked_locks.GRANTED

34
 SQL Server
Transações em banco de
dados

Transações são determinados por 1 ou mais comandos DML que em

conjunto determinam uma unidade lógica, seja de negócio, seja de
algum tipo de ação comum.
Transações podem ser controladas e precisam ser efetivadas (salvas) ou Oracle
desfeitas (canceladas) sem a que a aplicação que as defina precise
desfazer todos os comandos envolvidos na mesma de forma individual.
A efetivação é feita pelo comando COMMIT e o cancelamento é
realizado pelo comando ROLLBACK. Transações devem contemplar as
características (ACID) já tratadas anteriormente.
Transações podem ser fatiadas e desfeitas parcialmente, a efetivação
sempre será da transação como um todo, porem podemos criar pontos
de transação denominados SAVEPOINTS que poderão ajudar as
PostgreSQL
transações mais complexas em caso de necessidade de serem desfeitas ,
que isso possa ser feito de apenas parte da transação.
Transações podem ser implícitas ou explícitas.

A forma como as transações são controladas e tratadas varia em cada banco de

dados:

SQL Server: No SQL Server, as transações são controladas implicitamente pela

instrução BEGIN TRANSACTION, que marca o início de uma transação. O COMMIT é
usado para confirmar as alterações feitas pela transação, tornando-as permanentes.
O ROLLBACK é usado para desfazer todas as alterações feitas pela transação e
retornar o banco de dados ao estado anterior.

Exemplo de transação no SQL Server:

BEGIN TRANSACTION;

-- Executar operações de inserção/atualização/exclusão

COMMIT;
Oracle: No Oracle, as transações são controladas explicitamente pelo uso dos

35
comandos COMMIT e ROLLBACK. O COMMIT confirma as alterações feitas pela
transação, enquanto o ROLLBACK desfaz todas as alterações e retorna o banco de
dados ao estado anterior.

Exemplo de transação no Oracle:

BEGIN
SAVEPOINT start_transaction;

-- Executar operações de inserção/atualização/exclusão

COMMIT;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO start_transaction;
RAISE;
END;

PostgreSQL: No PostgreSQL, as transações são controladas implicitamente por

padrão. Cada instrução SQL é executada em uma transação separada. O COMMIT é
usado para confirmar as alterações e o ROLLBACK é usado para desfazer as
alterações.

Exemplo de transação no PostgreSQL:

BEGIN;

-- Executar operações de inserção/atualização/exclusão

COMMIT;

PARA RECORDAR (ACID):

1.Atomicidade: Uma transação é atômica, o que significa que todas as suas

operações são tratadas como uma única unidade. Se uma operação falhar ou ocorrer
um erro, todas as operações da transação são desfeitas (rollback), e nenhuma

35
alteração é aplicada ao banco de dados.

2.Consistência: As transações garantem a consistência dos dados, garantindo que o

banco de dados esteja em um estado válido antes e após a execução da transação. Se
uma transação violar as restrições de integridade do banco de dados, ela será
revertida.

3.Isolamento: As transações são isoladas umas das outras, o que significa que cada
transação é executada como se fosse a única transação em execução no banco de
dados. Isso evita que transações concorrentes interfiram umas nas outras e garante a
integridade dos dados.

4.Durabilidade: Uma vez que uma transação é confirmada (committed), suas

alterações se tornam permanentes e não podem ser desfeitas (undone). As
alterações persistem mesmo em caso de falha do sistema ou reinicialização do banco
de dados.

TRANSAÇÕES IMPLICITAS E EXPLICITAS:

SQL Server:

1.Commit Explícito (Explicit Commit): O SQL Server permite a realização de commits

explícitos usando o comando COMMIT TRANSACTION. Ele é usado para confirmar as
alterações feitas dentro da transação e torná-las permanentes. Um commit explícito
também encerra a transação atual.

2.Commit Implícito (Implicit Commit): O SQL Server realiza commits implícitos

automaticamente em várias situações, como ao executar comandos DDL (Data
Definition Language) e certas operações de controle de transações. Um commit
implícito encerra a transação atual e torna as alterações permanentes.

Oracle:

1.Commit Implícito (Implicit Commit): O Oracle realiza commits implícitos

automaticamente em várias situações, como ao executar comandos DDL (Data
Definition Language) e certas operações de controle de transações. Um commit
implícito encerra a transação atual e torna as alterações permanentes.

2.Commit Explícito (Explicit Commit): É o commit realizado explicitamente pelo

comando COMMIT. Ele é usado para confirmar as alterações feitas dentro da

35
transação e torná-las permanentes. Um commit explícito também encerra a
transação atual.

PostgreSQL:

1.Commit Explícito (Explicit Commit): O PostgreSQL também permite a realização de

commits explícitos usando o comando COMMIT. Ele é usado para confirmar as
alterações feitas dentro da transação e torná-las permanentes. Um commit explícito
encerra a transação atual.

2.Commit Implícito (Implicit Commit): O PostgreSQL realiza um commit implícito ao

final de cada comando SQL individual, a menos que uma transação explícita esteja
em andamento. Isso significa que, por padrão, cada comando SQL é tratado como
uma transação separada e é efetuado um commit automático após sua execução.

35
 SQL Server

COMMIT

COMMIT é o comando que efetiva uma transação, liberando os

bloqueios sobre os registros, páginas, tabela, tablespace/Filegroup e
banco de dados.
Este comando provoca que os comandos depositados no mecanismo de Oracle
log buffer tanto do SQL Server, quanto Oracle e PostgreSQL sejam
despejados na estrutura física em disco para acomodar as transações
realizadas nos mecanismos de armazenamento de logs em discos, isso
provoca uma escrita da memória em disco.
Um alto volume de commits pode ser bastante nociva a performance do
banco pois exigirá que o mesmo escreva em disco mais tempo em disco,
podendo ocasionar problemas de performance severos
Commits encerram uma transação e nunca podem ser parciais, ou tudo
PostgreSQL
é salvo ou não. É possível aplicar alguns tipos de commits diferenciados
dependendo da versão do banco de dados

O comando COMMIT provoca os seguintes efeitos em instâncias dos bancos de dados

SQL Server, Oracle e PostgreSQL:

SQL Server:

1.Confirmação das alterações: O comando COMMIT confirma as alterações feitas

dentro da transação, tornando-as permanentes no banco de dados.

2.Liberação de bloqueios: Todos os bloqueios adquiridos pela transação são

liberados, permitindo que outras transações acessem os recursos anteriormente
bloqueados.

3.Atualização do log de transações: O log de transações é atualizado para refletir as

alterações confirmadas. Isso garante a durabilidade das alterações e permite a
recuperação em caso de falhas.

Oracle:

1.Confirmação das alterações: O comando COMMIT confirma as alterações feitas

36
dentro da transação, tornando-as permanentes no banco de dados.

2.Liberação de bloqueios: Todos os bloqueios adquiridos pela transação são

liberados, permitindo que outras transações acessem os recursos anteriormente
bloqueados.

3.Atualização do log de transações: O log de transações é atualizado para refletir as

alterações confirmadas. Isso garante a durabilidade das alterações e permite a
recuperação em caso de falhas.

PostgreSQL:

1.Confirmação das alterações: O comando COMMIT confirma as alterações feitas

dentro da transação, tornando-as permanentes no banco de dados.

2.Liberação de bloqueios: Todos os bloqueios adquiridos pela transação são

liberados, permitindo que outras transações acessem os recursos anteriormente
bloqueados.

3.Atualização do log de transações: O log de transações é atualizado para refletir as

alterações confirmadas. Isso garante a durabilidade das alterações e permite a
recuperação em caso de falhas.

4.Atualização de índices: Os índices são atualizados para refletir as alterações

confirmadas. Isso garante a consistência e a integridade dos índices em relação aos
dados atualizados.

TIPOS DE COMMITS EM SQL SERVER, ORACLE E POSTGRESQL:

SQL Server:

COMMIT: É o comando padrão para realizar um commit explícito no SQL Server. Ele
confirma todas as alterações feitas dentro da transação e as torna permanentes no
banco de dados.

COMMIT WORK: É uma variação do comando COMMIT que também realiza um

commit explícito. Ambos os comandos têm o mesmo efeito e podem ser usados para
confirmar as alterações e encerrar a transação.

Exemplo de uso no SQL Server:

36
BEGIN TRANSACTION;

-- Executar operações de inserção/atualização/exclusão

COMMIT;

Oracle:

COMMIT: Assim como no SQL Server, o comando COMMIT é utilizado para realizar
um commit explícito no Oracle. Ele confirma todas as alterações feitas dentro da
transação e as torna permanentes.

COMMIT WRITE IMMEDIATE: É um tipo específico de commit no Oracle que garante

que os dados confirmados sejam gravados imediatamente no disco. Isso evita que os
dados confirmados sejam armazenados apenas em buffers de memória e ainda não
sejam gravados em disco.

Exemplo de uso no Oracle:

BEGIN
SAVEPOINT start_transaction;

-- Executar operações de inserção/atualização/exclusão

COMMIT WRITE IMMEDIATE;

EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO start_transaction;
RAISE;
END;

COMMIT FORCE: Esse comando é usado para forçar a gravação imediata de todas as
alterações confirmadas no disco, mesmo que o banco de dados esteja configurado
com a gravação assíncrona ativada. Ele garante que todas as alterações confirmadas
sejam gravadas permanentemente antes de retornar.
Exemplo de uso no Oracle:

BEGIN

36
 SAVEPOINT start_transaction;

-- Executar operações de inserção/atualização/exclusão

COMMIT FORCE;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO start_transaction;
RAISE;
END;

COMMIT WRITE BATCH: Esse tipo de commit no Oracle é semelhante ao COMMIT

WRITE IMMEDIATE, mas permite que várias confirmações sejam agrupadas em uma
única gravação em lote. Isso pode melhorar o desempenho em situações em que há
um grande número de commits consecutivos.

Exemplo de uso no Oracle:

BEGIN
SAVEPOINT start_transaction;

-- Executar operações de inserção/atualização/exclusão

COMMIT WRITE BATCH;

EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO start_transaction;
RAISE;
END;

PostgreSQL:

COMMIT: No PostgreSQL, o comando COMMIT também é utilizado para realizar um

commit explícito. Ele confirma todas as alterações feitas dentro da transação e as
torna permanentes.

COMMIT PREPARED: É um comando específico do PostgreSQL que é usado para

confirmar uma transação preparada. Uma transação preparada é uma transação que
foi marcada como "preparada" e está aguardando um comando COMMIT PREPARED
para ser confirmada. Isso é útil em cenários de replicação e recuperação de

36
desastres.

Exemplo de uso no PostgreSQL:

BEGIN;

-- Executar operações de inserção/atualização/exclusão

COMMIT;

BEGIN;
-- Executar operações de inserção/atualização/exclusão
PREPARE TRANSACTION ‘Minha_transacao’;

COMMIT PREPARED ‘Minha_transacao’;

O comando PREPARE TRANSACTION 'my_transaction' marca a transação atual como

"preparada" e a associa a um nome, neste caso 'my_transaction'. Em seguida, o
COMMIT PREPARED 'my_transaction' é usado para confirmar essa transação
preparada.

É importante ressaltar que o suporte a transações preparadas pode variar de acordo

com a versão e a configuração do PostgreSQL. Além disso, é necessário usar a função
pg_prepared_xacts() para verificar as transações preparadas existentes e a função
pg_cancel_prepared_tx() para cancelar transações preparadas caso necessário.

36
 SQL Server

ROLLBACK

ROLLBACK é o comando que desfaz uma transação total ou

parcialmente, liberando os bloqueios sobre os registros, páginas, tabela,
tablespace/Filegroup e banco de dados.
Oracle
Este comando não provoca escrita imediata no banco a exemplo do que
ocorre em comando COMMIT, pois a transação ainda não foi escrita e os
blocos e páginas de dados ainda não foram escritos em disco.

O comando ROLLBACK pode desfazer toda a transação se for aplicado de

forma direta sem o uso de SAVEPOINT definido durante a transação,
neste caso os comandos anteriores ao SAVEPOINT ficariam pendentes de
salvamento ou cancelamento, então neste caso o comando COMMIT
PostgreSQL
poderia ter efeito após um comando ROLLBACK TO SAVEPOINT X;

O comando ROLLBACK é usado nos bancos de dados SQL Server, Oracle e PostgreSQL
para desfazer ou cancelar uma transação, revertendo todas as alterações feitas até o
ponto atual da transação. Cada banco de dados possui diferentes tipos de rollback
disponíveis:

SQL Server:

1.ROLLBACK: O comando ROLLBACK é usado para desfazer todas as alterações feitas

dentro de uma transação e retornar o banco de dados ao estado anterior à transação.

2.ROLLBACK TRANSACTION: É uma forma alternativa de usar o comando ROLLBACK

no SQL Server. Ele desfaz todas as alterações feitas na transação atual e retorna o
banco de dados ao estado anterior.

Oracle:

1.ROLLBACK: O comando ROLLBACK no Oracle é usado para desfazer todas as

alterações feitas dentro de uma transação e retornar o banco de dados ao estado
anterior à transação.

37
2.ROLLBACK TO SAVEPOINT: Esse comando é usado para desfazer as alterações feitas
após um savepoint específico. O savepoint é definido usando o comando SAVEPOINT
e pode ser usado para desfazer parte de uma transação, em vez de desfazer todas as
alterações.

PostgreSQL:

1.ROLLBACK: O comando ROLLBACK no PostgreSQL é usado para desfazer todas as

alterações feitas dentro de uma transação e retornar o banco de dados ao estado
anterior à transação.

2.ROLLBACK TO SAVEPOINT: Assim como no Oracle, o comando ROLLBACK TO

SAVEPOINT no PostgreSQL é usado para desfazer as alterações feitas após um
savepoint específico.

3.ROLLBACK PREPARED: Esse comando é usado para cancelar uma transação

preparada no PostgreSQL. Uma transação preparada é aquela que foi marcada como
"preparada" e está aguardando um comando COMMIT PREPARED para ser
confirmada.

37
 SQL Server

SAVEPOINT

SAVEPOINT é o comando que determina o início de uma transação

explicita em banco de dados, este ponteiro determina que uma PostgreSQL
transação possa ser desfeita a partir do mesmo, com isso o comando Oracle
ROLLBACK poderá atuar de forma parcial.
A regra do COMMIT depois do ROLLBACK não ter efeito e vice-versa não
existem quando há a inclusão de um comando SAVEPOINT.
Usado normalmente para transações mais complexas e que necessitem
de um maior grau de controle e que possam ser desfeitas parcialmente
dependendo da necessidade.
Pode ser usado em aplicações que utilizem qualquer linguagem que
suporte a linguagem SQL pois não se trata de comando de programação
de linguagem de banco de dados como PL/SQL (Oracle)
,PgSQL(PostgreSQL), TSQL(SQL Server).

Exemplos completos de uso do comando SAVEPOINT, incluindo o ROLLBACK para

savepoint nos bancos de dados SQL Server, Oracle e PostgreSQL:

SQL Server:

BEGIN TRANSACTION;

-- Executar operações de inserção/atualização/exclusão

SAVE TRANSACTION Savepoint1;

-- Executar mais operações

SAVE TRANSACTION Savepoint2;

-- Executar mais operações

-- Reverter para o savepoint Savepoint1

38
ROLLBACK TRANSACTION Savepoint1;

-- Executar mais operações

-- Confirmar as alterações
COMMIT;

Oracle:

BEGIN
SAVEPOINT Savepoint1;

-- Executar operações de inserção/atualização/exclusão

SAVEPOINT Savepoint2;

-- Executar mais operações

-- Reverter para o savepoint Savepoint1

ROLLBACK TO Savepoint1;

-- Executar mais operações

-- Confirmar as alterações
COMMIT;
END;

PostgreSQL:

BEGIN;

-- Executar operações de inserção/atualização/exclusão

SAVEPOINT Savepoint1;

-- Executar mais operações

SAVEPOINT Savepoint2;

38
-- Executar mais operações

-- Reverter para o savepoint Savepoint1

ROLLBACK TO Savepoint1;

-- Executar mais operações

-- Confirmar as alterações
COMMIT;

Nos exemplos acima, o comando SAVEPOINT é usado para criar pontos de

salvamento (savepoints) dentro de uma transação. Esses pontos permitem reverter a
transação para um estado anterior, caso necessário. O ROLLBACK TO é usado para
reverter a transação para o savepoint específico indicado, desfazendo as alterações
feitas após esse ponto. Em seguida, a transação pode continuar com novas operações
ou ser confirmada usando o comando COMMIT para tornar as alterações
permanentes no banco de dados.

38
 MODOS DE ISOLAMENTO Modo de Isolamento
READ UNCOMMITTED Possível
Dirty Read Fuzzy Read
Possível Possível
Phantom

DE TRANSAÇÕES DE BANCO READ COMMITTED

REPEATABLE READ
Não aplicável
Não aplicável
Possível
Não aplicável
Possível
Possível

DE DADOS (ANSI) SERIALIZABLE Não aplicável Não aplicável Não aplicável

Os modos de isolamento dos bancos de dados ANSI (American

National Standards Institute) referem-se a um conjunto padrão de
níveis de isolamento de transações definidos pela ANSI. Esses
níveis de isolamento são usados ​para controlar como as
transações interagem umas com as outras e garantem a
consistência e a integridade dos dados em um ambiente
multiusuário.

São descritos abaixo:

- READ UNCOMMITED
- READ COMMITED
- REPEATABLE READ
- SERIALIZABLE

Os quatro modos de isolamento definidos pela ANSI são:

1.READ UNCOMMITTED: Este é o nível de isolamento mais baixo. Ele permite que
uma transação leia dados não confirmados por outras transações, resultando em
leituras sujas (dirty reads). Isso significa que as alterações feitas por outras transações
ainda não confirmadas podem ser lidas, o que pode levar a resultados inconsistentes.

2.READ COMMITTED: Nesse nível de isolamento, uma transação garante que os

dados lidos sejam confirmados por outras transações. As leituras sujas são evitadas,
mas ainda é possível ocorrerem leituras repetíveis (repeatable reads) ou leituras
fantasma (phantom reads). Leituras repetíveis se referem à possibilidade de uma
transação ler os mesmos dados várias vezes e obter resultados diferentes, enquanto
leituras fantasma ocorrem quando novas linhas são inseridas ou removidas por
outras transações durante a execução da transação atual.

3.REPEATABLE READ: Nesse nível de isolamento, uma transação garante que as

leituras sejam repetíveis. Isso significa que, uma vez que uma linha é lida durante a
transação, os valores lidos permanecem os mesmos até o final da transação. No
entanto, ainda é possível ocorrerem leituras fantasma, onde novas linhas são

39
inseridas ou removidas por outras transações durante a execução da transação atual.

4.SERIALIZABLE: Este é o nível de isolamento mais alto e garante que as transações

sejam executadas como se fossem isoladas uma da outra. Ele garante a máxima
consistência dos dados, evitando leituras sujas, leituras repetíveis e leituras fantasma.
No entanto, esse nível de isolamento pode levar a bloqueios e baixa concorrência,
pois as transações precisam aguardar uns pelas outras.
É importante observar que, embora os níveis de isolamento ANSI forneçam uma base
padronizada, cada banco de dados pode implementá-los de maneiras ligeiramente
diferentes. Além disso, alguns bancos de dados podem oferecer níveis de isolamento
adicionais além dos definidos pela ANSI, como o modo "SNAPSHOT ISOLATION" ou
opções personalizadas de isolamento. É recomendável consultar a documentação
específica do banco de dados para obter informações detalhadas sobre os níveis de
isolamento disponíveis e como eles são implementados.

EXEMPLOS DE MODOS DE ISOLAMENTO:

1.READ UNCOMMITTED: Exemplo: Em um sistema de reserva de ingressos de

cinema, duas transações estão ocorrendo simultaneamente. A primeira transação
está atualizando a quantidade de ingressos disponíveis para um determinado filme,
enquanto a segunda transação está consultando a quantidade de ingressos
disponíveis. Com o nível de isolamento READ UNCOMMITTED, a segunda transação
pode ler os dados atualizados pela primeira transação antes mesmo de serem
confirmados, resultando em leituras sujas. Isso pode levar a inconsistências, como
vender mais ingressos do que realmente estão disponíveis.

2.READ COMMITTED: Exemplo: Em um sistema de gerenciamento de estoque, uma

transação está consultando a quantidade de um determinado item disponível no
estoque. Ao mesmo tempo, outra transação está atualizando essa quantidade. Com o
nível de isolamento READ COMMITTED, a primeira transação só pode ver a
quantidade atualizada depois que a segunda transação a confirmar. Isso evita leituras
sujas, pois a primeira transação não vê as alterações não confirmadas da segunda
transação.

3.REPEATABLE READ: Exemplo: Em um sistema de gerenciamento de pedidos online,

uma transação está consultando um determinado pedido e verificando o status do
pagamento. Enquanto isso, outra transação está atualizando o status do pagamento
para "Pago". Com o nível de isolamento REPEATABLE READ, a primeira transação

39
continuará a ver o status de pagamento original, mesmo que a segunda transação o
atualize. Isso garante leituras repetíveis, pois a primeira transação vê os mesmos
dados consistentes ao longo da transação.

4.SERIALIZABLE: Exemplo: Em um sistema de banco de dados, várias transações estão

lendo e atualizando registros em uma tabela simultaneamente. Com o nível de
isolamento SERIALIZABLE, o banco de dados garante que cada transação seja
executada como se estivesse isolada das outras. Isso evita leituras sujas, leituras
repetíveis e leituras fantasma. As transações são processadas uma após a outra,
garantindo a consistência dos dados, mas também resultando em um potencial maior
de bloqueios e menor concorrência.

Para Oracle , SQL Server e PostgreSQL o modo default é o de READ COMMITED, que
implica que o banco de dados em uma consulta a dados retornará sempre os dados
que foram salvos, mesmo que estejam sendo alterados, no caso do SQL Server se isso
ocorrer a consulta será bloqueada enquanto a transação que a atualiza ou exlclui não
realizar um comando COMMIT ou ROLLBACK

P0,P1,P2,P3:

1.Dirty Read (Leitura Suja): Uma leitura suja ocorre quando uma transação lê dados
não confirmados de outra transação. Em outras palavras, uma transação lê dados que
foram modificados por outra transação e ainda não foram confirmados ou revertidos.
Isso pode resultar em inconsistências nos dados, pois a transação que realizou a
leitura suja pode tomar decisões com base em informações não confirmadas.
Leituras sujas são possíveis em níveis de isolamento mais baixos, como READ
UNCOMMITTED.

2.Fuzzy Read (Leitura Nebulosa): O termo "fuzzy read" não é amplamente usado no
contexto de modos de isolamento de banco de dados. No entanto, pode-se
interpretar uma "fuzzy read" como uma leitura que permite certa imprecisão ou
ambiguidade nos resultados. Isso geralmente ocorre quando o nível de isolamento
permite que outras transações insiram ou removam dados durante a leitura.
Consequentemente, as leituras subsequentes podem incluir resultados que não
estavam presentes na primeira leitura, resultando em resultados imprecisos ou
nebulosos.

3.Phantom: O fenômeno "phantom" ocorre quando uma transação executa uma

consulta que retorna um conjunto de linhas e, em seguida, executa a mesma consulta
novamente, mas obtém um conjunto de linhas diferente. Isso pode acontecer quando

39
outras transações inserem, atualizam ou excluem linhas que correspondem aos
critérios da consulta original. O fenômeno "phantom" é uma anomalia que ocorre em
níveis de isolamento que permitem leituras repetíveis, mas não garantem uma visão
consistente do conjunto de resultados entre as execuções da mesma consulta.

MODOS DE ISOLAMENTO IMPLEMENTADOS PELO SQL SERVER , ORACLE E

POSTGRESQL:

SQL Server:

•READ UNCOMMITTED (Leitura não confirmada)

•READ COMMITTED (Leitura confirmada)

•REPEATABLE READ (Leitura repetível)

•SERIALIZABLE (Serializável)

•SNAPSHOT (Instantâneo)

Oracle:

•READ COMMITTED (Leitura confirmada)

•READ WRITE (Leitura e escrita)

•SERIALIZABLE (Serializável)

PostgreSQL:

•READ COMMITTED (Leitura confirmada)

•REPEATABLE READ (Leitura repetível)

•SERIALIZABLE (Serializável)

•READ UNCOMMITTED (Leitura não confirmada)

39
É importante observar que, embora esses modos de isolamento sejam comumente
suportados pelos bancos de dados mencionados, cada banco de dados pode ter
opções adicionais específicas para configuração de isolamento ou extensões do
padrão ANSI. Além disso, cada banco de dados pode ter nomes e opções específicas
para seus modos de isolamento. Recomenda-se consultar a documentação oficial do
banco de dados específico para obter informações detalhadas sobre os modos de
isolamento suportados e suas configurações correspondentes.

EXEMPLOS DE IMPLEMENTAÇÃO DE MODOS DE ISOLAMENTO EM SQL SERVER,

ORACLE E POSTGRESQL:

SQL Server:
READ UNCOMMITTED:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
READ COMMITTED:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
REPEATABLE READ:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SERIALIZABLE:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SNAPSHOT:
ALTER DATABASE [NomeDoBanco] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [NomeDoBanco] SET READ_COMMITTED_SNAPSHOT ON;

Oracle:

READ COMMITTED:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
READ WRITE:
SET TRANSACTION READ WRITE;
SERIALIZABLE:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

PostgreSQL:

READ COMMITTED:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
REPEATABLE READ:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

39
SERIALIZABLE:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
READ UNCOMMITTED:
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED;

39