Soci blog

Sokan azt hiszik, ha beraknak néhány tsql utasítást egy tranzakciós blokkba, akkor máris védettek más kapcsolatok hatásaitól. Természetesen ez messzemenőkig nem igaz, a default read commmitted szint mellett simán szúrhatnak be vagy törölhetnek sorokat, miközben egy select dolgozik rajta, mivel a select mindig csak azon a kis tartományon tart locokot, amit éppen olvasgat. Azon a pár lapon pl.

Ez egész gondolatmenet innen indult. A szerzÅ‘ azt bizonygatja, tök jó a NOLOCK hint, mert így gyorsabb lesz a query. Persze, valamelyest biztos, hisz ilyenkor egyáltalán nem rak lockokat a szerver az olvasott sorokra. A hozzászólásokban persze jól odamondják a jóembernek, hogy ne beszélj ilyenekrÅ‘l, mert sok hozzá nem értÅ‘ ember azt hiszi, ez valami tuning lehetÅ‘ség, miközben súlyos adathibák léphetnek fel a read UNcommitted szinten, a NOLOCK miatt.Â

Ez egyik hozzászólásban volt egy érdekes gondolat:

“Anyway, there is a little catch with NOLOCK however.  SQL Server mostly uses unordered clustered index scans when NOLOCK is specified, this can cause duplicate records to be returned when page splits occur while your query is scanning the index.”

Szóval nem feltétlen csak olyan sorok jöhetnek be, amiket esetleg egy másik tranzakció még visszavon, hanem még ugyanaz a sor is bejöhet duplikálva. Persze, aki ésszel használja, pl. statisztikai funkciókra, azt ez nem értekli, de fontos, hogy mindenki realizálja a NOLOCK veszélyeit.

A hozzászólásokban van egy link erre a cikkre, innen bedig erre. Mindkettő az izolációs szintek anomáliát boncolgatja, érdemes átfutni őket.

Mi a helyzet a 2005-ben, a snapshot read committed bekapcsolása után? Nos, ebben az esetben a read committed szintű izolációs szint esetén a select a párhuzamos módosítás előtti eredményeket adja vissza, ami egy bár időben eltolt, de konzisztens állapotot állít elő. Ezt a szintet nyilván azért szeretjük, mert az írók nem blokkolják az olvasókat és vica versa. Ugyanezért szokták bevetni 2000-ben a NOLOCKot, csak itt nincs meg viszont az inkonzisztens adatok veszélye. Ezért szeretjük ezt az újítást, és erre irigykedett minden sql server programozó az orákulumra 2005 előtt.

De persze ennek is meg van az ára. Minden egyes, a select futása alatti módosítást bevezet a szerver a tempdb-be, így mikor odaér a select a módosított adathoz, akkor átnyúlnak a tempdbbe, és onnak veszik el a sor módosítás előtti állapotát. Ez azért eléggé erőforrásigényes lehet. Különösen érdekes lehet a helyzet, ha egy order by-os selectet kérünk le. Ha az order by pont a clustering key mentén működik, akkor normál esetben egyszerűen olvasni kell a szervernek az adatlapokat, sorban, ez piszok gyors. Mi van viszont ebben a helyzetben? Foglalmam sincs, ilyenkor hogyan hajtja végre a kérést. Ha valaki tudja, ne tartsa magában. Köszönöm.

This entry was posted on Friday, January 26th, 2007 at 4:34 pm and is filed under Adatbázisok, SQL Server, SQL Server 2005, Szakmai élet. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.