locked
lockolasi mizeriak RRS feed

  • Question

  • Sziasztok
    szeretnem vegre megerteni, hogy hogyan is muxik ez a lock, mert a meglevo alap ismereteim alapjan ha van egy tablam amin 1 db rekordot updatelok (ossz vissz 100 rekord van benne) es egy masikat szeretnek select-tel olvasni akkor nem lehet gond.
    de megis van.
    csak akkor nincs, ha clustered indexet rakok az azonosito mezore (a sima index nem volt eleg)
    szuksegem lenne valami jo, ertheto, peldakkal illusztralt leirasra errol az egesz locking mizeriarol valahol amit jol elovasok probalgotk A-t meg B-t es vegul megertem :)
    ha tudtok ilyen linket akkro ne kimeljetek :)

    koszi!

    Potyos
    Wednesday, February 3, 2010 1:42 PM

Answers

  • Szia Pöttyös,
    Biztos vagyok benne, hogy a zárolást tökéletesen érted. :)
    Referenciának itt a BOL megfelelő fejezete:
    http://msdn.microsoft.com/en-us/library/ms190615(SQL.90).aspx

    Amit nem vettél figyelembe, az a lekérdezési terv lehet. Nézd meg a következőket. (SQL 2008-on futtattam, de a korábbi verzókon is hasonló eredményt várhatsz.)

    use tempdb
    go
    create table t(a int identity(1,1), b char(10) default 'qwe')
    go
    insert into t default values
    go 100 -- 100 sor beszúrás
    create index i on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- table scan
    go
    drop index t.i
    go
    create unique index i2 on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- index seek + lookup
    go
    drop index t.i2
    go
    create clustered index i3 on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- clustered index seek
    go

    Tehát egy "egyszerű" index esetén az optimalizáló végigolvassa a táblát. Ez fennakad minden sor szintű záron, ami esetleg a táblán van.  Kis méretű tábla esetén az optimalizáló könnyen választ table scan-t, hacsak jó oka nincs rá, hogy ne tegye.

    Ilyen ok, ha egyedi az index - ekkor biztosan csak egy lookup kell; illetve, ha fürtözött az index, mert ekkor nem kell lookup.


    Károly
    • Marked as answer by Pötyös Wednesday, February 10, 2010 4:35 PM
    Friday, February 5, 2010 4:38 PM

All replies

  • Szia Pöttyös,
    Biztos vagyok benne, hogy a zárolást tökéletesen érted. :)
    Referenciának itt a BOL megfelelő fejezete:
    http://msdn.microsoft.com/en-us/library/ms190615(SQL.90).aspx

    Amit nem vettél figyelembe, az a lekérdezési terv lehet. Nézd meg a következőket. (SQL 2008-on futtattam, de a korábbi verzókon is hasonló eredményt várhatsz.)

    use tempdb
    go
    create table t(a int identity(1,1), b char(10) default 'qwe')
    go
    insert into t default values
    go 100 -- 100 sor beszúrás
    create index i on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- table scan
    go
    drop index t.i
    go
    create unique index i2 on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- index seek + lookup
    go
    drop index t.i2
    go
    create clustered index i3 on t(a)
    go
    select * from t where a=5
    -- nem kell futtani, csak nézd meg a lekérdezési tervet
    -- clustered index seek
    go

    Tehát egy "egyszerű" index esetén az optimalizáló végigolvassa a táblát. Ez fennakad minden sor szintű záron, ami esetleg a táblán van.  Kis méretű tábla esetén az optimalizáló könnyen választ table scan-t, hacsak jó oka nincs rá, hogy ne tegye.

    Ilyen ok, ha egyedi az index - ekkor biztosan csak egy lookup kell; illetve, ha fürtözött az index, mert ekkor nem kell lookup.


    Károly
    • Marked as answer by Pötyös Wednesday, February 10, 2010 4:35 PM
    Friday, February 5, 2010 4:38 PM
  • szia

    Koszi, ez a link eleg jo es eleg erthetoen volt leirva :)

    Potyos
    Wednesday, February 10, 2010 4:35 PM