none
Trovato lock con READ UNCOMMITTED ?! RRS feed

 > 

  • Domanda

  • Question
    Registrati per votare
    0
    Registrati per votare

    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

    venerdì 8 gennaio 2016 17:10
    |

Risposte

Tutte le risposte

  • Question
    Registrati per votare
    1
    Registrati per votare

    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

    venerdì 8 gennaio 2016 22:54
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    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

    sabato 9 gennaio 2016 10:27
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    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


    sabato 9 gennaio 2016 17:45
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    Ok, quindi se la seconda transazione avesse usato il livello read uncommitted in questo caso non ci sarebbe stato alcun lock.

    C' è modo di trovare la transazione relativa al FETCH API_CURSOR000000000003D6DF ?

    thanks.

    sabato 9 gennaio 2016 21:02
    |
  • Question
    Registrati per votare
    1
    Registrati per votare

    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

    domenica 10 gennaio 2016 22:19
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    ottimo, grazie!

    ciao

    martedì 12 gennaio 2016 19:42
    |