Comparação entre os níveis de isolamento READ UNCOMMITTED do Babelfish e READ UNCOMMITTED do SQL Server Comparação entre os níveis de isolamento READ COMMITTED do Babelfish e READ COMMITTED do SQL Server Comparação entre os níveis de isolamento READ COMMITTED do Babelfish e READ COMMITTED SNAPSHOT do SQL Server Comparação entre os níveis de isolamento REPEATABLE READ do Babelfish e REPEATABLE READ do SQL Server Comparação entre os níveis de isolamento SERIALIZABLE do Babelfish e SERIALIZABLE do SQL Server

Comparar os níveis de isolamento do Babelfish e do SQL Server

Veja alguns exemplos das nuances na maneira como o SQL Server e o Babelfish implementam os níveis de isolamento ANSI.

nota

Os níveis de isolamento REPEATABLE READ e SNAPSHOT são os mesmos no Babelfish.
Os níveis de isolamento READ UNCOMMITTED e READ COMMITTED são os mesmos no Babelfish.

O exemplo a seguir mostra como criar a tabela base para todos os exemplos mencionados abaixo:


CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);

Tópicos

Comparação entre os níveis de isolamento READ UNCOMMITTED do Babelfish e READ UNCOMMITTED do SQL Server
Comparação entre os níveis de isolamento READ COMMITTED do Babelfish e READ COMMITTED do SQL Server
Comparação entre os níveis de isolamento READ COMMITTED do Babelfish e READ COMMITTED SNAPSHOT do SQL Server
Comparação entre os níveis de isolamento REPEATABLE READ do Babelfish e REPEATABLE READ do SQL Server
Comparação entre os níveis de isolamento SERIALIZABLE do Babelfish e SERIALIZABLE do SQL Server

Comparação entre os níveis de isolamento `READ UNCOMMITTED` do Babelfish e `READ UNCOMMITTED` do SQL Server

A tabela a seguir fornece detalhes sobre as leituras sujas quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento READ UNCOMMITTED no SQL Server em comparação com a implementação do Babelfish.

Transação 1	Transação 2	`READ UNCOMMITTED` do SQL Server	`READ UNCOMMITTED` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	Nenhum	Nenhum
Ocioso na transação	`UPDATE employee SET age=0;`	Atualização bem-sucedida.	Atualização bem-sucedida.
Ocioso na transação	`INSERT INTO employee VALUES (4, 'D', 40);`	Inserção bem-sucedida.	Inserção bem-sucedida.
`SELECT * FROM employee;`	Ocioso na transação	A transação 1 pode ver as alterações não confirmadas da transação 2.	O mesmo que `READ COMMITTED` no Babelfish. As alterações não confirmadas da transação 2 não são visíveis na transação 1.
Ocioso na transação	`COMMIT`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Vê as alterações confirmadas pela transação 2.	Vê as alterações confirmadas pela transação 2.

Comparação entre os níveis de isolamento `READ COMMITTED` do Babelfish e `READ COMMITTED` do SQL Server

A tabela a seguir fornece detalhes sobre o comportamento do bloqueio das leituras e das gravações quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento READ COMMITTED no SQL Server em comparação com a implementação do Babelfish.

Transação 1	Transação 2	`READ COMMITTED` do SQL Server	`READ COMMITTED` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`UPDATE employee SET age=100 WHERE id = 1;`	Atualização bem-sucedida.	Atualização bem-sucedida.
`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	Ocioso na transação	Etapa bloqueada até que a transação 2 seja confirmada.	As alterações da transação 2 ainda não estão visíveis. Updates row with id=3.
Ocioso na transação	`COMMIT`	A transação 2 foi confirmada com êxito. A transação 1 agora está desbloqueada e vê a atualização da transação 2.	A transação 2 foi confirmada com êxito.
`SELECT * FROM employee;`	Ocioso na transação	A transação 1 atualiza a linha com id = 1.	A transação 1 atualiza a linha com id = 3.

Comparação entre os níveis de isolamento `READ COMMITTED` do Babelfish e `READ COMMITTED SNAPSHOT` do SQL Server

A tabela a seguir fornece detalhes sobre o comportamento do bloqueio das linhas recém-inseridas quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento READ COMMITTED SNAPSHOT no SQL Server em comparação com a implementação do READ COMMITTED no Babelfish.

Transação 1	Transação 2	`READ COMMITTED SNAPSHOT` do SQL Server	`READ COMMITTED` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Nenhum	Nenhum
`INSERT INTO employee VALUES (4, 'D', 40);`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`UPDATE employee SET age = 99;`	Etapa bloqueada até que a Transação 1 seja confirmada. A linha inserida está bloqueada pela transação 1.	Três linhas atualizadas. A linha recém-inserida ainda não está visível.
`COMMIT`	Ocioso na transação	Confirmação bem-sucedida. A transação 2 agora está desbloqueada.	Confirmação bem-sucedida.
Ocioso na transação	`SELECT * FROM employee;`	Todas as quatro linhas têm idade = 99.	A linha com id = 4 tem o valor de idade 40, pois não estava visível para a transação 2 durante a consulta de atualização. Outras linhas são atualizadas para idade = 99.

Comparação entre os níveis de isolamento `REPEATABLE READ` do Babelfish e `REPEATABLE READ` do SQL Server

A tabela a seguir fornece detalhes sobre o comportamento do bloqueio das leituras e das gravações quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento REPEATABLE READ no SQL Server em comparação com a implementação do REPEATABLE READ no Babelfish.

Transação 1	Transação 2	`REPEATABLE READ` do SQL Server	`REPEATABLE READ` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee WHERE id != 1;`	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee;`	A transação 2 permanece bloqueada até que a transação 1 seja confirmada.	A transação 2 prossegue normalmente.
`COMMIT`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee;`	A atualização da transação 1 está visível.	A atualização da transação 1 não está visível.
`COMMIT`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee;`	Vê a atualização da transação 1.	Vê a atualização da transação 1.

A tabela a seguir fornece detalhes sobre o comportamento do bloqueio de gravação-gravação quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento REPEATABLE READ no SQL Server em comparação com a implementação do REPEATABLE READ no Babelfish.

Transação 1	Transação 2	`REPEATABLE READ` do SQL Server	`REPEATABLE READ` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Nenhum	Nenhum
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`UPDATE employee SET name='A_TXN2' WHERE id=1;`	Transação 2 bloqueada.	Transação 2 bloqueada.
`COMMIT`	Ocioso na transação	A confirmação foi bem-sucedida e a transação 2 foi desbloqueada.	A confirmação foi bem-sucedida e a transação 2 falha com erro, não foi possível serializar o acesso devido à atualização simultânea.
Ocioso na transação	`COMMIT`	Confirmação bem-sucedida.	A transação 2 já foi cancelada.
Ocioso na transação	`SELECT * FROM employee;`	Row with id=1 has name='A_TX2'.	Row with id=1 has name='A_TX1'.

A tabela a seguir fornece detalhes sobre as leituras fantasmas quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento REPEATABLE READ no SQL Server em comparação com a implementação do REPEATABLE READ no Babelfish.

Transação 1	Transação 2	`REPEATABLE READ` do SQL Server	`REPEATABLE READ` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`INSERT INTO employee VALUES (4, 'NewRowName', 20);`	A transação 2 prossegue sem nenhum bloqueio.	A transação 2 prossegue sem nenhum bloqueio.
Ocioso na transação	`SELECT * FROM employee;`	A linha recém-inserida está visível.	A linha recém-inserida está visível.
Ocioso na transação	`COMMIT`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	A nova linha inserida pela transação 2 está visível.	A nova linha inserida pela transação 2 não está visível.
`COMMIT`	Ocioso na transação	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	A linha recém-inserida está visível.	A linha recém-inserida está visível.

A tabela a seguir fornece detalhes de quando as transações simultâneas são executadas e os diferentes resultados finais ao usar o nível de isolamento REPEATABLE READ no SQL Server em comparação com a implementação do REPEATABLE READ do Babelfish.

Transação 1	Transação 2	`REPEATABLE READ` do SQL Server	`REPEATABLE READ` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Nenhum	Nenhum
`UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`	Ocioso na transação	A transação 1 atualiza a linha com id 1.	A transação 1 atualiza a linha com id 1.
Ocioso na transação	`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	A transação 2 está bloqueada porque a declaração SELECT tenta ler as linhas bloqueadas pela consulta UPDATE na transação 1.	A transação 2 prossegue sem nenhum bloqueio, pois a leitura nunca é bloqueada, a declaração SELECT é executada e, finalmente, a linha com id = 3 é atualizada, pois as alterações da transação 1 ainda não estão visíveis.
Ocioso na transação	`SELECT * FROM employee;`	Essa etapa é executada após a confirmação da transação 1. A linha com id = 1 é atualizada pela transação 2 na etapa anterior e está visível aqui.	A linha com o id = 3 é atualizada pela Transação 2.
`COMMIT`	Ocioso na transação	A transação 2 agora está desbloqueada.	Confirmação bem-sucedida.
Ocioso na transação	`COMMIT`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	As duas transações executam a atualização na linha com id = 1.	Linhas diferentes são atualizadas pelas transações 1 e 2.

Comparação entre os níveis de isolamento `SERIALIZABLE` do Babelfish e `SERIALIZABLE` do SQL Server

A tabela a seguir fornece detalhes sobre os bloqueios de alcance quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento SERIALIZABLE no SQL Server em comparação com a implementação do SERIALIZABLE no Babelfish.

Transação 1	Transação 2	`SERIALIZABLE` do SQL Server	`SERIALIZABLE` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`INSERT INTO employee VALUES (4, 'D', 35);`	A transação 2 permanece bloqueada até que a transação 1 seja confirmada.	A transação 2 prossegue sem nenhum bloqueio.
Ocioso na transação	`SELECT * FROM employee;`	Nenhum	Nenhum
`COMMIT`	Ocioso na transação	A transação 1 foi confirmada com êxito. A transação 2 agora está desbloqueada.	A transação 1 foi confirmada com êxito.
Ocioso na transação	`COMMIT`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	A linha recém-inserida está visível.	A linha recém-inserida está visível.

A tabela a seguir fornece detalhes de quando as transações simultâneas são executadas e os diferentes resultados finais ao usar o nível de isolamento SERIALIZABLE no SQL Server em comparação com a implementação do SERIALIZABLE do Babelfish.

Transação 1	Transação 2	`SERIALIZABLE` do SQL Server	`SERIALIZABLE` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Nenhum	Nenhum
Ocioso na transação	`INSERT INTO employee VALUES (4, 'D', 40);`	Nenhum	Nenhum
`UPDATE employee SET age =99 WHERE id = 4;`	Ocioso na transação	A transação 1 permanece bloqueada até que a transação 2 seja confirmada.	A transação 1 prossegue sem nenhum bloqueio.
Ocioso na transação	`COMMIT`	A transação 2 foi confirmada com êxito. A transação 1 agora está desbloqueada.	A transação 2 foi confirmada com êxito.
`COMMIT`	Ocioso na transação	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	A linha recém-inserida é visível com valor de idade = 99.	A linha recém-inserida é visível com valor de idade = 40.

A tabela a seguir fornece detalhes quando você aplica INSERT em uma tabela com restrição exclusiva. Ela mostra os resultados observados ao usar o nível de isolamento SERIALIZABLE no SQL Server em comparação com a implementação do SERIALIZABLE no Babelfish.

Transação 1	Transação 2	`SERIALIZABLE` do SQL Server	`SERIALIZABLE` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Nenhum	Nenhum
Ocioso na transação	`INSERT INTO employee VALUES (4, 'D', 40);`	Nenhum	Nenhum
`INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);`	Ocioso na transação	A transação 1 permanece bloqueada até que a transação 2 seja confirmada.	A transação 1 permanece bloqueada até que a transação 2 seja confirmada.
Ocioso na transação	`COMMIT`	A transação 2 foi confirmada com êxito. A transação 1 agora está desbloqueada.	A transação 2 foi confirmada com êxito. A transação 1 cancelada com erro de valor de chave duplicado viola a restrição exclusiva.
`COMMIT`	Ocioso na transação	A transação 1 foi confirmada com êxito.	As confirmações da transação 1 falham, pois não foi possível serializar o acesso devido às dependências de leitura ou de gravação entre as transações.
`SELECT * FROM employee;`	Ocioso na transação	row (5, 'E', 50) is inserted.	Existem apenas quatro linhas.

No Babelfish, transações simultâneas executadas com o nível de isolamento serializável falharão com erro de anomalia de serialização se a execução dessas transações for inconsistente com todas as possíveis execuções seriais (uma por vez) dessas transações.

As tabelas a seguir fornecem detalhes sobre a anomalia de serialização quando transações simultâneas são realizadas. Ela mostra os resultados observados ao usar o nível de isolamento SERIALIZABLE no SQL Server em comparação com a implementação do SERIALIZABLE no Babelfish.

Transação 1	Transação 2	`SERIALIZABLE` do SQL Server	`SERIALIZABLE` do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
`UPDATE employee SET age=5 WHERE age=10;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee;`	A transação 2 permanece bloqueada até que a transação 1 seja confirmada.	A transação 2 prossegue sem nenhum bloqueio.
Ocioso na transação	`UPDATE employee SET age=35 WHERE age=30;`	Nenhum	Nenhum
`COMMIT`	Ocioso na transação	A transação 1 foi confirmada com êxito.	A transação 1 é confirmada primeiro e pode ser confirmada com êxito.
Ocioso na transação	`COMMIT`	A transação 2 foi confirmada com êxito.	A confirmação da transação 2 falha com erro de serialização, toda a transação foi revertida. Repita a transação 2.
`SELECT * FROM employee;`	Ocioso na transação	As alterações das duas transações estão visíveis.	A transação 2 foi revertida. Somente as alterações da transação 1 são observadas.

No Babelfish, a anomalia de serialização só será possível se todas as transações simultâneas estiverem sendo executadas no nível de isolamento SERIALIZABLE. Na tabela a seguir, vamos pensar no exemplo acima, mas definir a transação 2 como nível de isolamento REPEATABLE READ.

Transação 1	Transação 2	Níveis de isolamento do SQL Server	Níveis de isolamento do Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Nenhum	Nenhum
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Nenhum	Nenhum
`SELECT * FROM employee;`	Ocioso na transação	Nenhum	Nenhum
`UPDATE employee SET age=5 WHERE age=10;`	Ocioso na transação	Nenhum	Nenhum
Ocioso na transação	`SELECT * FROM employee;`	A transação 2 permanece bloqueada até que a transação 1 seja confirmada.	A transação 2 prossegue sem nenhum bloqueio.
Ocioso na transação	`UPDATE employee SET age=35 WHERE age=30;`	Nenhum	Nenhum
`COMMIT`	Ocioso na transação	A transação 1 foi confirmada com êxito.	A transação 1 foi confirmada com êxito.
Ocioso na transação	`COMMIT`	A transação 2 foi confirmada com êxito.	A transação 2 foi confirmada com êxito.
`SELECT * FROM employee;`	Ocioso na transação	As alterações das duas transações estão visíveis.	As alterações das duas transações estão visíveis.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Níveis de isolamento de transações no Babelfish

Usar recursos do Babelfish com implementação limitada