SQL Server Seleziona il conteggio READ_COMMITTED_SNAPSHOT DOMANDA


8

Sembra che stia ottenendo molti deadlock quando si seleziona select count (*) su una tabella particolare. Ho già modificato tutti i parametri richiesti e li ho trasformati in blocco solo riga.

Ho anche modificato il database per utilizzare l'isolamento READ_COMMITTED_SNAPSHOT,

tuttavia, sembra che usando un conteggio selezionato (*) dove colonna =? sul tavolo innesca deadlock o blocchi sul tavolo ..

Ho ragione che il conteggio delle selezioni (*) dovrebbe accedere solo alle righe intermedie? Tuttavia, non sembra in questo modo e sto ancora riscontrando deadlock. Una corretta indicizzazione probabilmente aiuterebbe,

La domanda è: SQL Server 2008 R2 posiziona il blocco condiviso sulla tabella durante il conteggio selezionato (*) anche quando read_committed_snapshot è impostato su on?

Grazie


Hai bisogno di un conteggio esatto (a partire dalla richiesta) o va bene un conteggio approssimativo?
Jon Seigel,

in realtà, ho solo bisogno di sapere se vengono posizionati blocchi condivisi. Sto cercando di indagare su un problema di deadlock. Grazie
grassbl8d,

Il mio punto era che se si può considerare di cambiare il modo in cui si ottiene il conteggio, questo potrebbe essere il modo di risolvere il problema del deadlock. Ma ora che ho letto di nuovo la domanda, se è necessario utilizzare una WHEREclausola, il metodo a cui sto pensando non funzionerà comunque.
Jon Seigel,

È possibile ottenere conteggi approssimativi dalle tabelle dei metadati per un sottoinsieme della tabella se la clausola where corrisponde a un indice filtrato.
Aaron Bertrand

Risposte:


2

Fai attenzione con READ_COMMITTED_SNAPSHOT: se lo attivi, può causare molti bug impercettibili.

Anche READ_COMMITTED_SNAPSHOT è il livello di isolamento predefinito, che può essere ignorato da qualcosa. Esegui DBCC USEROPTIONS per determinare il livello di isolamento effettivo in cui viene eseguita la selezione.

Vorrei impostare esplicitamente SNAPSHOT LIVELLO ISOLAMENTO TRANSAZIONE prima della selezione. In questo modo sarai sicuro che la tua selezione non si abbraccerà mai nei deadlock e non infrangerai nessun altro codice, come potrebbe fare READ_COMMITTED_SNAPSHOT.


0

Il blocco con Isolamento istantanea non cambia. Ciò che cambia è che quando le pagine vengono modificate sotto di te, quelle pagine vengono copiate nel database tempdb in modo da poterle leggere dal database tempdb anziché dal normale database. (Sì, questa è una versione semplificata di ciò che sta accadendo.)

Hai detto che non hai in atto l'indicizzazione corretta, quindi stai eseguendo una scansione dell'indice in cluster (o una scansione della tabella se è un heap). Questi sono potenzialmente molti dati da spostare nel database tempdb. Se questa query è qualcosa che verrà eseguito più di una volta, suggerirei di aggiungere l'indice alla tabella.

Quale livello di isolamento utilizza la tua query?


Sto usando il livello di isolamento read_commited_snapshot. L'ho acceso come sto usando read_commit di default. Sono solo interessato se i blocchi vengono posizionati durante determinati conteggi. Grazie, ho già inserito gli indici tra
grassbl8d il

Sì, i blocchi sono ancora in corso. È possibile eseguire una query su sys.dm_tran_locks per vedere i blocchi in corso. Esegui la query in una finestra e esegui query sys.dm_tran_locks in un'altra finestra per vedere quali blocchi vengono eseguiti. Potrebbe essere necessario passare ai blocchi della tabella e utilizzare un suggerimento per forzare i blocchi a livello di pagina o persino di riga.
mrdenny,
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.