Opdatering af kolonne giver deadlock

Det kan vi ikke vide uden at kende mere til dit system. En simpel ting du kan prøve er

update mintabel with (rowlock)
set minkolonne = 1
where id = 123

(og andre steder) og måske "WITH (NOLOCK)" på SELECTs - men ikke hvis du har brug for at låse.

Generelt boer du vaere forberedt paa at skulle reexecute p.g.a. deadlocks.

Men naturligvis vil det hjaelpe at saenke transaction isolation level, men
kan du leve med read uncommitted ?

Erik: Er "with rowlock" egentligt mindre eller mere låsning end der ville være pr. default.

Kan effekten af dette være, at det i stedet er de andre kald som skal bruge tabellen, der fejler med deadlock i stedet?

Arne_V: Ohh, det var en idé. Jeg kan lave en try catch i min kode og så køre metoden igen, f.eks. op til 3 gange før jeg giver op?

Ang. "read uncommitted", kan jeg gøre det isoleret på dette kald eller er det nødvendigt at det findes som en overordnet database-indstilling?

Det er helt normalt at goere den slags.

Test dog paa exception type - ikke alle exceptions er vaerd at genproeve paa.

Transaction isolation level er per connection/transaction level. Men det skal nok
laves paa flere, medmindre det er den her SQL som blokerer for sig selv.

"Jeg skal løse problemet i netop dette sql-kald og vil derfor helst ikke have alternative løsninger eller gode råd om databasedesign."

Det ses jo desværre ofte at et dårligt designet system kan give problemer, så jeg forstår ikke helt den modvillighed fra starten!

Rowlock giver mindre låsning - default er at låse alle rækker, der ligger på samme "page", her nøjes du med rækken. Det giver mere administration for sql-serveren, men derudover er den i sig selv ufarlig.

Men det hjælper ikke kun at lave det i den UPDATE du viser, hvis rækkens "page" er låst andetsteds.

Og det hjælper heller ikke en dyt, hvis du faktisk har en deadlock på række-niveau.

Man kan sikkert regne på, om det i en given applikation kan betale sig med page-låse med enkelte deadlocks, i forhold til række-låse med ingen/færre deadlocks.

Tak for hjælpen, erik og arne, jeg blev meget klogere på hvordan det hele hænger sammen. Jeg vil først prøve at fange deadlocks i koden og kalde igen - da det er det eneste sted der sker deadlock, burde det løse problemet. Men jeg er helt klart mere opmærksom på låsning af sider og rækker næste gang systemet skal opdateres.

Vil en være sød at lægge et svar så vi kan lukke?

janus, jeg skrev sådan, netop fordi jeg godt ved mange problemer stammer fra dårligt design, så det har jeg ikke brug for at få at vide. Jeg har alligevel ikke mulighed for at omdesigne.

Ingen point til mig, tak.

svar