Leggi commesso livello di isolamento snapshot VS Snapshot

Question

Potrebbe qualcuno si prega di aiuto a capire quando usare livello di isolamento SNAPSHOT oltre LEGGI IMPEGNA SNAPSHOT in SQL Server?

Mi rendo conto che nella maggior parte dei casi, leggere le opere SNAPSHOT impegnato, ma non so quando vado per isolamento dello snapshot.

Grazie

Answer 1

READ COMMITTED SNAPSHOT fa ottimista legge e scrive pessimistiche. Al contrario, SNAPSHOT fa ottimista legge e scrive ottimistiche.

Si consiglia READ COMMITTED SNAPSHOT per la maggior parte le applicazioni che fila necessità delle versioni.

Leggere questo ottimo articolo di Microsoft: Scelta livelli di isolamento delle versioni delle righe basate . Spiega i benefici ei costi di entrambi i livelli di isolamento.

Ed ecco una più approfondita: http://msdn.microsoft.com/en-us/ biblioteca / ms345124 (SQL.90) .aspx

Answer 2

[2]

Si veda l'esempio qui sotto:

Leggi Committed Snapshot

Cambia la proprietà del database, come di seguito

ALTER DATABASE SQLAuthority
SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
GO

Sessione 1

USE SQLAuthority
GO
BEGIN TRAN
UPDATE DemoTable
SET i = 4
WHERE i = 1

Sessione 2

USE SQLAuthority
GO
BEGIN TRAN
SELECT *
FROM   DemoTable
WHERE i = 1

Risultato - Query nella Sessione 2 mostra vecchio valore (1, ONE) perché transazione corrente non è impegnata. Questo è il modo per evitare di bloccare e leggere i dati impegnati anche.

Sessione 1

COMMIT

Sessione 2

USE SQLAuthority
GO
SELECT *
FROM   DemoTable
WHERE i = 1

Risultato -. Query nella Sessione 2 mostra alcuna riga perché riga viene aggiornata in sessione 1. Così ancora una volta, stiamo assistendo a dati impegnati

Snapshot Isolation Level

Questo è il nuovo livello di isolamento, che era disponibile da SQL Server 2005 in poi. Per questa caratteristica, v'è un cambiamento necessario nella domanda come deve utilizzare un nuovo livello di isolamento.

Cambia database di impostazione usando sotto. Dobbiamo fare in modo che non ci sia nessuna transazione nel database.

ALTER DATABASE SQLAuthority SET AllOW_SNAPSHOT_ISOLATION ON

Ora, abbiamo anche bisogno di cambiare il livello di isolamento della connessione utilizzando seguente

Sessione 1

USE SQLAuthority
GO
BEGIN TRAN
UPDATE DemoTable
SET i = 10
WHERE i = 2

Sessione 2

SET TRANSACTION ISOLATION LEVEL SNAPSHOT
GO
USE SQLAuthority
GO
BEGIN TRAN
SELECT *
FROM   DemoTable
WHERE i = 2

result- Anche se abbiamo cambiato il valore a 10, ci sarà ancora vedere vecchio record in sessione 2 (2, DUE).

Ora, proviamo ad commettono transazione in sessione 1

Sessione 1

COMMIT

Torniamo alla sessione 2 ed eseguire selezionare nuovamente.

Sessione 2

SELECT *
FROM   DemoTable
WHERE i = 2

Si vedrà ancora il record a causa della sessione 2 ha dichiarato la transazione con isolamento dello snapshot. A meno che non si completa la transazione, non vedremo ultimo disco.

Sessione 2

COMMIT
SELECT *
FROM   DemoTable
WHERE i = 2

Ora, non dovremmo vedere la fila come è già aggiornato.

See: Autorità SQL , Safari Documentazione in linea

Answer 3

Nessun confronto tra Snapshot e Snapshot Read Committed è completa senza una discussione di eccezione temuto "istantanea di conflitto di aggiornamento" che può accadere in Snapshot, ma non Snapshot Read Committed.

In poche parole, l'isolamento snapshot recupera un'istantanea dei dati impegnati presso il inizio di una transazione , e quindi utilizza il blocco ottimistico sia per letture e le scritture. Se, quando il tentativo di commettere una transazione, si scopre che qualcosa cambiato alcuni dei gli stessi dati, il database verrà rollback l'intera transazione e generare un errore che causa un'eccezione conflitto di aggiornamento snapshot nel codice chiamante. Questo perché la versione dei dati interessati dalla transazione non è la stessa alla fine della transazione come era all'inizio.

Snapshot Read Committed non soffre di questo problema perché utilizza blocco su scritture (scritture pessimistiche) e ottiene informazioni sulla versione snapshot di tutti i dati impegnati alla stat di ogni dichiarazione .

La possibilità di conflitti di aggiornamento istantanee che accadono in Snapshot e NON Snapshot Read Committed è una differenza estremamente significativa tra i due.

Answer 4

Ancora rilevanti, a partire con i commenti di Bill Ho letto le note di più e fatti che potrebbero essere utili a qualcun altro.

Per le dichiarazioni singoli predefinite (tra cui "SELECT") opera sui dati "impegnati" (LEGGI impegnati), la domanda è:? Si aspettano che i dati siano "inattiva" e impedire ad altri di lavorare durante la lettura

Impostazione tramite click destro DB “Proprietà -> Opzioni -> Varie”:

Concorrenza / Blocco: viene letto Committed Snapshot on [default off, dovrebbe essere in]:

• Utilizza snapshot per selezionare (leggi), non aspettare per gli altri, e non bloccarli.
• Effetti operazione senza modifica del codice
• ALTER DATABASE SET READ_COMMITTED_SNAPSHOT [ON | OFF]
• SELECT name, is_read_committed_snapshot_on FROM sys.databases

Consistenza: Consentire Snapshot Isolation [default off, discutibili - OK off]:

• consentire ai client di richiesta ISTANTANEA attraverso istruzioni SQL (transazioni).
• Codice deve richiedere istantanee “transazione” (come SET TRANSACTION ...)
• ALTER DATABASE SET ALLOW_SNAPSHOT_ISOLATION [ON | OFF]
• SELECT name, is_read_committed_snapshot_on FROM sys.databases

Alla domanda: non è una o l'altro tra Leggi commessi Snapshot e consentire l'isolamento snapshot. Si tratta di due casi di Snapshot, e entrambi potrebbero essere acceso o spento in modo indipendente, con consentire l'isolamento snapshot un po 'più di un argomento avanzato. Lasciare Snapshot Isolation consente al codice di fare un passo ulteriore controllo Snapshot terra.

Il problema sembra chiaro se si pensa a una riga: per default il sistema ha nessuna copia, in modo da un lettore deve aspettare se qualcun altro sta scrivendo, e uno scrittore deve anche aspettare se qualcun altro sta leggendo - il mosto fila bloccare tutto il tempo. Abilitazione “viene letto Committed Snapshot On” attiva il DB di sostenere “copie snapshot” per evitare questi blocchi.

Rambling on ...

A mio parere “si legge Committed Istantanea sul” dovrebbe essere “TRUE” per le normali database MS SQLServer, e che si tratta di un'ottimizzazione prematura che le navi “FALSE” per impostazione predefinita.

Tuttavia, mi hanno detto la serratura di una riga di peggio, non solo perché si può essere affrontando più righe attraverso tabelle, ma perché in blocchi di riga di SQL Server sono implementati utilizzando "blocco" blocchi a livello (blocco righe casuali associati per vicinanza di stoccaggio ) e che ci sia una soglia in cui più si blocca grilletto tavolo di chiusura -. presumibilmente più "ottimista" ottimizzazioni delle prestazioni a rischio di problemi di blocco nei database occupato