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

Confronto tra i livelli di isolamento di Babelfish e SQL Server

Di seguito sono riportati alcuni esempi sulle sfumature del modo in cui SQL Server e Babelfish implementano i livelli di isolamento. ANSI

Nota

I livelli di isolamento SNAPSHOT sono REPEATABLE READ gli stessi in Babelfish.
Il livello di READ UNCOMMITTED isolamento è lo stesso in Babelfish. READ COMMITTED

L'esempio seguente mostra come creare la tabella di base per tutti gli esempi menzionati 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

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

Babelfish `READ UNCOMMITTED` rispetto al livello di isolamento SQL del server `READ UNCOMMITTED`

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

Transazione 1	Transazione 2	SQLServer `READ UNCOMMITTED`	Babelfish `READ UNCOMMITTED`
`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 riuscito.	Aggiornamento riuscito.
Inattivo in transazione	`INSERT INTO employee VALUES (4, 'D', 40);`	Inserimento riuscito.	Inserimento riuscito.
`SELECT * FROM employee;`	Inattivo in transazione	La transazione 1 può visualizzare modifiche non confermate rispetto alla transazione 2.	Come `READ COMMITTED` in Babelfish. Le modifiche non confermate dalla transazione 2 non sono visibili nella transazione 1.
Inattivo in transazione	`COMMIT`	Nessuno	Nessuno
`SELECT * FROM employee;`	Inattivo in transazione	Visualizza le modifiche apportate dalla transazione 2.	Visualizza le modifiche apportate dalla transazione 2.

Babelfish `READ COMMITTED` rispetto al livello di isolamento SQL del server `READ COMMITTED`

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

Transazione 1	Transazione 2	SQLServer `READ COMMITTED`	Babelfish `READ COMMITTED`
`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 riuscito.	Aggiornamento riuscito.
`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	Inattivo in transazione	Fase bloccata fino al completamento 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 eseguita correttamente. La transazione 1 è ora sbloccata e vede l'aggiornamento della transazione 2.	La transazione 2 viene eseguita correttamente.
`SELECT * FROM employee;`	Inattivo in transazione	La transazione 1 aggiorna la riga con id = 1.	La transazione 1 aggiorna la riga con id = 3.

Babelfish `READ COMMITTED` rispetto al livello di isolamento SQL del server `READ COMMITTED SNAPSHOT`

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

Transazione 1	Transazione 2	SQLServer `READ COMMITTED SNAPSHOT`	Babelfish `READ COMMITTED`
`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 completamento della transazione 1. La riga inserita è bloccata dalla transazione 1.	Tre righe aggiornate. La riga appena inserita non è ancora visibile.
`COMMIT`	Inattivo in transazione	Impegno riuscito. La transazione 2 è ora sbloccata.	Impegno riuscito.
Inattivo in transazione	`SELECT * FROM employee;`	Tutte e 4 le righe hanno età = 99.	La riga con id = 4 ha il valore di età 40 poiché non era visibile alla transazione 2 durante la query di aggiornamento. Le altre righe vengono aggiornate a age=99.

Babelfish `REPEATABLE READ` rispetto al livello di isolamento del server SQL `REPEATABLE READ`

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

Transazione 1	Transazione 2	SQLServer `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 completamento 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 della transazione 1.	vede l'aggiornamento della transazione 1.

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

Transazione 1	Transazione 2	SQLServer `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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;`	Transazione 2 bloccata.	Transazione 2 bloccata.
`COMMIT`	Inattivo in transazione	Il commit è riuscito e la transazione 2 è stata sbloccata.	Commit riuscito e la transazione 2 fallisce con errore, impossibile serializzare l'accesso a causa di un aggiornamento simultaneo.
Inattivo in transazione	`COMMIT`	Esecuzione riuscita.	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 nascoste quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di REPEATABLE READ isolamento in SQL Server rispetto all'implementazione Babelfish. REPEATABLE READ

Transazione 1	Transazione 2	SQLServer `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 alcun blocco.	La transazione 2 procede senza alcun blocco.
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 su quando vengono eseguite transazioni simultanee e i diversi risultati finali quando si utilizza il livello di REPEATABLE READ isolamento in SQL Server rispetto all'implementazione REPEATABLE READ Babelfish.

Transazione 1	Transazione 2	SQLServer `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 poiché l'SELECTistruzione tenta di leggere le righe bloccate dalla UPDATE query nella transazione 1.	La transazione 2 procede senza alcun blocco poiché la lettura non viene mai bloccata, l'SELECTistruzione viene eseguita e infine la riga con id = 3 viene aggiornata poiché le modifiche alla transazione 1 non sono ancora visibili.
Inattivo in transazione	`SELECT * FROM employee;`	Questo passaggio viene eseguito dopo il completamento della transazione 1. La riga con id = 1 viene aggiornata dalla transazione 2 nel passaggio precedente ed è visibile qui.	La riga con id = 3 viene aggiornata dalla transazione 2.
`COMMIT`	Inattivo in transazione	La transazione 2 è ora sbloccata.	Impegno riuscito.
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.

Babelfish `SERIALIZABLE` rispetto al livello di isolamento SQL del server `SERIALIZABLE`

La tabella seguente fornisce dettagli sugli intervalli di blocco quando vengono eseguite transazioni simultanee. Mostra i risultati osservati quando si utilizza il livello di SERIALIZABLE isolamento in SQL Server rispetto all'implementazione SERIALIZABLE Babelfish.

Transazione 1	Transazione 2	SQLServer `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 completamento della transazione 1.	La transazione 2 procede senza alcun blocco.
Inattivo in transazione	`SELECT * FROM employee;`	Nessuno	Nessuno
`COMMIT`	Inattivo in transazione	La transazione 1 viene eseguita correttamente. La transazione 2 è ora sbloccata.	La transazione 1 viene eseguita correttamente.
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 su quando vengono eseguite transazioni simultanee e i diversi risultati finali quando si utilizza il livello di SERIALIZABLE isolamento in SQL Server rispetto all'implementazione SERIALIZABLE Babelfish.

Transazione 1	Transazione 2	SQLServer `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 completamento della transazione 2.	La transazione 1 procede senza alcun blocco.
Inattivo in transazione	`COMMIT`	La transazione 2 viene eseguita correttamente. La transazione 1 è ora sbloccata.	La transazione 2 viene eseguita correttamente.
`COMMIT`	Inattivo in transazione	Nessuno	Nessuno
`SELECT * FROM employee;`	Inattivo in transazione	La riga appena inserita è visibile con valore di età = 99.	La riga appena inserita è visibile con valore di età = 40.

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

Transazione 1	Transazione 2	SQLServer `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 completamento della transazione 2.	La transazione 1 è bloccata fino al completamento della transazione 2.
Inattivo in transazione	`COMMIT`	La transazione 2 viene eseguita correttamente. La transazione 1 è ora sbloccata.	La transazione 2 viene eseguita correttamente. La transazione 1 interrotta con errore «valore chiave duplicato» viola un vincolo univoco.
`COMMIT`	Inattivo in transazione	La transazione 1 viene eseguita correttamente.	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 Isolation Level serializable falliranno con 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 SERIALIZABLE isolamento in SQL Server rispetto all'implementazione Babelfish. SERIALIZABLE

Transazione 1	Transazione 2	SQLServer `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 completamento della transazione 1.	La transazione 2 procede senza alcun blocco.
Inattivo in transazione	`UPDATE employee SET age=35 WHERE age=30;`	Nessuno	Nessuno
`COMMIT`	Inattivo in transazione	La transazione 1 viene eseguita correttamente.	La transazione 1 viene confermata per prima ed è in grado di eseguirla con successo.
Inattivo in transazione	`COMMIT`	La transazione 2 viene eseguita correttamente.	Il commit della transazione 2 non riesce a causa di un errore di serializzazione, l'intera transazione è stata annullata. Riprova la transazione 2.
`SELECT * FROM employee;`	Inattivo in transazione	Le modifiche di entrambe le transazioni sono visibili.	La transazione 2 è stata annullata. Vengono visualizzate solo le modifiche alla transazione 1.

In Babelfish, l'anomalia di serializzazione è possibile solo se tutte le transazioni simultanee vengono eseguite a livello di isolamento. SERIALIZABLE Nella tabella seguente, prendiamo l'esempio precedente ma impostiamo invece la transazione 2 sul livello di isolamento. REPEATABLE READ

Transazione 1	Transazione 2	SQLLivelli di isolamento del 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 completamento della transazione 1.	La transazione 2 procede senza alcun blocco.
Inattivo in transazione	`UPDATE employee SET age=35 WHERE age=30;`	Nessuno	Nessuno
`COMMIT`	Inattivo in transazione	La transazione 1 viene eseguita correttamente.	La transazione 1 viene eseguita correttamente.
Inattivo in transazione	`COMMIT`	La transazione 2 viene eseguita correttamente.	La transazione 2 viene eseguita correttamente.
`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 delle transazioni in Babelfish

Utilizzo di funzionalità Babelfish con implementazione limitata

Confronto tra i livelli di isolamento di Babelfish e SQL Server

Nota

Argomenti

Babelfish READ UNCOMMITTED rispetto al livello di isolamento SQL del server READ UNCOMMITTED

Babelfish READ COMMITTED rispetto al livello di isolamento SQL del server READ COMMITTED

Babelfish READ COMMITTED rispetto al livello di isolamento SQL del server READ COMMITTED SNAPSHOT

Babelfish REPEATABLE READ rispetto al livello di isolamento del server SQL REPEATABLE READ

Babelfish SERIALIZABLE rispetto al livello di isolamento SQL del server SERIALIZABLE

Babelfish `READ UNCOMMITTED` rispetto al livello di isolamento SQL del server `READ UNCOMMITTED`

Babelfish `READ COMMITTED` rispetto al livello di isolamento SQL del server `READ COMMITTED`

Babelfish `READ COMMITTED` rispetto al livello di isolamento SQL del server `READ COMMITTED SNAPSHOT`

Babelfish `REPEATABLE READ` rispetto al livello di isolamento del server SQL `REPEATABLE READ`

Babelfish `SERIALIZABLE` rispetto al livello di isolamento SQL del server `SERIALIZABLE`