Isolamento (sistemas de banco de dados) - Isolation (database systems)

Em sistemas de banco de dados , o isolamento determina como a integridade da transação é visível para outros usuários e sistemas.

Um nível de isolamento mais baixo aumenta a capacidade de muitos usuários de acessar os mesmos dados ao mesmo tempo, mas aumenta o número de efeitos de simultaneidade (como leituras sujas ou atualizações perdidas) que os usuários podem encontrar. Por outro lado, um nível de isolamento mais alto reduz os tipos de efeitos de simultaneidade que os usuários podem encontrar, mas requer mais recursos do sistema e aumenta as chances de que uma transação bloqueie outra.

O isolamento é normalmente definido no nível do banco de dados como uma propriedade que define como ou quando as alterações feitas por uma operação se tornam visíveis para os outros. Em sistemas mais antigos, pode ser implementado sistemicamente, por exemplo, por meio do uso de tabelas temporárias. Em sistemas de duas camadas, um gerenciador de processamento de transações (TP) é necessário para manter o isolamento. Em sistemas de n camadas (como vários sites tentando reservar o último assento em um voo), uma combinação de procedimentos armazenados e gerenciamento de transações é necessária para confirmar a reserva e enviar a confirmação ao cliente.

O isolamento é uma das quatro propriedades do ACID , junto com a atomicidade , consistência e durabilidade .

Controle de simultaneidade

O controle de simultaneidade compreende os mecanismos subjacentes em um SGBD que tratam do isolamento e garantem a correção relacionada. É muito usado pelos motores de banco de dados e armazenamento para garantir a execução correta de transações simultâneas e (por meio de mecanismos diferentes) a correção de outros processos de DBMS. Os mecanismos relacionados à transação normalmente restringem o tempo das operações de acesso aos dados do banco de dados ( programações de transação ) a certos pedidos caracterizados como as propriedades de programação de serializabilidade e recuperabilidade . Restringir a execução da operação de acesso ao banco de dados normalmente significa desempenho reduzido (medido pelas taxas de execução) e, portanto, os mecanismos de controle de simultaneidade são normalmente projetados para fornecer o melhor desempenho possível sob as restrições. Freqüentemente, quando possível sem prejudicar a correção, a propriedade de serialização é comprometida para um melhor desempenho. No entanto, a capacidade de recuperação não pode ser comprometida, pois normalmente resulta em uma violação rápida da integridade do banco de dados .

O bloqueio de duas fases é o método de controle de simultaneidade de transação mais comum em DBMSs, usado para fornecer serializabilidade e recuperabilidade para correção. Para acessar um objeto de banco de dados, uma transação precisa primeiro adquirir um bloqueio para esse objeto. Dependendo do tipo de operação de acesso (por exemplo, ler ou escrever um objeto) e do tipo de bloqueio, a obtenção do bloqueio pode ser bloqueada e adiada, se outra transação estiver segurando um bloqueio para aquele objeto.

Leia fenômenos

O padrão ANSI / ISO SQL 92 refere-se a três fenômenos de leitura diferentes quando a Transação 1 lê dados que a Transação 2 pode ter alterado.

Nos exemplos a seguir, duas transações ocorrem. Na primeira, a Consulta 1 é realizada. Então, na segunda transação, a Consulta 2 é executada e confirmada. Por fim, na primeira transação, a Consulta 1 é realizada novamente.

As consultas usam a seguinte tabela de dados:

Comercial
eu ia nome era
1 Joe 20
2 Jill 25

Leituras sujas

Uma leitura suja (também conhecida como dependência não confirmada ) ocorre quando uma transação tem permissão para ler dados de uma linha que foi modificada por outra transação em execução e ainda não confirmada.

Leituras sujas funcionam de maneira semelhante às leituras não repetíveis ; no entanto, a segunda transação não precisaria ser confirmada para que a primeira consulta retornasse um resultado diferente. A única coisa que pode ser evitada no nível de isolamento READ UNCOMMITTED são as atualizações que aparecem fora de ordem nos resultados; ou seja, as atualizações anteriores sempre aparecerão em um conjunto de resultados antes das atualizações posteriores.

Em nosso exemplo, a Transação 2 altera uma linha, mas não confirma as alterações. A transação 1 então lê os dados não confirmados. Agora, se a Transação 2 reverter suas alterações (já lidas pela Transação 1) ou atualizar diferentes alterações no banco de dados, então a visualização dos dados pode estar errada nos registros da Transação 1.

Transação 1 Transação 2 
/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 20 */

/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
/* No commit here */

/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 21 */

ROLLBACK; /* lock-based DIRTY READ */

Mas, neste caso, não existe nenhuma linha com um id de 1 e uma idade de 21.

Leituras não repetíveis

Uma leitura não repetível ocorre quando, durante o curso de uma transação, uma linha é recuperada duas vezes e os valores dentro da linha diferem entre as leituras.

O fenômeno de leituras não repetíveis pode ocorrer em um método de controle de simultaneidade baseado em bloqueio quando os bloqueios de leitura não são adquiridos ao executar um SELECT ou quando os bloqueios adquiridos nas linhas afetadas são liberados assim que a operação SELECT é executada. No método de controle de simultaneidade multiversão , leituras não repetíveis podem ocorrer quando o requisito de que uma transação afetada por um conflito de confirmação deve ser revertida é relaxado.

Transação 1 Transação 2 
/* Query 1 */
SELECT * FROM users WHERE id = 1;

/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
COMMIT; /* in multiversion concurrency
   control, or lock-based READ COMMITTED */

/* Query 1 */
SELECT * FROM users WHERE id = 1;
COMMIT; /* lock-based REPEATABLE READ */

Neste exemplo, a Transação 2 é confirmada com sucesso, o que significa que suas alterações na linha com id 1 devem se tornar visíveis. No entanto, a Transação 1 já viu um valor diferente para a idade nessa linha. Nos níveis de isolamento SERIALIZABLE e REPEATABLE READ, o DBMS deve retornar o valor antigo para o segundo SELECT. Em READ COMMITTED e READ UNCOMMITTED, o DBMS pode retornar o valor atualizado; esta é uma leitura não repetível.

Existem duas estratégias básicas usadas para evitar leituras não repetíveis. A primeira é atrasar a execução da Transação 2 até que a Transação 1 seja confirmada ou revertida. Este método é usado quando o bloqueio é usado e produz a programação serial T1, T2 . Uma programação em série exibe um comportamento de leitura repetível .

Na outra estratégia, conforme usada no controle de simultaneidade multiversão , a Transação 2 tem permissão para confirmar primeiro, o que fornece uma melhor simultaneidade. No entanto, a Transação 1, que começou antes da Transação 2, deve continuar operando em uma versão anterior do banco de dados - um instantâneo do momento em que foi iniciada. Quando a Transação 1 eventualmente tenta confirmar, o DBMS verifica se o resultado da confirmação da Transação 1 seria equivalente à programação T1, T2 . Se for, a Transação 1 pode prosseguir. Se não puder ser visto como equivalente, no entanto, a Transação 1 deve ser revertida com uma falha de serialização.

Usando um método de controle de simultaneidade baseado em bloqueio, no modo de isolamento REPEATABLE READ, a linha com ID = 1 seria bloqueada, bloqueando a Consulta 2 até que a primeira transação fosse confirmada ou revertida. No modo READ COMMITTED, na segunda vez que a Consulta 1 foi executada, a idade teria mudado.

Sob o controle de simultaneidade multiversão, no nível de isolamento SERIALIZABLE, ambas as consultas SELECT veem um instantâneo do banco de dados obtido no início da Transação 1. Portanto, eles retornam os mesmos dados. No entanto, se a Transação 2 tentasse ATUALIZAR essa linha também, ocorreria uma falha de serialização e a Transação 1 seria forçada a reverter.

No nível de isolamento READ COMMITTED, cada consulta vê um instantâneo do banco de dados obtido no início de cada consulta. Portanto, cada um deles vê dados diferentes para a linha atualizada. Nenhuma falha de serialização é possível neste modo (porque nenhuma promessa de serialização é feita) e a Transação 1 não terá que ser repetida.

Leituras fantasmas

Uma leitura fantasma ocorre quando, no decorrer de uma transação, novas linhas são adicionadas ou removidas por outra transação aos registros que estão sendo lidos.

Isso pode ocorrer quando os bloqueios de intervalo não são adquiridos ao executar uma operação SELECT ... WHERE . A anomalia das leituras fantasmas é um caso especial de leituras não repetíveis quando a Transação 1 repete uma consulta SELECT ... WHERE variada e, entre as duas operações, a Transação 2 cria (ou seja, INSERT ) novas linhas (na tabela de destino) que atendem a WHERE cláusula.

Transação 1 Transação 2 
/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;

/* Query 2 */
INSERT INTO users(id, name, age) VALUES (3, 'Bob', 27);
COMMIT;

/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
COMMIT;

Observe que a Transação 1 executou a mesma consulta duas vezes. Se o nível mais alto de isolamento for mantido, o mesmo conjunto de linhas deve ser retornado nas duas vezes e, de fato, é isso que deve ocorrer em um banco de dados operando no nível de isolamento SQL SERIALIZABLE. No entanto, nos níveis de isolamento menores, um conjunto diferente de linhas pode ser retornado pela segunda vez.

No modo de isolamento SERIALIZABLE, a Consulta 1 resultaria no bloqueio de todos os registros com idade no intervalo de 10 a 30, portanto, a Consulta 2 seria bloqueada até que a primeira transação fosse confirmada. No modo READ REPEATABLE, a faixa não seria travada, permitindo a inserção do registro. Portanto, a segunda instrução da Consulta 1 não retornaria o mesmo resultado da primeira.

Níveis de isolamento

Das quatro propriedades ACID em um SGBD (Sistema de Gerenciamento de Banco de Dados), a propriedade de isolamento é a mais freqüentemente relaxada. Ao tentar manter o nível mais alto de isolamento, um DBMS geralmente adquire bloqueios nos dados que podem resultar em uma perda de simultaneidade ou implementa o controle de simultaneidade multiversão . Isso requer a adição de lógica para que o aplicativo funcione corretamente.

A maioria dos SGBDs oferece vários níveis de isolamento de transação , que controlam o grau de bloqueio que ocorre ao selecionar os dados. Para muitos aplicativos de banco de dados, a maioria das transações de banco de dados pode ser construída para evitar a necessidade de altos níveis de isolamento (por exemplo, nível SERIALIZABLE), reduzindo assim a sobrecarga de bloqueio para o sistema. O programador deve analisar cuidadosamente o código de acesso ao banco de dados para garantir que qualquer relaxamento de isolamento não cause bugs de software difíceis de encontrar. Por outro lado, se níveis de isolamento mais altos forem usados, a possibilidade de conflito é aumentada, o que também requer uma análise cuidadosa e técnicas de programação para evitar.

Uma vez que cada nível de isolamento é mais forte do que aqueles abaixo, em que nenhum nível de isolamento superior permite uma ação proibida por um inferior, o padrão permite que um DBMS execute uma transação em um nível de isolamento mais forte do que o solicitado (por exemplo, uma "leitura confirmada" transação pode realmente ser executada em um nível de isolamento de "leitura repetida").

Os níveis de isolamento definidos pelo padrão ANSI / ISO SQL são listados a seguir.

Serializável

Este é o nível de isolamento mais alto.

Com uma implementação de DBMS de controle de simultaneidade baseada em bloqueio , a serializabilidade exige que bloqueios de leitura e gravação (adquiridos em dados selecionados) sejam liberados no final da transação. Além disso , os bloqueios de intervalo devem ser adquiridos quando uma consulta SELECT usa uma cláusula WHERE com intervalo , especialmente para evitar o fenômeno de leituras fantasmas .

Ao usar o controle de simultaneidade não baseado em bloqueio, nenhum bloqueio é adquirido; entretanto, se o sistema detectar uma colisão de gravação entre várias transações simultâneas, apenas uma delas terá permissão para confirmar. Consulte o isolamento de instantâneo para obter mais detalhes sobre este tópico.

De: (Second Informal Review Draft) ISO / IEC 9075: 1992, Database Language SQL- 30 de julho de 1992: A execução de transações SQL concorrentes no nível de isolamento SERIALIZABLE tem garantia de ser serializável. Uma execução serializável é definida como uma execução das operações de execução simultânea de transações SQL que produzem o mesmo efeito que alguma execução serial dessas mesmas transações SQL. Uma execução serial é aquela em que cada transação SQL é executada até a conclusão antes que a próxima transação SQL comece.

Leituras repetíveis

Nesse nível de isolamento, uma implementação de DBMS de controle de simultaneidade baseada em bloqueio mantém os bloqueios de leitura e gravação (adquiridos nos dados selecionados) até o final da transação. No entanto, os bloqueios de intervalo não são gerenciados, portanto, podem ocorrer leituras fantasmas .

A distorção de gravação é possível neste nível de isolamento em alguns sistemas. A inclinação de gravação é um fenômeno em que duas gravações são permitidas na (s) mesma (s) coluna (s) em uma tabela por dois escritores diferentes (que leram anteriormente as colunas que estão atualizando), resultando na coluna com dados que são uma combinação das duas transações .

Leia comprometido

Nesse nível de isolamento, uma implementação de DBMS de controle de simultaneidade baseada em bloqueio mantém bloqueios de gravação (adquiridos nos dados selecionados) até o final da transação, mas bloqueios de leitura são liberados assim que a operação SELECT é realizada (portanto, o fenômeno de leituras não repetíveis pode ocorrer neste nível de isolamento). Como no nível anterior, os bloqueios de intervalo não são gerenciados.

Resumindo, a leitura confirmada é um nível de isolamento que garante que todos os dados lidos sejam confirmados no momento em que são lidos. Ele simplesmente restringe o leitor de ver qualquer leitura intermediária, não comprometida e 'suja'. Ele não faz nenhuma promessa de que, se a transação emitir novamente a leitura, ela encontrará os mesmos dados; os dados podem ser alterados após serem lidos.

Leia sem compromisso

Este é o nível de isolamento mais baixo. Nesse nível, leituras sujas são permitidas, portanto, uma transação pode ver alterações ainda não confirmadas feitas por outras transações.

Nível de isolamento padrão

O nível de isolamento padrão de diferentes DBMSs varia amplamente. A maioria dos bancos de dados que apresentam transações permitem que o usuário defina qualquer nível de isolamento. Alguns SGBDs também requerem sintaxe adicional ao executar uma instrução SELECT para adquirir bloqueios (por exemplo, SELECT ... FOR UPDATE para adquirir bloqueios de gravação exclusivos em linhas acessadas).

No entanto, as definições acima foram criticadas por serem ambíguas e não refletirem com precisão o isolamento fornecido por muitos bancos de dados:

Este artigo mostra uma série de pontos fracos na abordagem da anomalia para definir os níveis de isolamento. Os três fenômenos ANSI são ambíguos e, mesmo em suas interpretações mais vagas, não excluem algum comportamento anômalo ... Isso leva a alguns resultados contra-intuitivos. Em particular, os níveis de isolamento baseados em bloqueio têm características diferentes de seus equivalentes ANSI. Isso é desconcertante porque os sistemas de banco de dados comerciais geralmente usam implementações de bloqueio. Além disso, os fenômenos ANSI não distinguem entre vários tipos de comportamento de nível de isolamento que são populares em sistemas comerciais.

Existem também outras críticas sobre a definição de isolamento ANSI SQL, na medida em que incentiva os implementadores a fazer "coisas ruins":

... depende de maneiras sutis na suposição de que um esquema de bloqueio é usado para controle de simultaneidade, em oposição a um esquema de simultaneidade otimista ou de várias versões. Isso implica que a semântica proposta está mal definida .

Níveis de isolamento, fenômenos de leitura e bloqueios

Níveis de isolamento vs fenômenos de leitura

'+' - possível
'-' - não é possível


             Leia fenômenos


Nível de isolamento

 Leituras sujas Atualizações perdidas Leituras não repetíveis Fantasmas
Leia não comprometido + + + +
Leia Comprometido - + + +
Leitura repetível - - - +
Serializável - - - -

Anomaly Serializable não é o mesmo que Serializable. Ou seja, é necessário, mas não suficiente, que uma tabela serializável esteja livre de todos os três tipos de fenômenos.

Veja também

Referências

links externos