Am 2 tabele:

1. X - cimp PK idx1, cimp x1(numar rinduri aprox 2.000.000)

2. Y - cimp PK  idy1, cimp FK idx1 , cimp idz1, cimp valoare (nr rinduri aprox 3.000.000)
792

Am index pe FK idX1 pe tabela Y pentru rapiditate

Am facut un  script de testare, care consta, in afara de select*uri pe X si pe Y, in urmatoarele:

inserez in Y cu null pe idx1 de mai multe ori (maxim 10, dupa cite am observat) si cu acelasi idz1

insert in X si  iau valoarea lui idx1

fac update pe Y cu  idx1 obtinut where idz1 = valoareIDz1 si idx1 is null

Ei, pe acest update da deadlock daca rulez 2 script-uri concurent .

Transaction (Process ID 85) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
 

(Cum stiu ca pe update  - dupa ce am citit pe net tot felul de tot felul despre dead=lock - cum se vad - si l-am vazut, pina la urma, din Sql Server Logs + scriind la print-uri de am turbat ... Am pus si SQL Server Profiler si am vazut si acolo liniile ...)

Ce e ciudat este ca se updateaza doar 2-10 rinduri 

Daca rulez un singur script nu da eroare

Daca scot index-ul de pe  IdX1 de pe tabela Y - pot sa rulez si 100 de script-uri concurent  - tot nu da eroare, dar dureaza ca naiba.

Stiti cumva ce as putea face -nu sa schimb codul - este ultima optiune   - ca sa nu mai dea deadlock ?

 Baza de date este SQL 2000

Dupa cate imi dau seama acel "cimp PK idx1" este identity (ca din cate stiu nu poate o cheie primara sa fie null), apoi il folosesti pentru a actualiza Y; eu zic sa folosesti functia SCOPE_IDENTITY() care da ultimul identity bagat.

ggciubuc:

Dupa cate imi dau seama acel "cimp PK idx1" este identity (ca din cate stiu nu poate o cheie primara sa fie null), apoi il folosesti pentru a actualiza Y; eu zic sa folosesti functia SCOPE_IDENTITY() care da ultimul identity bagat.

 

Folosesc scope_identity ... alta idee?

Diana:

Cum arata scriptul pe care il folosesti?

Mare * in principiu am spus ce face

 "<operatii, printre care si select din Y si din X with(nolock) >

inserez in Y cu null pe idx1 de mai multe ori (maxim 10, dupa cite am observat) si cu acelasi idz1

insert in X si  iau valoarea lui idx1

fac update pe Y cu  idx1 obtinut where idz1 = valoareIDz1 si idx1 is null

<operatii>

" 

Ce te-ar mai putea interesa 

WITH (UPDLOCK) - e mai tare decit with(nolock) ?

Se poate folosi si la update? 

NOLOCK, READUNCOMMITED 

Specifies that dirty reads are allowed. No shared locks are issued to prevent other transactions from modifying data read by the current transaction, and exclusive locks set by other transactions do not block the current transaction from reading the locked data.

UPDLOCK Specifies that update locks are to be taken and held until the transaction completesAcquiring an update lock does not prevent others from reading the same data, but it does ensure that you're first in line to upgrade your lock to an exclusive lock if you subsequently decide to modify the locked data

* "quote"din Books Online si Inside SQL Server 2000*

Pentru "update" se pot folosi:

         FASTFIRSTROW
        | HOLDLOCK
        | PAGLOCK
        | READCOMMITTED
        | REPEATABLEREAD
        | ROWLOCK
        | SERIALIZABLE
        | TABLOCK
        | TABLOCKX
        | UPDLOCK

 - lista figureaza in BOL SQL 2005 sub numele de "table hint limited". 

* Folosesti cumva alt "isolation level" decat cel "default"? 

nu folosesc alt isolation level decit cel default ... am incercat sa il pun pe minim dar tot nu am reusit.

Scuza-ma ca te pun la munca, dar poti sa imi indici exact linkul catre un exemplu de update care foloseste updlock ?Si care e cel mai "mic" ? UPDLock ?

Un exemplu din Inside SQL Server 2000:

USE pubs
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
SELECT * FROM authors (UPDLOCK) WHERE au_id='172-32-1176'
-- Add 5 sec sleep to widen the window for the deadlock
WAITFOR DELAY '00:00:05' 
UPDATE authors SET au_lname='Updated by '
    + CONVERT(varchar, @@spid) WHERE au_id='172-32-1176'
COMMIT TRAN

 Ceva asemenator aici:

http://mikedimmick.blogspot.com/2004/03/selectupdate-problem-or-why-updlock.html

* Putzin "off topic" - in articolul de mai jos, vezi "locking escalation behavior ... for a specific index"

Diana - vad ca updlock se foloseste pentru SELECT , nu pentru UPDATE . Si, pe deasupra , 1. eu folosesc nolock pentru select si 2. scriptul nu se deadlock la 1 run - ci la 2 concurente

In articolul recomandata nu vad  "locking escalation behavior ... for a specific index"

Imi poti da linkul, te rog ?

Sorry again...

http://www.sql-server-performance.com/reducing_locks_hints.asp 

Ok... oricum, avind in vedere ca am (nolock) - banui ca e folosirea (nolock) e mai buna decit folosirea (updlock) in SQL Server

Am verificat scriptul  - si merge la fel cu (nolock) ...