SNAPSHOT COMMITTED READ COMMITTED di SQL Server vs SNAPSHOT


23

Stavo studiando le differenze tra i livelli di SQL Server READ COMMITTED SNAPSHOTe di SNAPSHOTisolamento e mi sono imbattuto nella seguente risorsa:

Scelta dei livelli di isolamento basati su Versioning di riga

Per la maggior parte delle applicazioni, si consiglia di leggere l'isolamento con commit utilizzando il controllo delle versioni delle righe rispetto all'isolamento dello snapshot per i seguenti motivi:

  • Consuma meno spazio tempdb rispetto all'isolamento dello snapshot.

  • L'isolamento dello snapshot è vulnerabile agli aggiornamenti dei conflitti che non sono applicabili alla lettura dell'isolamento commesso mediante il controllo delle versioni delle righe. Quando una transazione in esecuzione con l'isolamento dello snapshot legge i dati che vengono poi modificati da un'altra transazione, un aggiornamento della transazione dello snapshot agli stessi dati provoca un conflitto di aggiornamento e la transazione termina e torna indietro. Questo non è un problema con l'isolamento impegnato nella lettura mediante il controllo delle versioni delle righe.

Sono un po 'nuovo su questi argomenti, ma non riesco a capire i due punti elenco dal link sopra.

  1. Perché lo spazio tempdb sarebbe diverso per queste modalità? Uno memorizza un versioning più granulare rispetto all'altro?

  2. Perché l'isolamento dello snapshot è più vulnerabile agli aggiornamenti dei conflitti?

Risposte:


18
  1. READ COMMITTED SNAPSHOTutilizza una nuova istantanea dopo ogni istruzione. Ciò significa che vengono mantenute in vita meno versioni di riga. (L'affermazione che hai citato dai documenti è leggermente fuorviante perché suggerisce che questo è sempre vero - è vero solo in caso di SNAPSHOTtransazioni di lunga durata .) Le versioni delle righe dello snapshot vengono create in scrittura. Le letture non influenzano ciò che viene messo in tempdb. Gli scrittori non possono probabilmente prevedere quali letture verranno eseguite in futuro. I lettori influenzano solo ciò che può essere eliminato.
  2. Quando una SNAPSHOTtransazione T1scrive su una riga che è stata modificata da un'altra transazione T2nel tempo tra l' T1avvio e il T1tentativo di scrittura, l'istruzione ha esito negativo con un errore di conflitto di aggiornamento. Questo è un modello di concorrenza ottimista. Con READ COMMITTED SNAPSHOT T1aspetterebbe T2di rilasciare l'X-lock sulla riga e continuare normalmente.

1
Per # 2, è sicuro dire che SNAPSHOT non si blocca esclusivamente per gli aggiornamenti, ma si basa solo sul controllo delle versioni delle righe?
John Russell,

1
@JohnRussell si blocca esclusivamente per supportare il rollback. Tutte le scritture devono essere X-lock per garantire che la riga possa essere ripristinata in caso di rollback.
usr

0

Un'ulteriore differenza tra istantanea e lettura dell'istantanea impegnata è la seguente.

  1. istantanea

Nella prima sessione

IMPOSTA LIVELLO ISOLAMENTO TRAN SNAPSHOT INIZIA TRAN SELEZIONA * DA TB1 ..... .....

Nella seconda sessione

Aggiorna TB1 SET NAME = NAME + 'test' Where id = 1

Nella prima sessione

SELEZIONA * DA TB1 - QUESTO restituirà il nome valore per ID = 1, non nome + 'test' COMMIT TRAN

Nell'istantanea impegnata in lettura la prima selezione nella sessione 1 restituirà il nome per id = 1 e la seconda selezione restituirà il nome + 'test'.

Quindi, in isolamento dello snapshot, SQL SERVER esegue uno snapshot all'inizio della transazione e legge da quello snapshot durante l'intera transazione.

Nell'istantanea impegnata in lettura l'istantanea viene acquisita per ogni istruzione SELECT durante la transazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.