READ UNCOMMITTED di Babelfish rispetto al livello di isolamento READ UNCOMMITTED di SQL Server READ COMMITTED di Babelfish rispetto al livello di isolamento READ COMMITTED di SQL Server READ COMMITTED di Babelfish rispetto al livello di isolamento READ COMMITTED SNAPSHOT di SQL Server REPEATABLE READ di Babelfish rispetto al livello di isolamento REPEATABLE READ di SQL Server SERIALIZABLE di Babelfish rispetto al livello di isolamento SERIALIZABLE di SQL Server

Confronto tra i livelli di isolamento di Babelfish e SQL Server

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

Argomenti

READ UNCOMMITTED di Babelfish rispetto al livello di isolamento READ UNCOMMITTED di SQL Server
READ COMMITTED di Babelfish rispetto al livello di isolamento READ COMMITTED di SQL Server
READ COMMITTED di Babelfish rispetto al livello di isolamento READ COMMITTED SNAPSHOT di SQL Server
REPEATABLE READ di Babelfish rispetto al livello di isolamento REPEATABLE READ di SQL Server
SERIALIZABLE di Babelfish rispetto al livello di isolamento SERIALIZABLE di SQL Server

`READ UNCOMMITTED` di Babelfish rispetto al livello di isolamento `READ UNCOMMITTED` di SQL Server

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

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

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

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

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.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Livelli di isolamento della transazione in Babelfish

Utilizzo di funzionalità Babelfish con implementazione limitata