# Comparar os níveis de isolamento do Babelfish e do SQL Server
<a name="babelfish-transaction.examples"></a>

 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);
```

**Topics**
+ [Comparação entre os níveis de isolamento `READ UNCOMMITTED` do Babelfish e `READ UNCOMMITTED` do SQL Server](#babelfish-transaction.examples.unc)
+ [Comparação entre os níveis de isolamento `READ COMMITTED` do Babelfish e `READ COMMITTED` do SQL Server](#babelfish-transaction.examples.com)
+ [Comparação entre os níveis de isolamento `READ COMMITTED` do Babelfish e `READ COMMITTED SNAPSHOT` do SQL Server](#babelfish-transaction.examples.snapshot)
+ [Comparação entre os níveis de isolamento `REPEATABLE READ` do Babelfish e `REPEATABLE READ` do SQL Server](#babelfish-transaction.examples.read)
+ [Comparação entre os níveis de isolamento `SERIALIZABLE` do Babelfish e `SERIALIZABLE` do SQL Server](#babelfish-transaction.examples.serialize)

## Comparação entre os níveis de isolamento `READ UNCOMMITTED` do Babelfish e `READ UNCOMMITTED` do SQL Server
<a name="babelfish-transaction.examples.unc"></a>

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 name="babelfish-transaction.examples.com"></a>

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 name="babelfish-transaction.examples.snapshot"></a>

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 name="babelfish-transaction.examples.read"></a>

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 name="babelfish-transaction.examples.serialize"></a>

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. |