v praci som narazil na jeden (celkom zaujimavy) problem nad ms sqlserver, s ktorym zase nemam az take prenikave skusenosti, tak mi chvilku trvalo, kym som ho vyriesil. mozno bude niekoho zaujimat a niekomu sa bude hodit (myslim, ze je to jedna z beznejsich chyb). popisem priklad z praxe, kazdy, kto vie o com hovorim, by si tam mal najst potrebnu informaciu:

podmienky:

- majme tabulku J a tabulku V, ktore obsahuju informacie o ulohe. v J su standartne informacie o ulohe a vo V su premenne nabindovane k J cez J.id.
- majme dva druhy procesov:
1) update process - UPDATE queries v transakcii:

BEGIN TRAN
UPDATE J ...
UPDATE V ...
UPDATE V ...
...
UPDATE V ...
COMMIT

2) select process - SELECT query nad J

SELECT COUNT(*) from J ...

- majme takychto procesov pustenych niekolko (produkcna prevadzka bola cca 2 UPDATE + 2 SELECT viacmenej simultanne, ja som to testoval v 4/2 pri intervaloch spustania rand(0, 1000) milisekund)

nastava problem: DEADLOCKu nad SELECT query (process typu #2)

riesenie: skusal som vsetko, do primitivnych zaobalovaciek selectu do transakcie, cez read uncommited transakcie cez isolation level nad query, pomohlo - zda sa - nieco velmi trivialne, zakazanie uzamykania selectu pri count(*), co nam je vlastne aj tak jedno, kedze pri tom mnozstve poziadaviek tie cisla nemusia byt 100% presne a to, ze sa objavi odchylka je aj tak malo pravdepodobne. Takze spravna syntax SELECT query v procese typu #2 je:

SELECT count(*) from J (NOLOCK) where ...


test: 30000 update query v kazdom zo 4 procesov + 1200 select query v kazdom z 2 procesov bez deadlocku (inokedy mi to uz najneskor pri selecte#200 hodilo deadlock... takze dufam, ze je to ok

---

EDIT

nakoniec som - podla mojho nazoru - vybral este lepsie riesenie z ponukanych.
kedze NOLOCK funguje ako read uncommitted (tzn, berie do uvahy vsetko, aj neCOMMITnute riadky), existuje este jedna lepsia alternativa a to READPAST, ktora neberie do uvahy nic, co je locknute (tzn, riadky, ktore su prave spracovavane ignoruje). v tomto pripade mi to pride rozumnejsie, kazdopadne COUNT(*) je ako taky dost nespolahlivy a nikdy by sa nemal pouzivat ako dolezity udaj.

moja finalna query:

SELECT count(*) from J (READPAST) where ...