I deadlock sono un "fenomeno" del tutto normale in un dbms. Per la vastità dell'argomento non è possibile esaurire la discussione in un post ma ti rimando a questo mio articolo su "Il controllo della concorrenza in SQL Server 7.0" i cui principi esposti sono tuttora validi in SQL Server 2000

http://italy.mvps.org/MVPs/lbianchi/art_IsolationLevel.htm

Bye

target ha scritto:

Wow, ho visto che è un articolone...

stampo e... imparo

ThanX

Credimi... è solo un bignami... ;-)

Bye

salve,
marcoorru ha scritto:

.....
Ultimamente per problemi di sovraccarico del db (era diventato molto lento)abbiamo pensato di modificare l'opzione Recovery Model da 'full' a 'simple' andando nelle proprieta del db da Enterprise Manager e poi nella cartella 'Options'

sembra proprio che da quel momento siano iniziati ad apparire gli errori di 'Transaction deadlocked...'

DOMANDA è possibile che ci sia una relazione tre la mia impostazione e l'errore riscontrato????

grazie mille

no, il cambiamento di modello di recovery non puo' influire sulla gestione dei lock..
modificando il modello di recovery cambia "solo" ( ) la capacita' di SQL Server di gestire recovery puntuali e backup di transaction log, vista la natura stessa del recovery mode "simple", che altro non fa che applicare alle pagine dati le modifiche apportate e presenti nel log delle transazioni al momento dell'esecuzione dei checkpoints, comprendendo nello stesso tempo alla eliminazione virtuale dei LSN (Log Sequence Number) relativi alle transazioni "scadute", rendendo quindi possibile il riciclo dello spazio da loro utilizzato ..

molto brevemente, SQL Server gestisce il transaction log internamente con dei punti di transazione LSN (Log Sequence Number)..
Tutte le operazioni che vengono effettuate scrivono nel log un'entry che descrive esattamente le modifiche apportate e tutte le entries che fanno capo alla stessa transazione vengono raggruppate in modo da poter abortire o committare l'itera operazione.
Il buffer manager garantisce che il transaction log sia scritto prima dell'esecuzione delle modifiche, e cio' avviene scrivendo nell'heder di ogni data page modificata il LSN al quale la modifica si riferisce. Le cosidette Dirty pages vengono scritte fisicamente su disco al momento in cui il LSN della pagina e' inferiore al LSN nella ultima pagina del log.
L'utilizzo dello spazio fisico nel log delle transazioni e' circolare, nel senso che avviene per scritture sucessive al primo LSN dallo spazio iniziale
di questo.
Al momento della scrittura fisica nelle pagine dati, tutti i LSN committati saranno annullati e lo spazio da loro occupato viene reso libero; cio' puo' causare l'utilizzo degli ultimi Kb del log ed inutilizzazione della parte iniziale dell'allocazione.

saluti

marcoorru ha scritto:

visto che come mi dici le due cose non sono legate mi chiedo allora come si possa spiegare che un applicativo funzionante da diversi mesi tutt'ad un tratto inizi a dare questo tipo di errori?

Se nel frattempo hai letto l'articolo ti sarai già confortato del fatto che la modifica del recovery model non centra nulla (come ti ha già detto Andrea) ne con i deadlock e tantomeno con le prestazioni/tempi di risposta. Le cause dei deadlock sono quelle che hai letto nell'articolo, ovvero derivanti dalla richiesta incrociata di risorse da parte di 2 connessioni ognuna delle quali applica un blocco di tipo incompatibile con quello che l'altra intende applicare. Partendo dal presupposto che l'applicazione di accesso ai dati non sia cambiata nel corso del tempo, posso pensare ad un incremento delle attività degli utenti (pura ipotesi) e ad un progressivo aumento dello stato di frammentazione degli indici (quasi certezza) che provoca direttamente un aumento del numero di IO (fisici o logici) necessari per soddisfare una query e, quindi, un aumento dei tempi di esecuzione di ogni singola query. Provvedi quindi ad una ricostruzione completa degli indici ma non aspettarti da questa dei miracoli in quanto servirebbe solo a ridurre le occorrenze di deadlock ma un intervento a livello di codice per gestire l'evenienza è l'unica attività risolutiva...

E' possibile che si sia 'rovinato' qualcosa all'interno del mio SQL?

...questo è un evento sempre possibile, ma non si manifesta di certo con dei deadlock... ;-)

Bye