it-swarm.it

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

Ho letto qui che alcuni dati extra verranno archiviati 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 a Oracle 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.

73
Adam Butler

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. Puoi aggiungere altri problemi

Carico

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

Sicurezza

Più importante, isolamenti di istantanee non sono sicuri in molti casi per impostazione predefinita. Leggi "Isolamento istantanea" (Wikipedia) per ulteriori informazioni sulle anomalie di scrittura/inclinazione. La sezione successiva è "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:

49
gbn

So che questo è un vecchio thread, ma direi in gran parte l'isolamento dell'istantanea è un proiettile magico. Eliminerà tutto del tuo blocco 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 di esperienza lontano meno problemi di blocco rispetto a SQL Server lo fa. 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.

36
Chuck

Coppia di punti aggiuntivi da aggiungere alle altre risposte:

SET ALLOW_SNAPSHOT_ISOLATION ON abilita l'isolamento dello snapshot solo in un database. Per trarne vantaggio devi ricodificare e SET TRANSACTION ISOLATION LEVEL SNAPSHOT per le transazioni a cui desideri applicare. Il codice chiamante dovrà essere modificato per gestire gli errori di conflitto di aggiornamento.

Dopo SET READ_COMMITTED_SNAPSHOT ON, le istruzioni in lettura vengono utilizzate per il controllo delle versioni delle righe. Nota, questo è livello di istruzione il versioning delle righe per solo 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.

26

Credo che questo ci darà qualcosa di più vicino a Oracle 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 naturalmente 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 utilizzando SNAPSHOT ISOLATION in tutti i nostri progetti che utilizzano SQL Server DB. Niente più errori SQL 1205, causati non da un codice dell'applicazione errato, ma dal comportamento predefinito del blocco delle pagine e delle righe.

L'impatto sulle prestazioni è minimo e finora sono trascorsi 7 anni, centinaia di milioni di operazioni sono state elaborate in diversi sistemi, 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 hai un 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.

10