Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Aprenda Isolamento | Acid
Otimização de SQL e Recursos de Consulta

Isolamento

Deslize para mostrar o menu

No contexto de bancos de dados, isolamento refere-se à capacidade de um sistema de banco de dados de controlar a visibilidade das alterações feitas por transações concorrentes. Garante que as transações operem de forma independente umas das outras, evitando interferências e mantendo a integridade dos dados.

Existem 4 níveis de isolamento em SQL:

  • read uncommitted;
  • read committed;
  • repeatable read;
  • serializable.

Read uncommitted

Este é o nível mais baixo de isolamento, onde as transações podem ver alterações feitas por outras transações mesmo antes de serem confirmadas. Esse nível permite leituras sujas, ou seja, uma transação pode ler dados que foram modificados por outra transação, mas ainda não foram confirmados.

Leituras sujas

Note
Estude Mais

Uma leitura suja ocorre quando uma transação lê dados que foram modificados por outra transação, mas ainda não foram confirmados.

Por exemplo, imagine duas transações bancárias ocorrendo simultaneamente: a Transação A consulta o saldo da sua conta enquanto a Transação B deposita dinheiro na sua conta. Se a Transação A visualizar o saldo aumentado antes que a Transação B seja finalizada, trata-se de uma leitura suja, pois o novo saldo pode ser desfeito caso a Transação B falhe.

dirty+read

Implementação

Para especificar o nível de isolamento para a transação, podemos usar o seguinte comando em nossa consulta:

-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

/* Transaction query */
COMMIT;
  • SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;: Esta instrução altera o nível de isolamento da transação atual para "Read Uncommitted", permitindo que a transação leia dados modificados por outras transações não confirmadas;

  • este comando deve ser usado apenas dentro do bloco da transação! Caso contrário, não terá efeito, e o nível de isolamento padrão será utilizado.

Também podemos verificar o nível de isolamento atual usando o seguinte comando:
SHOW TRANSACTION ISOLATION LEVEL;

Read committed

O nível de isolamento Read Committed garante que uma transação veja apenas dados que foram confirmados por outras transações.
Isso significa que alterações não confirmadas feitas por outras transações não ficam visíveis para transações operando sob o isolamento Read Committed.
Como resultado, evita leituras sujas ao permitir que uma transação leia apenas dados confirmados. No entanto, esse nível de transação apresenta problemas com leituras não repetíveis.

Leituras não repetíveis

Note
Estude Mais

Uma leitura não repetível ocorre quando uma transação lê a mesma linha várias vezes dentro da mesma transação, mas os dados recuperados mudam entre as leituras devido a modificações feitas por outras transações. Essa inconsistência pode levar a comportamentos inesperados e resultados incorretos.

Por exemplo, imagine uma transação consultando o saldo da conta de um cliente duas vezes. A primeira consulta retorna $1000, mas antes que a transação seja concluída, outra transação deposita $500 na conta. Quando a segunda consulta é executada, ela mostra $1500, levando a uma leitura não repetível, onde os mesmos dados são lidos de forma diferente dentro de uma única transação devido a alterações feitas por outra transação.

O nível de isolamento "Read committed" permite leituras não repetíveis porque bloqueia a operação de leitura em valores que estão em processo de transações não confirmadas, mas não bloqueia a operação de escrita.
Como resultado, é possível gravar novos dados na linha que está sendo lida por outra transação.

Leitura não repetida

Atualização perdida

Devido à ausência de bloqueio de escrita, existe mais um problema com o nível de isolamento read committed - atualizações perdidas.

Note
Estude Mais

Uma atualização perdida é uma situação na administração de bancos de dados em que uma transação sobrescreve as alterações feitas por outra transação, levando à perda de dados. Isso normalmente ocorre quando várias transações tentam atualizar os mesmos dados simultaneamente, e as alterações de uma transação são sobrescritas por outra antes de serem confirmadas no banco de dados.

As atualizações perdidas ocorrem quando duas transações paralelas tentam alterar a mesma linha. Como resultado, a transação que é confirmada por último sobrescreve os valores confirmados por outras transações.

Lost_update

Implementação

Também é possível especificar este nível de isolamento utilizando os seguintes comandos:

-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

/* Transaction query */
COMMIT;

É importante observar que Read Committed é o nível de isolamento padrão para a maioria dos Sistemas de Gerenciamento de Banco de Dados, por isso podemos deixar de especificá-lo.

question mark

Se uma transação lê dados que foram modificados por outra transação não confirmada, que tipo de leitura é essa?

Selecione a resposta correta

Tudo estava claro?

Como podemos melhorá-lo?

Obrigado pelo seu feedback!

Seção 1. Capítulo 6

Pergunte à IA

expand

Pergunte à IA

ChatGPT

Pergunte o que quiser ou experimente uma das perguntas sugeridas para iniciar nosso bate-papo

Isolamento

No contexto de bancos de dados, isolamento refere-se à capacidade de um sistema de banco de dados de controlar a visibilidade das alterações feitas por transações concorrentes. Garante que as transações operem de forma independente umas das outras, evitando interferências e mantendo a integridade dos dados.

Existem 4 níveis de isolamento em SQL:

  • read uncommitted;
  • read committed;
  • repeatable read;
  • serializable.

Read uncommitted

Este é o nível mais baixo de isolamento, onde as transações podem ver alterações feitas por outras transações mesmo antes de serem confirmadas. Esse nível permite leituras sujas, ou seja, uma transação pode ler dados que foram modificados por outra transação, mas ainda não foram confirmados.

Leituras sujas

Note
Estude Mais

Uma leitura suja ocorre quando uma transação lê dados que foram modificados por outra transação, mas ainda não foram confirmados.

Por exemplo, imagine duas transações bancárias ocorrendo simultaneamente: a Transação A consulta o saldo da sua conta enquanto a Transação B deposita dinheiro na sua conta. Se a Transação A visualizar o saldo aumentado antes que a Transação B seja finalizada, trata-se de uma leitura suja, pois o novo saldo pode ser desfeito caso a Transação B falhe.

dirty+read

Implementação

Para especificar o nível de isolamento para a transação, podemos usar o seguinte comando em nossa consulta:

-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

/* Transaction query */
COMMIT;
  • SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;: Esta instrução altera o nível de isolamento da transação atual para "Read Uncommitted", permitindo que a transação leia dados modificados por outras transações não confirmadas;

  • este comando deve ser usado apenas dentro do bloco da transação! Caso contrário, não terá efeito, e o nível de isolamento padrão será utilizado.

Também podemos verificar o nível de isolamento atual usando o seguinte comando:
SHOW TRANSACTION ISOLATION LEVEL;

Read committed

O nível de isolamento Read Committed garante que uma transação veja apenas dados que foram confirmados por outras transações.
Isso significa que alterações não confirmadas feitas por outras transações não ficam visíveis para transações operando sob o isolamento Read Committed.
Como resultado, evita leituras sujas ao permitir que uma transação leia apenas dados confirmados. No entanto, esse nível de transação apresenta problemas com leituras não repetíveis.

Leituras não repetíveis

Note
Estude Mais

Uma leitura não repetível ocorre quando uma transação lê a mesma linha várias vezes dentro da mesma transação, mas os dados recuperados mudam entre as leituras devido a modificações feitas por outras transações. Essa inconsistência pode levar a comportamentos inesperados e resultados incorretos.

Por exemplo, imagine uma transação consultando o saldo da conta de um cliente duas vezes. A primeira consulta retorna $1000, mas antes que a transação seja concluída, outra transação deposita $500 na conta. Quando a segunda consulta é executada, ela mostra $1500, levando a uma leitura não repetível, onde os mesmos dados são lidos de forma diferente dentro de uma única transação devido a alterações feitas por outra transação.

O nível de isolamento "Read committed" permite leituras não repetíveis porque bloqueia a operação de leitura em valores que estão em processo de transações não confirmadas, mas não bloqueia a operação de escrita.
Como resultado, é possível gravar novos dados na linha que está sendo lida por outra transação.

Leitura não repetida

Atualização perdida

Devido à ausência de bloqueio de escrita, existe mais um problema com o nível de isolamento read committed - atualizações perdidas.

Note
Estude Mais

Uma atualização perdida é uma situação na administração de bancos de dados em que uma transação sobrescreve as alterações feitas por outra transação, levando à perda de dados. Isso normalmente ocorre quando várias transações tentam atualizar os mesmos dados simultaneamente, e as alterações de uma transação são sobrescritas por outra antes de serem confirmadas no banco de dados.

As atualizações perdidas ocorrem quando duas transações paralelas tentam alterar a mesma linha. Como resultado, a transação que é confirmada por último sobrescreve os valores confirmados por outras transações.

Lost_update

Implementação

Também é possível especificar este nível de isolamento utilizando os seguintes comandos:

-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

/* Transaction query */
COMMIT;

É importante observar que Read Committed é o nível de isolamento padrão para a maioria dos Sistemas de Gerenciamento de Banco de Dados, por isso podemos deixar de especificá-lo.

Tudo estava claro?

Como podemos melhorá-lo?

Obrigado pelo seu feedback!

Seção 1. Capítulo 6
some-alt