\nSokan azt hiszik, ha beraknak n\u00e9h\u00e1ny tsql utas\u00edt\u00e1st egy tranzakci\u00f3s blokkba, akkor m\u00e1ris v\u00e9dettek m\u00e1s kapcsolatok hat\u00e1sait\u00f3l. Term\u00e9szetesen ez messzemen\u0151kig nem igaz, a default read commmitted szint mellett sim\u00e1n sz\u00farhatnak be vagy t\u00f6r\u00f6lhetnek sorokat, mik\u00f6zben egy select dolgozik rajta, mivel a select mindig csak azon a kis tartom\u00e1nyon tart locokot, amit \u00e9ppen olvasgat. Azon a p\u00e1r lapon pl.\n<\/p>\n
\nEz eg\u00e9sz gondolatmenet innen<\/a> indult. A szerz\u0151 azt bizonygatja, t\u00f6k j\u00f3 a NOLOCK hint, mert \u00edgy gyorsabb lesz a query. Persze, valamelyest biztos, hisz ilyenkor egy\u00e1ltal\u00e1n nem rak\u00a0lockokat a szerver az olvasott sorokra.\u00a0A hozz\u00e1sz\u00f3l\u00e1sokban<\/a> persze j\u00f3l odamondj\u00e1k a j\u00f3embernek,\u00a0hogy\u00a0ne\u00a0besz\u00e9lj ilyenekr\u0151l, mert sok\u00a0hozz\u00e1 nem \u00e9rt\u0151 ember azt hiszi, ez valami tuning lehet\u0151s\u00e9g, mik\u00f6zben s\u00falyos adathib\u00e1k l\u00e9phetnek fel a read UNcommitted szinten, a NOLOCK miatt.\u00a0\n<\/p>\n Ez egyik hozz\u00e1sz\u00f3l\u00e1sban volt egy \u00e9rdekes gondolat:<\/p>\n \n“Anyway, there is a little catch with NOLOCK however.\u00a0 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.<\/span>”\n<\/p>\n \nSz\u00f3val nem felt\u00e9tlen csak olyan sorok j\u00f6hetnek be, amiket esetleg egy m\u00e1sik tranzakci\u00f3 m\u00e9g visszavon, hanem m\u00e9g ugyanaz a sor is bej\u00f6het duplik\u00e1lva. Persze, aki \u00e9sszel haszn\u00e1lja, pl. statisztikai funkci\u00f3kra, azt ez nem \u00e9rtekli, de fontos, hogy mindenki realiz\u00e1lja\u00a0a NOLOCK vesz\u00e9lyeit.\n<\/p>\n \nA hozz\u00e1sz\u00f3l\u00e1sokban van egy link erre a cikkre<\/a>, innen bedig erre<\/a>. Mindkett\u0151 az izol\u00e1ci\u00f3s szintek anom\u00e1li\u00e1t boncolgatja, \u00e9rdemes \u00e1tfutni \u0151ket.\n<\/p>\n \nMi a helyzet a 2005-ben, a snapshot\u00a0read committed\u00a0bekapcsol\u00e1sa ut\u00e1n? Nos, ebben az esetben a read committed szint\u0171 izol\u00e1ci\u00f3s szint eset\u00e9n a select a p\u00e1rhuzamos m\u00f3dos\u00edt\u00e1s el\u0151tti eredm\u00e9nyeket adja vissza, ami egy b\u00e1r id\u0151ben eltolt, de konzisztens \u00e1llapotot \u00e1ll\u00edt el\u0151. Ezt a szintet nyilv\u00e1n az\u00e9rt szeretj\u00fck, mert az \u00edr\u00f3k nem blokkolj\u00e1k az olvas\u00f3kat \u00e9s vica versa. Ugyanez\u00e9rt szokt\u00e1k bevetni 2000-ben a NOLOCKot, csak itt nincs meg viszont az inkonzisztens adatok vesz\u00e9lye. Ez\u00e9rt szeretj\u00fck ezt\u00a0az \u00faj\u00edt\u00e1st, \u00e9s erre irigykedett minden sql server programoz\u00f3 az\u00a0or\u00e1kulumra 2005 el\u0151tt.\n<\/p>\n \nDe persze ennek is meg van az \u00e1ra. Minden egyes, a select fut\u00e1sa alatti m\u00f3dos\u00edt\u00e1st bevezet a szerver a tempdb-be, \u00edgy mikor oda\u00e9r a select a m\u00f3dos\u00edtott adathoz, akkor \u00e1tny\u00falnak a tempdbbe, \u00e9s\u00a0onnak veszik el a\u00a0sor m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapot\u00e1t. Ez az\u00e9rt el\u00e9gg\u00e9 er\u0151forr\u00e1sig\u00e9nyes lehet. K\u00fcl\u00f6n\u00f6sen \u00e9rdekes lehet a helyzet, ha egy order by-os selectet k\u00e9r\u00fcnk le. Ha az order by pont a clustering\u00a0key ment\u00e9n m\u0171k\u00f6dik, akkor norm\u00e1l esetben egyszer\u0171en olvasni kell a szervernek az adatlapokat, sorban, ez piszok gyors. Mi van viszont ebben a helyzetben?\u00a0Foglalmam sincs, ilyenkor hogyan hajtja v\u00e9gre a k\u00e9r\u00e9st. Ha valaki tudja, ne tartsa mag\u00e1ban. K\u00f6sz\u00f6n\u00f6m.<\/p>\n","protected":false},"excerpt":{"rendered":" Sokan azt hiszik, ha beraknak n\u00e9h\u00e1ny tsql utas\u00edt\u00e1st egy tranzakci\u00f3s blokkba, akkor m\u00e1ris v\u00e9dettek m\u00e1s kapcsolatok hat\u00e1sait\u00f3l. Term\u00e9szetesen ez messzemen\u0151kig nem igaz,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,4,30,21],"tags":[],"class_list":["post-194","post","type-post","status-publish","format-standard","hentry","category-adatbazisok","category-szakmai-elet","category-sql-server","category-sql-server-2005"],"_links":{"self":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/194","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=194"}],"version-history":[{"count":0,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/194\/revisions"}],"wp:attachment":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}