none
SELECT BLOCCATA DA UPDATE CON TRANSAZIONE IMPLICITA RRS feed

  • Domanda

  • Salve, riuscite a farmi capire meglio questa stranezza ...?..

    Tramite script python eseguo delle istruzioni di update su una tabella... l'update viene lanciato senza dichiarare l'inizio della transazionio quindi (suppongo) viene inizializzata una transazione implicita...
    Se nel frattempo cerco di eseguire una select sulla stessa tabella oggetto dell'update; il comando viene tenuto bloccato dal processo precedente...

    mi aspetterei che l'istruzione lanciata da python (set implicit_transactions on ) non bloccasse l'accesso al processo che esegue la Select... sbaglio?..... perchè?


    Marco

    mercoledì 19 dicembre 2018 16:56

Tutte le risposte

  • Potrebbe essere un problema di Isolation Level e di come il tuo Script Python viene eseguito sul server dal programma.

    Io lavoro in .Net ed il client SQL di .Net non effettua transazioni implicite, quindi non ho mai avuto simili problemi.

    Dai un occhiata a questa pagina per capirne di più sull'Isolation Level e verifica come Python si connette a SQL Server e se vi sono dei parametri nell'esecuzione del tuo update che possano indicare come aggiornare con la corretta modalità per le tue esigenze.

    https://docs.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-2017

    Aggiungo che normalmente le Update dovrebbero essere così rapide da non dare fastidio alle select, magari se mi dici cosa aggiorni e come potrebbe essere solo necessario modificare la query di Update.

    saluti


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 dicembre 2018 09:30
  • mi aspetterei che l'istruzione lanciata da python (set implicit_transactions on ) non bloccasse l'accesso al processo che esegue la Select... sbaglio?..... perchè?

    Ciao Marco,

    sono d'accordo con quanto suggerisce Sabrina, controlla l'isolation level di entrambe le connessioni (specialmente di quella che esegue la SELECT).

    L'isolation level by default per le connessioni a SQL Server è Read Committed Isolation Level (per fortuna IMHO), se la connessione che esegue la SELECT lavora con questo livello di isolamento, potrà leggere dati "committati" quindi rimarrà in attesa del commit del comando di UPDATE, per leggere le data page modificate.

    Qui trovi tutti i dettagli: Understanding SQL Server Isolation Levels.

    Ciao!


    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn

    domenica 23 dicembre 2018 16:46
    Moderatore
  • Grazie mille!!...

    non avevo mai affrontato questo argomento prima d'ora..:

    ad ogni modo python lancia la connesione con questo livello di isolamento..:

    -- network protocol: TCP/IP
    set quoted_identifier on
    set arithabort off
    set numeric_roundabort off
    set ansi_warnings on
    set ansi_padding on
    set ansi_nulls on
    set concat_null_yields_null on
    set cursor_close_on_commit off
    set implicit_transactions off
    set language Italiano
    set dateformat dmy
    set datefirst 1
    set transaction isolation level read committed

    forse dovrei modificare la connessione e impostare il livello "...READUNCOMMITTED"....

    CHE DITE?

    ps: in linea di principio concordate con la mia idea che; per eventuali query di sola lettura sarebbe sempre opportuno impostare il livello COMMITTED?..... evitando così di bloccae altri processi e leggrendo così solo dati "consolidati" al momento della richiesta della select...


    Marco

    mercoledì 26 dicembre 2018 22:05

  • set transaction isolation level read committed

    forse dovrei modificare la connessione e impostare il livello "...READUNCOMMITTED"....

    CHE DITE?

    ps: in linea di principio concordate con la mia idea che; per eventuali query di sola lettura sarebbe sempre opportuno impostare il livello COMMITTED?..... evitando così di bloccae altri processi e leggrendo così solo dati "consolidati" al momento della richiesta della select...

    Ciao Marco,

    sulla scelta del livello di isolamento, a mio parere, non c'è sempre una risposta giusta o sbagliata, ma dipende dal contesto.

    SE per la query (leggi connessione) che esegue soltanto una SELECT si possono tollerare eventuali "dirty reads" dovute al livello di isolamento "readuncommitted" allora la tua idea è buona, se non possiamo tollerare le "dirty reads" significa che il livello di "readuncommitted" non è opportuno.

    Per la mia esperienza: per una query che estrae il fatturato in tempo reale, sui dati in continua evoluzione (OLTP), si possono tollerare eventuali dirty reads, viene comunicato che il dato è temporaneo e che ci possono essere scostamenti. Per una query che effettua la stampa di un DdT oppure di una fattura, o che determina la quantità giacente di un prodotto, per me, le dirty reads non sono ammesse e quindi di conseguenza non è opportuno utilizzare il livello di isolamento readuncommitted.

    Ciao


    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn

    mercoledì 26 dicembre 2018 23:03
    Moderatore
  • concordo con te!! Grazie

    Marco

    giovedì 27 dicembre 2018 19:47