Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Confronto tra i livelli di isolamento di Babelfish e SQL Server
<a name="babelfish-transaction.examples"></a>

 Di seguito sono riportati alcuni esempi delle differenze nel modo in cui SQL Server e Babelfish implementano i livelli di isolamento ANSI. 

**Nota**  
I livelli di isolamento `REPEATABLE READ` e `SNAPSHOT` sono gli stessi in Babelfish.
I livelli di isolamento `READ UNCOMMITTED` e `READ COMMITTED` sono gli stessi in Babelfish.

L’esempio seguente mostra come creare la tabella di base per tutti gli esempi citati di seguito:

```
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**
+ [`READ UNCOMMITTED` di Babelfish rispetto al livello di isolamento `READ UNCOMMITTED` di SQL Server](#babelfish-transaction.examples.unc)
+ [`READ COMMITTED` di Babelfish rispetto al livello di isolamento `READ COMMITTED` di SQL Server](#babelfish-transaction.examples.com)
+ [`READ COMMITTED` di Babelfish rispetto al livello di isolamento `READ COMMITTED SNAPSHOT` di SQL Server](#babelfish-transaction.examples.snapshot)
+ [`REPEATABLE READ` di Babelfish rispetto al livello di isolamento `REPEATABLE READ` di SQL Server](#babelfish-transaction.examples.read)
+ [`SERIALIZABLE` di Babelfish rispetto al livello di isolamento `SERIALIZABLE` di SQL Server](#babelfish-transaction.examples.serialize)

## `READ UNCOMMITTED` di Babelfish rispetto al livello di isolamento `READ UNCOMMITTED` di SQL Server
<a name="babelfish-transaction.examples.unc"></a>

La tabella seguente fornisce dettagli sulle letture dirty quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `READ UNCOMMITTED` in SQL Server rispetto all’implementazione Babelfish.


| Transazione 1 | Transazione 2 | `READ UNCOMMITTED` di SQL Server | `READ UNCOMMITTED` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;` | `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;` | Nessuna | Nessuno | 
| Inattivo in transazione | `UPDATE employee SET age=0;` | Aggiornamento completato. | Aggiornamento completato. | 
| Inattivo in transazione | `INSERT INTO employee VALUES (4, 'D', 40);` | Inserimento completato. | Inserimento completato. | 
| `SELECT * FROM employee;` | Inattivo in transazione | La transazione 1 può visualizzare le modifiche di cui non è stato eseguito il commit dalla transazione 2. | Come `READ COMMITTED` in Babelfish. Le modifiche di cui non è stato eseguito il commit dalla transazione 2 non sono visibili nella transazione 1.  | 
| Inattivo in transazione | `COMMIT` | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Vede le modifiche di cui è stato eseguito il commit dalla transazione 2. | Vede le modifiche di cui è stato eseguito il commit dalla transazione 2. | 

## `READ COMMITTED` di Babelfish rispetto al livello di isolamento `READ COMMITTED` di SQL Server
<a name="babelfish-transaction.examples.com"></a>

La tabella seguente fornisce dettagli sul comportamento del blocco di lettura-scrittura quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `READ COMMITTED` in SQL Server rispetto all’implementazione Babelfish.


| Transazione 1 | Transazione 2 | `READ COMMITTED` di SQL Server | `READ COMMITTED` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;` | `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `UPDATE employee SET age=100 WHERE id = 1;` | Aggiornamento completato. | Aggiornamento completato. | 
| `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);` | Inattivo in transazione | Passaggio bloccato fino al commit della transazione 2. | Le modifiche alla transazione 2 non sono ancora visibili. Aggiorna la riga con id=3. | 
| Inattivo in transazione | `COMMIT` | La transazione 2 viene correttamente sottoposta al commit. La transazione 1 è ora sbloccata e vede l’aggiornamento dalla transazione 2. | La transazione 2 viene correttamente sottoposta al commit.  | 
| `SELECT * FROM employee;` | Inattivo in transazione | La transazione 1 aggiorna la riga con id = 1. | La transazione 1 aggiorna la riga con id = 3. | 

## `READ COMMITTED` di Babelfish rispetto al livello di isolamento `READ COMMITTED SNAPSHOT` di SQL Server
<a name="babelfish-transaction.examples.snapshot"></a>

La tabella seguente fornisce dettagli sul comportamento del blocco delle righe appena inserite quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `READ COMMITTED SNAPSHOT` in SQL Server rispetto all’implementazione `READ COMMITTED` di Babelfish.


| Transazione 1 | Transazione 2 | `READ COMMITTED SNAPSHOT` di SQL Server | `READ COMMITTED` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;` | `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;` | Nessuna | Nessuno | 
| `INSERT INTO employee VALUES (4, 'D', 40);` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `UPDATE employee SET age = 99;` | Il passaggio è bloccato fino al commit della transazione 1. La riga inserita è bloccata dalla transazione 1. | Sono state aggiornate tre righe. La riga appena inserita non è ancora visibile. | 
| `COMMIT` | Inattivo in transazione | Commit completato. La transazione 2 è ora sbloccata. | Commit completato. | 
| Inattivo in transazione | `SELECT * FROM employee;` | Tutte e 4 le righe hanno age=99. | La riga con id = 4 ha il valore di age 40 perché non era visibile alla transazione 2 durante la query di aggiornamento. Le altre righe vengono aggiornate ad age=99.  | 

## `REPEATABLE READ` di Babelfish rispetto al livello di isolamento `REPEATABLE READ` di SQL Server
<a name="babelfish-transaction.examples.read"></a>

La tabella seguente fornisce dettagli sul comportamento del blocco di lettura-scrittura quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `REPEATABLE READ` in SQL Server rispetto all’implementazione `REPEATABLE READ` di Babelfish.


| Transazione 1 | Transazione 2 | `REPEATABLE READ` di SQL Server | `REPEATABLE READ` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| `UPDATE employee SET name='A_TXN1' WHERE id=1;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee WHERE id != 1;` | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee;` | La transazione 2 è bloccata fino al commit della transazione 1. | La transazione 2 procede normalmente.  | 
| `COMMIT` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee;` | L’aggiornamento dalla transazione 1 è visibile. | L’aggiornamento dalla transazione 1 non è visibile. | 
| `COMMIT` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee;` | Vede l’aggiornamento dalla transazione 1. | Vede l’aggiornamento dalla transazione 1. | 

La tabella seguente fornisce dettagli sul comportamento del blocco di scrittura-scrittura quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `REPEATABLE READ` in SQL Server rispetto all’implementazione `REPEATABLE READ` di Babelfish.


| Transazione 1 | Transazione 2 | `REPEATABLE READ` di SQL Server | `REPEATABLE READ` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | Nessuna | Nessuno | 
| `UPDATE employee SET name='A_TXN1' WHERE id=1;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `UPDATE employee SET name='A_TXN2' WHERE id=1;` | La transazione 2 è bloccata. | La transazione 2 è bloccata. | 
| `COMMIT` | Inattivo in transazione | Il commit è stato completato e la transazione 2 è stata sbloccata. | Il commit è stato completato e la transazione 2 non riesce con l’errore indicante la mancata serializzazione dell’accesso a causa di un aggiornamento simultaneo. | 
| Inattivo in transazione | `COMMIT` | Commit completato. | La transazione 2 è già stata interrotta. | 
| Inattivo in transazione | `SELECT * FROM employee;` | La riga con id=1 ha name='A\_TX2'. | La riga con id=1 ha name='A\_TX1'. | 

La tabella seguente fornisce dettagli sul comportamento delle letture fantasma quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `REPEATABLE READ` in SQL Server rispetto all’implementazione `REPEATABLE READ` di Babelfish.


| Transazione 1 | Transazione 2 | `REPEATABLE READ` di SQL Server | `REPEATABLE READ` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `INSERT INTO employee VALUES (4, 'NewRowName', 20);` | La transazione 2 procede senza blocchi. | La transazione 2 procede senza blocchi. | 
| Inattivo in transazione | `SELECT * FROM employee;` | La riga appena inserita è visibile. | La riga appena inserita è visibile. | 
| Inattivo in transazione | `COMMIT` | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | La nuova riga inserita dalla transazione 2 è visibile. | La nuova riga inserita dalla transazione 2 non è visibile. | 
| `COMMIT` | Inattivo in transazione | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | La riga appena inserita è visibile. | La riga appena inserita è visibile. | 

La tabella seguente fornisce dettagli sull’esecuzione di transazioni simultanee e sui diversi risultati finali quando si utilizza il livello di isolamento `REPEATABLE READ` in SQL Server rispetto all’implementazione `REPEATABLE READ` di Babelfish.


| Transazione 1 | Transazione 2 | `REPEATABLE READ` di SQL Server | `REPEATABLE READ` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | Nessuna | Nessuno | 
| `UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);` | Inattivo in transazione | La transazione 1 aggiorna la riga con id 1. | La transazione 1 aggiorna la riga con id 1. | 
| Inattivo in transazione | `UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);` | La transazione 2 è bloccata perché l’istruzione SELECT tenta di leggere le righe bloccate dalla query UPDATE nella transazione 1. | La transazione 2 procede senza blocchi perché la lettura non viene mai bloccata, l’istruzione SELECT viene eseguita e la riga con id = 3 viene aggiornata perché le modifiche alla transazione 1 non sono ancora visibili. | 
| Inattivo in transazione | `SELECT * FROM employee;` | Questo passaggio viene eseguito dopo il commit della transazione 1. La riga con id = 1 viene aggiornata dalla transazione 2 nel passaggio precedente ed è visibile. | La riga con id = 3 viene aggiornata dalla transazione 2. | 
| `COMMIT` | Inattivo in transazione | La transazione 2 è ora sbloccata. | Commit completato. | 
| Inattivo in transazione | `COMMIT` | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Entrambe le transazioni eseguono l’aggiornamento sulla riga con id = 1. | Le diverse righe vengono aggiornate dalle transazioni 1 e 2. | 

## `SERIALIZABLE` di Babelfish rispetto al livello di isolamento `SERIALIZABLE` di SQL Server
<a name="babelfish-transaction.examples.serialize"></a>

La tabella seguente fornisce dettagli sui blocchi di intervallo quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `SERIALIZABLE` in SQL Server rispetto all’implementazione `SERIALIZABLE` di Babelfish.


| Transazione 1 | Transazione 2 | `SERIALIZABLE` di SQL Server | `SERIALIZABLE` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `INSERT INTO employee VALUES (4, 'D', 35);` | La transazione 2 è bloccata fino al commit della transazione 1. | La transazione 2 procede senza blocchi. | 
| Inattivo in transazione | `SELECT * FROM employee;` | Nessuno | Nessuno | 
| `COMMIT` | Inattivo in transazione | La transazione 1 viene correttamente sottoposta al commit. La transazione 2 è ora sbloccata. | La transazione 1 viene correttamente sottoposta al commit.  | 
| Inattivo in transazione | `COMMIT` | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | La riga appena inserita è visibile. | La riga appena inserita è visibile. | 

La tabella seguente fornisce dettagli sull’esecuzione di transazioni simultanee e sui diversi risultati finali quando si utilizza il livello di isolamento `SERIALIZABLE` in SQL Server rispetto all’implementazione `SERIALIZABLE` di Babelfish.


| Transazione 1 | Transazione 2 | `SERIALIZABLE` di SQL Server | `SERIALIZABLE` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | Nessuna | Nessuno | 
| Inattivo in transazione | `INSERT INTO employee VALUES (4, 'D', 40);` | Nessuno | Nessuno | 
| `UPDATE employee SET age =99 WHERE id = 4;` | Inattivo in transazione | La transazione 1 è bloccata fino al commit della transazione 2. | La transazione 1 procede senza blocchi. | 
| Inattivo in transazione | `COMMIT` | La transazione 2 viene correttamente sottoposta al commit. La transazione 1 è ora sbloccata. | La transazione 2 viene correttamente sottoposta al commit. | 
| `COMMIT` | Inattivo in transazione | Nessuno | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | La riga appena inserita è visibile con valore age = 99. | La riga appena inserita è visibile con valore age = 40. | 

La tabella seguente fornisce i dettagli relativi all’azione `INSERT` in una tabella con vincolo univoco. Mostra i risultati osservati quando si utilizza il livello di isolamento `SERIALIZABLE` in SQL Server rispetto all’implementazione `SERIALIZABLE` di Babelfish.


| Transazione 1 | Transazione 2 | `SERIALIZABLE` di SQL Server | `SERIALIZABLE` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | Nessuna | Nessuno | 
| Inattivo in transazione | `INSERT INTO employee VALUES (4, 'D', 40);` | Nessuno | Nessuno | 
| `INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);` | Inattivo in transazione | La transazione 1 è bloccata fino al commit della transazione 2. | La transazione 1 è bloccata fino al commit della transazione 2. | 
| Inattivo in transazione | `COMMIT` | La transazione 2 viene correttamente sottoposta al commit. La transazione 1 è ora sbloccata. | La transazione 2 viene correttamente sottoposta al commit. La transazione 1 viene interrotta con errore di valore di chiave duplicato che viola un vincolo univoco. | 
| `COMMIT` | Inattivo in transazione | La transazione 1 viene correttamente sottoposta al commit. | Il commit della transazione 1 ha esito negativo e non è stato possibile serializzare l’accesso a causa di dipendenze di lettura o scrittura tra le transazioni. | 
| `SELECT * FROM employee;` | Inattivo in transazione | Viene inserita la riga (5, 'E', 50). | Esistono solo 4 righe. | 

In Babelfish, le transazioni simultanee eseguite con livello di isolamento serializzabile restituiscono un errore di anomalia di serializzazione se l’esecuzione di queste transazioni non è coerente con tutte le possibili esecuzioni seriali (una alla volta) di tali transazioni.

Le tabelle seguenti forniscono dettagli sull’anomalia di serializzazione quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di isolamento `SERIALIZABLE` in SQL Server rispetto all’implementazione `SERIALIZABLE` di Babelfish.


| Transazione 1 | Transazione 2 | `SERIALIZABLE` di SQL Server | `SERIALIZABLE` di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| `UPDATE employee SET age=5 WHERE age=10;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee;` | La transazione 2 è bloccata fino al commit della transazione 1. | La transazione 2 procede senza blocchi. | 
| Inattivo in transazione | `UPDATE employee SET age=35 WHERE age=30;` | Nessuno | Nessuno | 
| `COMMIT` | Inattivo in transazione | La transazione 1 viene correttamente sottoposta al commit. | La transazione 1 viene sottoposta al commit per prima ed è in grado di completarlo con successo. | 
| Inattivo in transazione | `COMMIT` | La transazione 2 viene correttamente sottoposta al commit. | Il commit della transazione 2 non riesce a causa di un errore di serializzazione, l’intera transazione è stata sottoposta a rollback. Riprova la transazione 2. | 
| `SELECT * FROM employee;` | Inattivo in transazione | Le modifiche di entrambe le transazioni sono visibili. | La transazione 2 è stata sottoposta a rollback. Vengono visualizzate solo le modifiche alla transazione 1. | 

In Babelfish, l’anomalia di serializzazione si verifica solo se tutte le transazioni simultanee vengono eseguite a livello di isolamento `SERIALIZABLE`. Nella tabella seguente è riportato l’esempio precedente con la transazione 2 impostata sul livello di isolamento `REPEATABLE READ`.


| Transazione 1 | Transazione 2 | Livelli di isolamento di SQL Server | Livelli di isolamento di Babelfish | 
| --- | --- | --- | --- | 
| `BEGIN TRANSACTION` | `BEGIN TRANSACTION` | Nessuno | Nessuna | 
| `SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;` | `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;` | Nessuna | Nessuno | 
| `SELECT * FROM employee;` | Inattivo in transazione | Nessuno | Nessuno | 
| `UPDATE employee SET age=5 WHERE age=10;` | Inattivo in transazione | Nessuno | Nessuno | 
| Inattivo in transazione | `SELECT * FROM employee;` | La transazione 2 è bloccata fino al commit della transazione 1. | La transazione 2 procede senza blocchi. | 
| Inattivo in transazione | `UPDATE employee SET age=35 WHERE age=30;` | Nessuno | Nessuno | 
| `COMMIT` | Inattivo in transazione | La transazione 1 viene correttamente sottoposta al commit. | La transazione 1 viene correttamente sottoposta al commit. | 
| Inattivo in transazione | `COMMIT` | La transazione 2 viene correttamente sottoposta al commit. | La transazione 2 viene correttamente sottoposta al commit. | 
| `SELECT * FROM employee;` | Inattivo in transazione | Le modifiche di entrambe le transazioni sono visibili. | Le modifiche di entrambe le transazioni sono visibili. |