Quali sono i rischi se abilitiamo l'istantanea con commit della lettura in sql-server?

Ho letto qui che verranno archiviati alcuni dati extra per riga, quindi potremmo vedere un peggioramento delle prestazioni ma quali altri rischi ci sono?

per esempio. Ciò influirà sul recupero del database? C'è qualcos'altro che dobbiamo fare per approfittare di questo?

Ho intenzione di eseguire questi comandi:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Credo che questo ci darà qualcosa di più vicino all'oracolo in cui se una transazione si aggiorna altre transazioni possono ancora leggere i vecchi dati. È corretto?

Sto esaminando questo perché sono stufo dei problemi di blocco in SQL Server 2005. Spero che ciò possa ridurre i deadlock occasionali che i nostri utenti vedono, aiutare le prestazioni complessive della nostra applicazione e incoraggiare i nostri sviluppatori a fare più di un'operazione per transazione senza paura.

Sommario

1. Se hai problemi di blocco, allora hai un problema con il tuo codice: non è il motore di database
2. Non è un proiettile magico
3. Potresti aggiungere altri problemi

Caricare

Aumenterà anche il carico sul tuo tempdb e CPU . Vedi anche:

• "Impatto sulle prestazioni: il potenziale costo di Read_Committed_Snapshot" (Linchi Shea)

Sicurezza

Soprattutto, per impostazione predefinita gli isolamenti delle istantanee non sono sicuri in molti casi . Leggi "Isolamento snapshot" (Wikipedia) per ulteriori informazioni sulle anomalie di scrittura / inclinazione. La prossima sezione è "Rendere serializzabile l'isolamento di istantanee" per aggirare questo problema.

In generale, quindi, l'isolamento delle istantanee pone alcuni dei problemi legati al mantenimento di vincoli non banali per l'utente, che potrebbe non apprezzare né le potenziali insidie ​​né le possibili soluzioni. Il vantaggio di questo trasferimento è una prestazione migliore.

Vedi anche:

• "I potenziali pericoli del livello di isolamento dell'istantanea commessa in lettura " (JimMcLeod, contestato nei commenti di Alex Kuznetsov)
• Deadlocked !: "leggi l'istantanea impegnata" Spiegato (Nick Berardi)
• Serializable vs. Snapshot Isolation Level, il problema di Marble (Craig Freedman)
• Le letture che coinvolgono UDF sotto READ_COMMITTED_SNAPSHOT possono sembrare incoerenti (Alex Kuznetsov)

So che si tratta di un vecchio thread, ma direi che in gran parte l'isolamento istantaneo è un proiettile magico. Eliminerà tutti i tuoi blocchi tra lettori e scrittori. Tuttavia non impedirà agli scrittori di bloccare altri scrittori. Non c'è modo di aggirare questo.

Nella mia esperienza, il carico aggiuntivo sul TEMPDB è trascurabile e i vantaggi del controllo delle versioni di riga nella riduzione dei lettori bloccati sono enormi.

Per riferimento, il versioning delle righe (isolamento delle istantanee) è il metodo che Oracle ha usato per decenni per ottenere l'isolamento senza bloccare i lettori e i DB Oracle su cui ho lavorato per quasi 20 anni hanno molti meno problemi di blocco rispetto a SQL Server. La maggior parte degli sviluppatori SQL esita a utilizzare l'isolamento di istantanee perché ha testato il proprio codice solo su database che utilizzano l'impostazione predefinita.

Coppia di punti aggiuntivi da aggiungere alle altre risposte:

SET ALLOW_SNAPSHOT_ISOLATION ONabilita l'isolamento dello snapshot solo in un database. Per trarne vantaggio è necessario ricodificare e SET TRANSACTION ISOLATION LEVEL SNAPSHOTper le transazioni a cui si desidera applicare. Il codice chiamante dovrà essere modificato per gestire gli errori di conflitto di aggiornamento.

Dopo SET READ_COMMITTED_SNAPSHOT ON, le dichiarazioni a lettura impegnata uso di riga delle versioni. Nota, questo è il versioning delle righe a livello di istruzione solo per letture . Per gli aggiornamenti, viene recuperata la riga "reale" e applicati i blocchi di aggiornamento. Vedere la sezione Riepilogo del comportamento in Informazioni sui livelli di isolamento basati sul controllo delle versioni di riga

In entrambi i casi, senza test esaustivi è probabile che introduciate una serie completamente nuova di problemi nel sistema.

Credo che questo ci darà qualcosa di più vicino all'oracolo in cui se una transazione si aggiorna altre transazioni possono ancora leggere i vecchi dati. È corretto?

Sì, questo è corretto .

Vale la pena leggere i collegamenti nella risposta di gbn e credo che lo stesso valga per l'MVCC predefinito di Oracle come per SQL Server in modalità Isolamento istantanea. Aggiungo che se capisci le potenziali insidie, i benefici dell'IMO superano di gran lunga le difficoltà aggiunte (parlando da una prospettiva Oracle) - e ovviamente alcuni problemi di blocco scompaiono legittimamente, questo è il punto di MVCC (c'è anche una classe di problemi di blocco che non andranno via a causa di problemi di codice, ma presumo che tu lo capisca).

Stiamo usando SNAPSHOT ISOLATION in tutti i nostri progetti che utilizzano SQL Server DB. Non più errori SQL 1205, causati non da un codice dell'applicazione errato, ma dal comportamento di blocco delle pagine e delle righe predefinito.

L'impatto sulle prestazioni è minimo e finora sono trascorsi 7 anni, centinaia di milioni di operazioni sono state elaborate in sistemi diversi, senza problemi di ISOLAMENTO SNAPSHOT.

Le situazioni in cui diversi thread diversi stanno aggiornando le informazioni aziendali critiche in una singola riga in parallelo sono estremamente eccezionali e le probabilità che ISOLATION SNAPSHOT causino qualsiasi problema di incoerenza sono molto vicine allo zero.

Se si dispone di un sistema OLTP, che per impostazione predefinita aggiorna una singola riga in base ai dati della riga corrente in molti thread, ovviamente SNAPSHOTS non è accettabile in questi casi.

lo avevamo attivo e una strana istruzione sql in esecuzione 4 ha mai bloccato l'intero db, non importa quanti core e tutti. La disattivazione di RCSI ha risolto il problema. Lo accenderei una volta che dovessi affrontare altri deadlock, non di default.