Principale utente con più risposte
Trovato lock con READ UNCOMMITTED ?!

Domanda
-
Ciao a tutti,
ho da qualche giorno attivato il report per identificare i lock sul database e con mia sorpresa ho trovato che il processo che crea il lock (un lock 3-S ovvero un shared lock di una semplice select) sembra essere stato eseguito con l'isolamento RED UNCOMMITTED:
<blocked-process-report>
<blocked-process>
<process id="process8a2e08" taskpriority="0" logused="0" waitresource="PAGE: 11:3:1936706" waittime="5254" ownerId="92843974" transactionname="SELECT" lasttranstarted="2016-01-08T15:22:46.110" XDES="0x2d22b3b80" lockMode="S" schedulerid="3" kpid="4768" status="suspended" spid="972" sbid="0" ecid="4" priority="0" trancount="0" lastbatchstarted="2016-01-08T15:22:46.107" lastbatchcompleted="2016-01-08T15:22:46.107" clientapp=".Net SqlClient Data Provider" hostname="LIP01" hostpid="2020" isolationlevel="read committed (2)" xactid="92843974" currentdb="11" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
<executionStack>
<frame line="2" stmtstart="36" sqlhandle="0x02000000fb52e7124d640472ed556377d25c80ebd7e0bee3"/>
<frame line="1" sqlhandle="0x000000000000000000000000000000000000000000000000"/>
</executionStack>
<inputbuf>
</inputbuf>
</process>
</blocked-process>
<blocking-process>
<process status="sleeping" spid="944" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2016-01-08T15:22:51.450" lastbatchcompleted="2016-01-08T15:22:51.450" clientapp=".NET Framework Library" hostname="DO01" hostpid="2100" loginname="Item" isolationlevel="read uncommitted (1)" xactid="92834094" currentdb="11" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<executionStack/>
<inputbuf>
FETCH API_CURSOR000000000003D6DF </inputbuf>
</process>
</blocking-process>
</blocked-process-report>Quindi mi chiedo come può una transazione con query UNCOMMITTED lockare un'altra transazione? purtroppo essendo un cursore non riesco a trovare quale sia lo statement eseguito.
Grazie per l'aiuto
Ciao
Risposte
-
C' è modo di trovare la transazione relativa al FETCH API_CURSOR000000000003D6DF ?
Ciao Andrea,
conoscendo lo SPID (session process ID), che nel tuo esempio era 944 per la sessione che stava eseguendo l'operazione di fetch dal cursore, puoi interrogare la DMV sys.dm_tran_session_transactions filtrandola sulla colonna session_id ed ottenere l'ID della transazione, attraverso il quale puoi recuperare le altre informazioni.
Ciao
Sergio Govoni
SQL Server MVP
MVP Profile | English Blog | Twitter | LinkedIn- Modificato Sergio GovoniMVP, Moderator domenica 10 gennaio 2016 22:20
- Proposto come risposta Fabrizio GiammariniMVP, Moderator martedì 12 gennaio 2016 10:52
- Contrassegnato come risposta JeTibaMicrosoft employee, Moderator martedì 26 aprile 2016 09:45
Tutte le risposte
-
Quindi mi chiedo come può una transazione con query UNCOMMITTED lockare un'altra transazione? purtroppo essendo un cursore non riesco a trovare quale sia lo statement eseguito.
Ciao,
una query eseguita con il livello di isolamento Read UnCommitted, può leggere dati non ancora committati da parte di altre transazioni, ma può bloccare a sua volta altre transazioni.. nell'esempio che hai postato, sta bloccando una query con livello di isolamento Read Committed.
Ciao
Sergio Govoni
SQL Server MVP
MVP Profile | English Blog | Twitter | LinkedIn- Modificato Sergio GovoniMVP, Moderator venerdì 8 gennaio 2016 22:55
-
Chiaro.
Quindi l'unico modo per far si che una query come quella che ho postato non blocchi altre transazioni DML è quello di eseguirla cambiando il livello di isolamento in SET TRANSACTION ISOLATION LEVEL SNAPSHOT (con ovviamente database abilitato)?
Supponiamo che la query viene eseguita con livello snapshot e successivamente interviene una qualsiasi transazione DML senza livello di isolamento (classico read committed), non dovrebbero esserci problemi giusto? ovviamente la seconda transazione eseguirà il classico lock ma per lo meno non viene bloccata da una semplice query.
grazie ancora
ciao
-
Ciao,
questo paragrafo, estratto dai BOL, è chiarificatore:
"La scelta di un livello di isolamento delle transazioni non ha effetto sui blocchi acquisiti per proteggere le modifiche dei dati. Una transazione ottiene sempre un blocco esclusivo su qualsiasi dato da essa modificato, che mantiene fino al suo completamento, indipendentemente dal livello di isolamento impostato per la transazione. Per le operazioni di lettura, i livelli di isolamento delle transazioni definiscono essenzialmente il livello di protezione dagli effetti delle modifiche apportate da altre transazioni.
Un livello di isolamento inferiore aumenta la possibilità per un maggior numero di utenti di accedere ai dati contemporaneamente, ma anche la quantità di effetti di concorrenza (ad esempio letture dirty o perdita di aggiornamenti) potenzialmente verificabili"
Con il livello di isolamento Snapshot Read Committed e l'opzione READ_COMMITTED_SNAPSHOT attivata (ON) le operazioni di lettura richiederanno solo i blocchi a livello di tabella e nessun blocco di pagina o di riga.. non bloccando quindi altre query.
Ciao
Sergio Govoni
SQL Server MVP
MVP Profile | English Blog | Twitter | LinkedIn
- Modificato Sergio GovoniMVP, Moderator sabato 9 gennaio 2016 17:46
-
-
C' è modo di trovare la transazione relativa al FETCH API_CURSOR000000000003D6DF ?
Ciao Andrea,
conoscendo lo SPID (session process ID), che nel tuo esempio era 944 per la sessione che stava eseguendo l'operazione di fetch dal cursore, puoi interrogare la DMV sys.dm_tran_session_transactions filtrandola sulla colonna session_id ed ottenere l'ID della transazione, attraverso il quale puoi recuperare le altre informazioni.
Ciao
Sergio Govoni
SQL Server MVP
MVP Profile | English Blog | Twitter | LinkedIn- Modificato Sergio GovoniMVP, Moderator domenica 10 gennaio 2016 22:20
- Proposto come risposta Fabrizio GiammariniMVP, Moderator martedì 12 gennaio 2016 10:52
- Contrassegnato come risposta JeTibaMicrosoft employee, Moderator martedì 26 aprile 2016 09:45
-