[SQL Server] Accodamento dati anche se tabella allocata

[ibernet]

Buongiorno a tutti, scenario: SQL Server 2008 Enterprise

Il problema:
Tabella "Pippo" condivisa con n utenti abilitati ad accedervi con il solo permesso di "Select"
La tabella Pippo viene updatada più volte durante il giorno (sempre in accoda) e viene eseguito un delete di una fetta di dati posti nel passato.

Casistica:
- Un utente accede alla tabella con un driver ODBC, non la chiude e la tabella rimanendo allocata non riesce ad eliminare i dati della tabella finchè l'utente finale non libera il processo, quindi impedisce anche il successivo insert

Soluzione tampone:
Una procedura che prima di procedere al delete controlla se c'è qualche utente che la impegna, se ne trova killa in automatico gli utenti e procede con il delete e poi la scrittura dei dati.
Funziona, ma questa casistica non è ottimale perchè essendo una tabella che viene updatata molte volte ci ritroviamo nella condizione di killare continuamente le query degli utenti finali.

Il collegamento con access è solo un esempio, la tabella può essere letta anche da PowerBI, Visula Studio, SQL Stesso.
------------------------------------------------------------

Richiesta di aiuto:
Conoscete un modo per poter cancellare il dato anche se la tabella è allocata da n utenti senza doverli killare e senza dover attendere la coda di accesso di SQL?
Se la soluzione richiede una modifica al db/schema/tabella va bene, ciò che mi interessa è comprendere come eliminare e accodare immediatamente i dati pur avendo la tabella impegnata da altri utenti.

[URANIO]

C'è qualcosa di strano o ho capito male.
A meno di non gestire male la transazione la tabella è accessibile sempre.

[ibernet]

Ciao Uranio, hai ragione, ho modificato il testo sopra specificando meglio il problema.

[nman]

Concordo con Uranio, SQLServer di default è sempre accessibile


Il tuo problema mi ricorda qualcosa relativo all' "Accesso esclusivo"
Potresti avere qualche impostazione particolare nel DB ??

https://msdn.microsoft.com/it-it/library/ms345598.aspx

.

[optime]

se ne parla qui http://dba.stackexchange.com/questio...-in-sql-server

[ibernet]

Ciao ragazzi, vi ringrazio molto per il supporto.
Alla fine microsoft mi ha risposto, ci ho parlato poco fa e entro domani ho 2 soluzioni che poi vi condivido.
Sono molto fighe, una semplice e una complicata ma molto performante e sicura.

A presto e grazie

[nman]

Ma ritengo che non ti servano soluzioni particolari, .....

SQLServer di Default non ha nessun blocco ......
tu probabilmente hai qualcosa a livello di tabella, o di DataBase ( escluderei di Server )

a parer mio si tratta di qualcosa di volutamente messo dal progettista del DB
....... e io prima di rimuoverlo mi chiederei perché è stato messo

....... e entro domani ho 2 soluzioni che poi vi condivido. .........

Sono curioso di vedere cosa ci propone Microsoft,
magari imparo qualcosa (che non fa mai male )

.

[URANIO]

Ma ritengo che non ti servano soluzioni particolari, .....

SQLServer di Default non ha nessun blocco ......
tu probabilmente hai qualcosa a livello di tabella, o di DataBase ( escluderei di Server )
.

Leggendo il link precedente e facendo qualche ricerca sembra che i driver ODBC abbiano questo comportamento, fanno il lock della tabella di default (ormai non li uso più).
Secondo me la soluzione è O cambiare driver di acceso, usando un OLEDB che sicuramente non ha questo comportamento, oppure specificare qualcosa nella stringa di connesione utilizzata in modo da forzare il comportamento dovuto.

[ibernet]

Ciao Uranio, hai colto in pieno,
anche gli altri sistemi però finchè non terminano la lettura dei dati non permette l'eliminazione del dato in quanto viene rispettata una coda, in questo caso se un utente poco smart fa una query a campi incrociati potenzialmente la tabella può rimanere allocata per molto tempo.
Il driver ODBC usato in Access ha in più la casistica che permette la lettura di un'anteprima e la tiene loccata finchè manualmente non si chiude questa anteprima.

Ad ogni modo le due soluzioni per risolvere questi problemi di lock sono queste:

Sistema blando (ma applicabile nel mio caso):
- Fare il select chiudendo l'istruzione con un "with (nolock)"
questo comando permette la lettura del dato senza allocare la tabella, quindi nel mio specifico caso, per quella fetta di utenti che usa per forza il driver ODBC, non li farò accedere alla tabella fisica ma gli farò vedere una vista logica che sarà scritta così "Select * from tabella with (nolock)"
Così facendo quando leggeranno i dati da Access non avranno modo di allocarmi la tabella.

Sistema molto più efficiente:
- Usare il db tempdb a supporto per avere sempre un dato consistente anche se admin sta aggiornando i dati.

READ_COMMITTED_SNAPSHOT
Abilitare il READ_COMMITTED_SNAPSHOT nelle opzioni del database
Informazioni:
"Snapshot Isolation in SQL Server" (https://msdn.microsoft.com/en-us/lib...v=vs.110).aspx)
"Enabling Row Versioning-Based Isolation Levels" (https://technet.microsoft.com/en-us/...=sql.105).aspx)
"Displaying Row Versioning Information" (https://technet.microsoft.com/en-us/...=sql.105).aspx)
"Understanding Row Versioning-Based Isolation Levels" (https://technet.microsoft.com/en-us/...=sql.105).aspx)
"Using Row Versioning-based Isolation Levels" (https://technet.microsoft.com/en-us/...=sql.105).aspx)

In questo caso sarebbe anche opportuno verificare che la configurazione del tempdb rispecchi le best practices Microsoft che trovate qui https://support.microsoft.com/en-us/kb/2154845d
--------------------------------------------------------------------------------------------------

Nel mio caso applicherò la prima soluzione, mi basta e avanza, quando riuscirò a respirare approfondirò bene il secondo sistema che mi sembra molto più efficiente e sicuro.

Grazie a tutti per l'attenzione e il supporto, è stato molto apprezzato