{"id":809,"date":"2009-02-25T12:17:32","date_gmt":"2009-02-25T11:17:32","guid":{"rendered":"http:\/\/soci.hu\/blog\/?p=809"},"modified":"2014-05-02T08:32:06","modified_gmt":"2014-05-02T06:32:06","slug":"uj-cikkem-snapshot-elszigetelesi-szint-az-sql-server-2008-ban","status":"publish","type":"post","link":"https:\/\/soci.hu\/blog\/index.php\/2009\/02\/25\/uj-cikkem-snapshot-elszigetelesi-szint-az-sql-server-2008-ban\/","title":{"rendered":"Snapshot elszigetel\u00e9si szint a SQL Server 2005-t\u0151l"},"content":{"rendered":"

El\u00e9gg\u00e9 elfeledett t\u00e9ma ez az SQL Serverben, pedig \u00f6nmag\u00e1ban ez az \u00faj szolg\u00e1ltat\u00e1s eladta volna az SQL 2005-\u00f6t.
\nUpdate: kor\u00e1bban itt egy url volt a technetre, de onnan leker\u00fclt a cikk, ez\u00e9rt felt\u00f6lt\u00f6ttem ide:<\/p>\n

Bevezet\u0151 az elszigetel\u00e9si szintekbe<\/strong>
\nAz SQL Servernek biztos\u00edtani kell a p\u00e1rhuzamosan fut\u00f3 adatm\u00f3dos\u00edt\u00f3 \u00e9s olvas\u00f3 folyamatok b\u00e9k\u00e9s egym\u00e1s mellett \u00e9l\u00e9s\u00e9t. A p\u00e1rhuzamos m\u0171veletek egym\u00e1sra hat\u00e1s\u00e1t teljesen meg lehetne akad\u00e1lyozni, \u00e1m ez s\u00falyosan visszavetn\u00e9 az adatb\u00e1zis kiszolg\u00e1l\u00e1si sebess\u00e9g\u00e9t. Ehhez egyszer\u0171en csak be kellene rakni egy kapu\u0151rt, aki addig nem enged be egy \u00faj tranzakci\u00f3t, m\u00edg az \u00e9ppen fut\u00f3 konkl\u00fazi\u00f3ra nem jutott, azaz committal vagy rollback-kel v\u00e9get nem \u00e9rt. K\u00f6nnyen bel\u00e1that\u00f3, hogy ezzel kiirtan\u00e1nk minden p\u00e1rhuzamoss\u00e1got az adatb\u00e1ziskezel\u0151b\u0151l, egyfelhaszn\u00e1l\u00f3sra degrad\u00e1ln\u00e1nk.
\nA k\u00e1osz \u00e9s a soros\u00edtott tranzakci\u00f3k k\u00f6z\u00f6tt vannak kompromisszumos k\u00f6zbens\u0151 szintek, ezek az elszigetel\u00e9si szintek, isolation level-\u00f6k. K\u00f6nny\u0171 elk\u00e9pzelni, hogy k\u00e9t \u00edr\u00f3 m\u0171veletet, amelyek ugyanarra az er\u0151forr\u00e1sra, pl. t\u00e1bla sorra vonatkoznak, nem lehet p\u00e1rhuzamos\u00edtani. \u00cdgy az elszigetel\u00e9si szintek a p\u00e1rhuzamos \u00edr\u00f3 \u00e9s olvas\u00f3 folyamatok k\u00f6z\u00f6tti \u00e1that\u00e1st tudj\u00e1k szab\u00e1lyozni. Eg\u00e9szen pontosan, az elszigetel\u00e9si szintek a selectekre hatnak. Az insert, update, delete-re nem, ezt \u00e9rdemes a fej\u00fcnkbe v\u00e9sni m\u00e1r az elej\u00e9n.<\/p>\n

A k\u00e9rd\u00e9sek a k\u00f6vetkez\u0151k:
\n1.\tL\u00e1that-e egy select olyan adatokat, amelyeket egy m\u00e1sik, nyitott tranzakci\u00f3 \u00e9ppen m\u00f3dos\u00edt (dirty records)?
\n2.\tElv\u00e1rhat\u00f3-e, hogy egy tranzakci\u00f3ban a kiolvasott adatokat ugyanazon selecttel \u00fajra kiolvasva pontosan ugyan\u00fagy n\u00e9znek ki a sorok, mint kor\u00e1bban, vagy megv\u00e1ltozhatnak a k\u00e9t olvas\u00e1s k\u00f6z\u00f6tt, azaz, megism\u00e9telhet\u0151-e az olvas\u00e1s (repeatable read)?
\n3.\tMi van, ha az el\u0151bbi olvas\u00e1sok k\u00f6z\u00f6tt \u00faj sorokat sz\u00farnak be a t\u00e1bl\u00e1ba? L\u00e1that\u00f3v\u00e1 v\u00e1lnak-e ezek a szellem sorok a m\u00e1sodik olvas\u00e1sra (phantom records)?<\/p>\n

Az SQL Server mindh\u00e1rom k\u00e9rd\u00e9sre ad v\u00e1laszokat, m\u00e1r id\u00e9tlen id\u0151k \u00f3ta. <\/p>\n

A READ UNCOMMITTED elszigetel\u00e9si szinten fut\u00f3 select l\u00e1thatja az \u00e9ppen m\u00f3dos\u00edt\u00e1s alatt \u00e1ll\u00f3 sorokat, amelyeket lehet, hogy egy m\u00e1sodperc m\u00falva m\u00e1r vissza is g\u00f6rgetnek.
\nA READ COMMITTED alap\u00e9rtelmezett szinten nem l\u00e1tunk piszkos rekordokat, de belefuthatunk a nem megism\u00e9telhet\u0151 olvas\u00e1s \u00e9s a fantom sorok probl\u00e9m\u00e1j\u00e1ba.
\nA REPEATABLE READ szinten garant\u00e1lj\u00e1k az olvas\u00e1sok megism\u00e9telhet\u0151s\u00e9g\u00e9t, de fantom sorok m\u00e9g \u00edgy is megjelenhetnek.
\nA SERIALIZABLE szint az \u00f6sszes olvas\u00e1si anom\u00e1li\u00e1ra gy\u00f3gy\u00edr, cser\u00e9be a p\u00e1rhuzamoss\u00e1g nagyon er\u0151sen lecs\u00f6kken.
\nEzen szinteket a z\u00e1rol\u00e1sok idej\u00e9nek \u00e9s m\u00f3dj\u00e1nak vari\u00e1l\u00e1s\u00e1val k\u00e9pes el\u0151\u00e1ll\u00edtani a szerver, a r\u00e9szletekr\u0151l egy r\u00e9gebbi cikkemb\u0151l \u00e9rdemes t\u00e1j\u00e9koz\u00f3dni.
\nhttp:\/\/soci.hu\/publications.aspx
\nJ\u00f3l l\u00e1that\u00f3, hogy az elszigetel\u00e9si szintek megfelel\u0151 megold\u00e1st adnak a k\u00fcl\u00f6nb\u00f6z\u0151 \u00e9lethelyzetekben fell\u00e9p\u0151 p\u00e1rhuzamoss\u00e1gi probl\u00e9m\u00e1kra. Vagy m\u00e9gsem? Ha \u00edgy lenne, nem j\u00f6tt volna l\u00e9tre ez a cikk.<\/p>\n

A Snapshot elszigetel\u00e9si szint alapjai<\/strong>
\nAz el\u0151z\u0151 szintek k\u00f6z\u00f6s ideol\u00f3giai \u00e9s technol\u00f3giai jellemz\u0151je, hogy z\u00e1rol\u00e1ssokkal v\u00e9dik meg egym\u00e1st\u00f3l a p\u00e1rhuzamos folyamatokat. Ez elvileg korrekt megold\u00e1st ad, de id\u0151nk\u00e9nt t\u00fals\u00e1gosan lekorl\u00e1tozza a szerver p\u00e1rhuzamoss\u00e1g\u00e1t.
\nJ\u00f6n egy folyamat, ind\u00edt egy tranzakci\u00f3t, amiben neki\u00e1ll m\u00f3dos\u00edtani egy t\u00e1bla fel\u00e9t. A m\u00f3dos\u00edt\u00e1s mondjuk 5 percig tart. Ez id\u0151 alatt READ COMMITTED vagy szigor\u00fabb szinten senki nem tudja olvasni a t\u00e1bla m\u00f3dos\u00edt\u00e1s alatt \u00e1ll\u00f3 r\u00e9szeit, mert z\u00e1rol\u00e1s alatt \u00e1llnak. Mi\u00e9rt nem lehet azt tenni, hogy a select visszakapja a sorok m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapot\u00e1t?
\nHasonl\u00f3an, ha fut egy nagyobb analitikai lek\u00e9rdez\u00e9s vagy riport, ami intenz\u00edven olvassa a t\u00e1bla tartalm\u00e1t, akkor mi\u00e9rt nem engedik m\u00f3dos\u00edtani k\u00f6zben a sorokat, \u00fagy, hogy a select az adatok m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapot\u00e1t l\u00e1ssa? Mi\u00e9rt ne? Erre tal\u00e1lt\u00e1k ki a snapshot elszigetel\u00e9si szintet.
\nSnapshot eset\u00e9n nem z\u00e1rol\u00e1ssokkal dolgozik a szerver, hanem \u00fan. sorverzi\u00f3z\u00e1ssal. Amikor egy SNAPSHOT izol\u00e1ci\u00f3s szinten fut\u00f3 folyamat adatokat k\u00e9rdez le, nem rak a szerver csak olvashat\u00f3 (shared) z\u00e1rakat a sorokra. Ehelyett, ha j\u00f6n \u00edr\u00f3 folyamat, a m\u00f3dos\u00edtott sorok m\u00f3dos\u00edt\u00e1s el\u0151tt \u00e1llapot\u00e1t let\u00e1rolja a tempdb-ben, az \u00fan. version store-ban, verzi\u00f3t\u00e1rban. Ha az olvas\u00f3 folyamat vagy ak\u00e1r m\u00e1s folyamatok is \u00fajra a k\u00e9rd\u00e9ses adatokat select-\u00e1lj\u00e1k vissza, a verzi\u00f3t\u00e1rb\u00f3l szedi \u00f6ssze a szerver a m\u00f3dos\u00edtott sorok kor\u00e1bbi \u00e1llapot\u00e1t. Ha t\u00f6bben is nekil\u00e1tj\u00e1k m\u00f3dos\u00edtani ugyanazt a tartom\u00e1nyt, akkor t\u00f6bbf\u00e9le verzi\u00f3 is keletkezik a tempdb-ben, amelyek l\u00e1ncolt list\u00e1ban t\u00e1rol\u00f3dnak, \u00e9s lek\u00e9rdez\u00e9skor ebb\u0151l keresi ki a szerver a sz\u00fcks\u00e9ges verzi\u00f3t.
\nMit nyer\u00fcnk \u00e9s mit veszt\u00fcnk, hogy \u00e1ll a z\u00e1rol\u00e1s kontra sorverzi\u00f3z\u00e1s vet\u00e9lked\u0151? A verzi\u00f3z\u00e1s nyilv\u00e1nval\u00f3 (\u00f3ri\u00e1si) el\u0151nye, hogy az olvas\u00f3k nem blokkolj\u00e1k az \u00edr\u00f3kat \u00e9s vica versa. V\u00e9g\u00fcl is ez\u00e9rt vezett\u00e9k be a szintet. Sajnos viszont az is nyilv\u00e1nval\u00f3, hogy a m\u00f3dos\u00edt\u00e1sok lassabbak lesznek, mivel verzi\u00f3zni kell minden m\u00f3dos\u00edtott sort. A lek\u00e9rdez\u00e9sek is lassabbak lesznek, mert ha vannak nyitott \u00edr\u00f3 tranzakci\u00f3k, ut\u00e1na kell n\u00e9zni a soroknak a tempdb-ben is, h\u00e1tha van kor\u00e1bbi verzi\u00f3juk.
\nM\u00e1sfel\u0151l viszont verzi\u00f3z\u00e1s eset\u00e9n nem kell shared lockokat rakni az olvasott sorokra vagy lapokra, \u00edgy ez a k\u00f6lts\u00e9ge meg kiesik. A kett\u0151 k\u00f6z\u00f6tti d\u00f6nt\u00e9shez pontosabban meg kell ismern\u00fcnk a snapshot elszigetel\u00e9s bels\u0151 m\u0171k\u00f6d\u00e9st, v\u00e1gjunk h\u00e1t bele a r\u00e9szletekbe.
\nSnapshot \u00fczemm\u00f3dok bekapcsol\u00e1sa
\nK\u00e9tf\u00e9le m\u00f3don haszn\u00e1lhatjuk a snapshot elszigetel\u00e9si szintet, utas\u00edt\u00e1s \u00e9s tranzakci\u00f3 szinten is, fontos meg\u00e9rteni a pontos k\u00fcl\u00f6nbs\u00e9get a kett\u0151 k\u00f6z\u00f6tt.
\nEgyik snapshot \u00fczemm\u00f3d sincs alapban bekapcsolva az adatb\u00e1zisokon, azaz az SQL 2005-\u00f6s \u00e9s 2008-as adatb\u00e1zisok is z\u00e1rol\u00e1ssal m\u0171k\u00f6dnek, hasonl\u00f3an az SQL Server 2000-hez. Bekapcsol\u00e1suk ALTER DATABASE-zel lehets\u00e9ges:<\/p>\n

\r\nalter database SnapDB\r\nset allow_snapshot_isolation on\r\n<\/pre>\n
illetve<\/p>\n
\r\nalter database SnapDB\r\nset read_committed_snapshot on\r\n<\/pre>\n
Bekapcsol\u00e1s ut\u00e1n er\u0151sen megn\u0151het a tempdb m\u00e9rete \u00e9s terhel\u00e9se, err\u0151l hamarosan r\u00e9szletesen \u00edrok. Minden egyes t\u00e1bla sora, amelyen update vagy delete m\u0171veletet futtatunk, kap egy 14 b\u00e1jtos plusz adattagot, egy mutat\u00f3t, azaz ennyivel lesz hosszabb minden m\u00f3dos\u00edtott sor. Ett\u0151l lapt\u00f6r\u00e9sek (page split) k\u00f6vetkezhetnek be, ami t\u00f6redezett\u00e9 teheti a t\u00e1bl\u00e1t, \u00edgy bekapcsol\u00e1s \u00e9s n\u00e9mi haszn\u00e1lat ut\u00e1n \u00e9rdemes megfigyelni az \u00e9rintett t\u00e1bl\u00e1k t\u00f6redezetts\u00e9gi szintj\u00e9t, de defragment\u00e1lni, ha indokolt.<\/p>\n
Snapshot Isolation (SI)<\/strong>
\nHa az allow_snapshot_isolation be van kapcsolva, akkor a tranzakci\u00f3kban \u00e1tv\u00e1lthatunk SNAPSHOT elszigetel\u00e9si szintre, amit\u0151l tranzakci\u00f3-szint\u0171 sorverzi\u00f3z\u00e1st kapunk.
\nAlap\u00e1ll\u00e1s:<\/p>\n
\r\ncreate table Gyumolcs (id int, nev nvarchar(50))\r\ninsert Gyumolcs values(1, N'Alma')\r\n<\/pre>\n
“A”  kapcsolaton v\u00e9grehajtjuk a k\u00f6vetkez\u0151t:<\/p>\n
\r\nbegin tran\r\nupdate Gyumolcs set nev = N'K\u00f6rte' where id = 1\t\r\n<\/pre>\n
L\u00e1that\u00f3, a tranzakci\u00f3 nyitva maradt. “B” kapcsolaton:<\/p>\n
\r\nset transaction isolation level snapshot\r\nbegin tran\r\nselect * from Gyumolcs\r\n-- 1 Alma\r\n<\/pre>\n
\u00c1tv\u00e1ltottunk snapshot elszigetel\u00e9si szintre, \u00e9s felolvassuk a t\u00e1bl\u00e1t. Az els\u0151 megfigyel\u00e9s, hogy nem blokkol\u00f3dik az olvas\u00f3 (B) tranzakci\u00f3, hanem azonnal visszat\u00e9r a sor m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapot\u00e1val, azaz az Alm\u00e1val. Snapshot n\u00e9lk\u00fcl a select v\u00e1rakozna az els\u0151 tranzakci\u00f3 v\u00e9g\u00e9re, commit est\u00e9n a m\u00f3dos\u00edt\u00e1s ut\u00e1ni \u00e1llapotot l\u00e1tn\u00e1nk, rollbackn\u00e9l az el\u0151ttit.
\nZ\u00e1rjuk le az els\u0151 tranzakci\u00f3t, v\u00e9gleges\u00edtve a m\u00f3dos\u00edt\u00e1st:<\/p>\n
\r\nCommit\t\r\n<\/pre>\n
Adjuk ki m\u00e9g egyszer a selectet a m\u00e1sodik, m\u00e9g nyitott tranzakci\u00f3ban:<\/p>\n
\r\nselect * from Gyumolcs\r\n-- 1 Alma\r\n<\/pre>\n
Kimenet: tov\u00e1bbra is Alma. Mi\u00e9rt? SNAPSHOT szinten tranzakci\u00f3-szint\u0171 sorverzi\u00f3z\u00e1st kapunk, azaz garant\u00e1ltan ugyanazt az adatok kapjuk vissza m\u00e1sodik olvas\u00e1sra is, amit a tranzakci\u00f3 elej\u00e9n. REPEATABLE READ, sorverzi\u00f3z\u00e1ssal.
\nZ\u00e1rjuk le a m\u00e1sodik tranzakci\u00f3t is egy committal. Ekkor nem t\u00f6rt\u00e9nik adatb\u00e1zism\u0171veletet, hisz csak olvastunk ebben a tranzakci\u00f3ban, de a verzi\u00f3t\u00e1r tudja, hogy lehet takar\u00edtani a kor\u00e1bban elt\u00e1rolt sort, nincs m\u00e1r senkinek sz\u00fcks\u00e9ge r\u00e1. Ebb\u0151l k\u00f6vetkezik, hogy hossz\u00fa ideig nyitott tranzakci\u00f3k miatt igen nagyra tud n\u0151ni a verzi\u00f3t\u00e1r (a tempdb), \u00edgy erre fokozottan kell \u00fcgyelni az adatel\u00e9r\u0151 r\u00e9teg tervez\u00e9s\u00e9n\u00e9l.
\nTov\u00e1bb vizsg\u00e1l\u00f3dva n\u00e9zz\u00fck meg, mi a helyzet a fantomsorokkal?
\nA m\u00e1sodikon kapcsolaton:<\/p>\n
\r\nset transaction isolation level snapshot\r\nbegin tran\r\nselect * from Gyumolcs\r\n-- 1 K\u00f6rte\r\n<\/pre>\n
Kimenet: K\u00f6rte, az el\u0151z\u0151 teszt m\u00f3dos\u00edt\u00e1s\u00e1nak v\u00e9geredm\u00e9nye.<\/p>\n
Az els\u0151 kapcsolaton sz\u00farjunk be egy \u00faj sort:<\/p>\n
\r\nbegin tran\r\ninsert Gyumolcs values(2, N'Barack')\t\r\n\tselect * from Gyumolcs\r\n-- 1 K\u00f6rte\r\n<\/pre>\n
A m\u00e1sodik kapcsolaton megism\u00e9telve a selectet tov\u00e1bbra is csak a K\u00f6rte sor l\u00e1tszik, az \u00faj Barack nem. Ez akkor is \u00edgy marad, ha commitoljuk az els\u0151 tranzakci\u00f3 besz\u00far\u00e1s\u00e1t. Azaz l\u00e1tjuk, hogy a SNAPSHOT elszigetel\u00e9si szint v\u00e9d a fantom sorok ellen is. Ez az\u00e9rt nagy sz\u00e1m, mert ugyanazokat a tranzakcion\u00e1lis garanci\u00e1kat kapjuk SNAPSHOT szinten, mint a z\u00e1rol\u00f3s m\u0171k\u00f6d\u00e9si m\u00f3dban a legszigor\u00fabb SERIALIZABLE szinten, m\u00e9gis, a folyamatok p\u00e1rhuzamoss\u00e1g\u00e1t sokkal kev\u00e9sb\u00e9 korl\u00e1tozva. Ennek nyilv\u00e1n a verzi\u00f3t\u00e1r \u00e1lland\u00f3 friss\u00edt\u00e9s\u00e9vel fizetj\u00fck meg az \u00e1r\u00e1t.
\nRendben, a m\u00f3dos\u00edt\u00e1sok \u00e9s a friss\u00edt\u00e9sek j\u00f3l megf\u00e9rnek egym\u00e1s mellett, \u00e9s garant\u00e1lja nek\u00fcnk a szerver, hogy a lek\u00e9rdez\u00e9sek az \u0151ket mag\u00e1ba foglal\u00f3 tranzakci\u00f3 kezdet\u00e9hez k\u00e9pesti legfrissebb adatot adja nek\u00fcnk vissza. Ez adatelemz\u00e9si szempontb\u00f3l \u00f3ri\u00e1si el\u0151ny lehet, azonban a m\u00f3dos\u00edt\u00e1sokat kicsit megnehez\u00edti. Mi\u00e9rt?
\nHajtsuk v\u00e9gre a k\u00f6vetkez\u0151 scriptet az B kapcsolaton kereszt\u00fcl:<\/p>\n
\r\nset transaction isolation level snapshot\r\nbegin tran\r\nselect * from Gyumolcs \r\nwhere id = 1\r\n-- 1 K\u00f6rte\r\n<\/pre>\n
L\u00e1tjuk a K\u00f6rte sort, eddig semmi meglep\u0151.
\nA kapcsolaton m\u00f3dos\u00edtjuk B kapcsolaton lev\u00e1logatott sort:<\/p>\n
\r\nbegin tran\r\nupdate Gyumolcs set nev = N'Narancs' where id = 1\t\r\n<\/pre>\n
A K\u00f6rte most m\u00e1r Narancs, de m\u00e9g nincs v\u00e9gleges\u00edtve a tranzakci\u00f3. B folyamat \u00fajraolvashatn\u00e1 a sort, \u00e9s l\u00e1tn\u00e1 az eredeti \u00e1llapotot, az K\u00f6rt\u00e9t, ezt m\u00e1r tudjuk. De B most m\u00f3dos\u00edtani akarja ugyanazt a sort!<\/p>\n
\r\nupdate Gyumolcs \r\nset nev = N'Narancs' where id = 1\r\n-- V\u00e1rakozik ...\r\n<\/pre>\n
Mit tehet ilyenkor a szerver? Olvas\u00e1s eset\u00e9n el\u0151vehette az eredeti verzi\u00f3t, de ha most is ezt tenn\u00e9, akkor a tranzakci\u00f3 v\u00e9g\u00e9n fejbe v\u00e1gn\u00e1 a k\u00e9t tranzakci\u00f3 egym\u00e1s m\u00f3dos\u00edt\u00e1s\u00e1t, azaz a sor v\u00e9gs\u0151 \u00e1llapot\u00e1t az d\u00f6nten\u00e9 el, hogy melyik tranzakci\u00f3 v\u00e9gzett k\u00e9s\u0151bb. Ezt a probl\u00e9m\u00e1t lost update-nek nevezz\u00fck, elveszett m\u00f3dos\u00edt\u00e1snak. A cikk elej\u00e9n felsorol anom\u00e1li\u00e1k k\u00f6z\u00f6tt az\u00e9rt nem szerepelt ez, mert ez csak optimista, nem z\u00e1rol\u00f3s s\u00e9m\u00e1k eset\u00e9n jelentkezik, a z\u00e1rol\u00f3s-pesszimista \u00fczemm\u00f3dn\u00e1l nem.
\nNo, az SQL Server \u00fagy kezeli ezt az esetet, hogy megv\u00e1rakoztatja a m\u00e1sodik m\u00f3dos\u00edt\u00f3 tranzakci\u00f3t. Ha az els\u0151 egy committal ezek ut\u00e1n eld\u00f6nti, mit akar, a m\u00e1sodik megkapja a mag\u00e1\u00e9t:<\/p>\n
\r\ncommit\t\r\n<\/pre>\n
Msg 3960, Level 16, State 4, Line 1
\nSnapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table ‘dbo.Gyumolcs’ directly or indirectly in database ‘SnapDB’ to update, delete, or insert the row that has been modified or deleted by another transaction. Retry the transaction or change the isolation level for the update\/delete statement.<\/p>\n
Logikus l\u00e9p\u00e9s, valahogyan tudatni kell a m\u00e1sodik tranzakci\u00f3val, hogy megel\u0151zt\u00e9k. A tranzakci\u00f3t m\u00e1r le se kell z\u00e1rni, mert ezt megtette helyett\u00fcnk a szerver. S\u0151t, nem is szabad, hisz nincs \u00e9rtelme, ezt is gyorsan megtapasztaljuk:<\/p>\n
\r\n\tcommit\r\n<\/pre>\n
Msg 3902, Level 16, State 1, Line 1
\nThe COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.<\/p>\n
Azaz az els\u0151 tranzakci\u00f3 sikeresen m\u00f3dos\u00edtott a sort. Mit tehet a vesztes tranzakci\u00f3? Ott van a tipp a hiba\u00fczenetben, \u00fajra lehet pr\u00f3b\u00e1lkozni. M\u00e1sodikra tal\u00e1n mi lesz\u00fcnk a gyorsabbak. Ha belegondolunk, a z\u00e1rol\u00f3s-pesszimista \u00fczemm\u00f3d eset\u00e9n is vannak hasonl\u00f3 esetek, ott deadlockok eset\u00e9n kell ism\u00e9tl\u0151 logik\u00e1t berakni az alkalmaz\u00e1sba, itt pedig a 3960-as hib\u00e1t kell speci\u00e1lisan lekezelni (az adatel\u00e9r\u0151 r\u00e9tegben, vagy egy TSQL TRY-CATCH-ben).
\nEz a hiba valamelyest seg\u00edt d\u00f6nteni abban, hogy \u00e9rdemes-e \u00e1tv\u00e1ltanunk erre az \u00faj elszigetel\u00e9si szintre. Ha kev\u00e9s m\u00f3dos\u00edt\u00e1si konfliktust \u00e9l\u00fcnk meg, azaz sok az olvas\u00f3 folyamat, de kev\u00e9s az m\u00f3dos\u00edt\u00f3, akkor a SNAPSHOT j\u00f3 v\u00e1laszt\u00e1s, nagyon sokat seg\u00edthet a p\u00e1rhuzamos v\u00e9grehajt\u00e1sban, \u00edgy a szerver \u00e1tereszt\u0151 k\u00e9pess\u00e9g\u00e9ben (h\u00e1ny tranzakci\u00f3t tud v\u00e9grehajtani egys\u00e9gnyi id\u0151 alatt).
\nViszont sok p\u00e1rhuzamos \u00edr\u00f3 folyamat eset\u00e9n (pl. sok forr\u00e1sb\u00f3l t\u00e1pl\u00e1lkoz\u00f3 adatgy\u0171jt\u0151 rendszer) a r\u00e9gi z\u00e1rol\u00f3s \u00fczemm\u00f3d a megfelel\u0151bb. Ebben az esetben viszont a deadlockokat kell ism\u00e9tl\u00e9ssel lekezelni, csak ezekb\u0151l v\u00e1rhat\u00f3an kevesebb lesz, \u00edgy erre az oldalra billen el a m\u00e9rleg nyelve.<\/p>\n
Read Committed Snapshot Isolation (RCSI)<\/strong><\/p>\n
RCSI eset\u00e9n nem kell explicit \u00e1tv\u00e1ltani SNAPSHOT szintre set transaction isolation level paranccsal, hanem az eddigi alap\u00e9rtelmezett READ COMMITTED szint m\u0171k\u00f6d\u00e9se alakul \u00e1t verzi\u00f3zott\u00e1. Azaz an\u00e9lk\u00fcl, hogy a kisujjunkat is meg kellene mozgatni, m\u00e1ris \u00e9lvezhetj\u00fck a megn\u00f6vekedett p\u00e1rhuzamoss\u00e1got (meg a megn\u00f6vekedett tempdb-t :).
\nA SI \u00e9s az RCSI k\u00f6z\u00f6tt azonban alapvet\u0151 k\u00fcl\u00f6nbs\u00e9g van: m\u00edg SI est\u00e9n l\u00e1ttuk, hogy az olvas\u00f3 tranzakci\u00f3 kezdet\u00e9hez k\u00e9pest kapunk vissza konzisztens adatokat, ism\u00e9telt olvas\u00e1si garanci\u00e1val, addig RCSI eset\u00e9n a select utas\u00edt\u00e1s kezdet\u00e9hez k\u00e9pest kapunk vissza egys\u00e9ges adatokat. Azaz nincs ism\u00e9telt olvas\u00e1si \u00e9s fantom sorok elleni garancia.
\nN\u00e9zz\u00fck meg az els\u0151 p\u00e9ld\u00e1nkat, ez\u00fattal RCSI szinten. Hogy teljesen tiszta legyen a k\u00e9p, kapcsoljuk ki a sima SI-t:<\/p>\n
\r\nalter database SnapDB\r\nset allow_snapshot_isolation off\r\n<\/pre>\n
Majd v\u00e1ltsunk \u00e1t az RCSI \u00fczemm\u00f3dba a k\u00f6vetkez\u0151 paranccsal:<\/p>\n
\r\nalter database SnapDB\r\nset read_committed_snapshot on\r\n<\/pre>\n
A parancs csak akkor hajt\u00f3dik v\u00e9gre, ha csakis ezt a parancsot v\u00e9grehajt\u00f3 kapcsolat van benn az adatb\u00e1zisban. \u00dcgyelj\u00fcnk, hogy a Management Studio Object Browsere is nyitva tart egy kapcsolatot az adatb\u00e1zisra, ha annak belseje ki van nyitva a f\u00e1ban. Z\u00e1rjuk be a fa csom\u00f3pontj\u00e1t, \u00e9s felszabadul a kapcsolat.
\nBekapcsol\u00e1s ut\u00e1n hajtsuk v\u00e9gre a kor\u00e1bbi teszt\u00fcnket ezen a szinten:<\/p>\n
Conn1:<\/p>\n
\r\n1.\r\ncreate table Gyumolcs (id int, nev nvarchar(50))\r\ninsert Gyumolcs values(1, N'Alma')\t\r\n<\/pre>\n
Conn2:<\/p>\n
\r\n2.\r\nbegin tran\r\nselect * from Gyumolcs --1 Alma\r\n<\/pre>\n
Conn1:<\/p>\n
\r\n3.\r\nbegin tran\r\nupdate Gyumolcs set nev = N'K\u00f6rte' where id = 1\t\r\n<\/pre>\n
Conn2:<\/p>\n
\r\n4.\r\nselect * from Gyumolcs --1 Alma\r\n<\/pre>\n
Conn1:<\/p>\n
\r\n5.\r\ncommit\t\r\n<\/pre>\n
Conn2:<\/p>\n
\r\n6.\r\nselect * from Gyumolcs -- 1 K\u00f6rte\r\nCommit\r\n<\/pre>\n
L\u00e1that\u00f3, hogy a nyitott m\u00f3dos\u00edt\u00f3 tranzakci\u00f3 eset\u00e9n (3) a m\u00f3dos\u00edt\u00e1s el\u0151tt adatot kapjuk vissza (4), \u00e9pp\u00fagy, mint a SI eset\u00e9n. Ha azonban a m\u00f3dos\u00edt\u00e1s v\u00e9gleges\u00edt\u00e9sre ker\u00fclt (5), az olvas\u00f3 folyamat m\u00e1r a m\u00f3dos\u00edt\u00e1s ut\u00e1ni \u00e1llapot\u00e1t l\u00e1tja a sornak (6). Ez az alapvet\u0151 k\u00fcl\u00f6nbs\u00e9g az RCSI \u00e9s az SI k\u00f6z\u00f6tt.
\nRCSI eset\u00e9n nincs konfliktus update eset\u00e9n, a m\u00e1sodik m\u00f3dos\u00edt\u00f3 folyamat ugyan\u00fagy blokkol\u00f3dik, mint SI eset\u00e9n, azonban az els\u0151 \u00edr\u00f3 commitja ut\u00e1n a m\u00e1sodik is sikeresen v\u00e9grehajtja az update-j\u00e9t.
\nAzaz RCSI eset\u00e9n sz\u00e1m\u00edthatunk fejbe v\u00e1gott m\u00f3dos\u00edt\u00e1sokra, nem megism\u00e9telhet\u0151 olvas\u00e1sokra \u00e9s fantom sorokra. Cser\u00e9be viszont jelent\u0151sen kevesebb adat ker\u00fcl a verzi\u00f3t\u00e1rba, hisz nem kell olyan hossz\u00fa ideig megtartani a m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapotokat. Megint valamit-valami\u00e9rt.
\nA verzi\u00f3t\u00e1r m\u00e1s felhaszn\u00e1l\u00e1sai
\nA tempdb-ben kialak\u00edtott verzi\u00f3t\u00e1r els\u0151dlegesen a Snapshot szintek kedv\u00e9\u00e9rt ker\u00fclt kialak\u00edt\u00e1sra. \u00c1m ha m\u00e1r elk\u00e9sz\u00fclt, m\u00e1s szolg\u00e1ltat\u00e1st is \u00e9p\u00edtettek r\u00e1.
\nA triggerek m\u00e1r eddig is egyfajta verzi\u00f3zott m\u00f3don m\u0171k\u00f6dtek, hisz pl. a deleted t\u00e1bla a sorok m\u00f3dos\u00edt\u00e1s el\u0151tti \u00e1llapot\u00e1t mutatta. Ezt SQL Server 2000-ben a tranzakci\u00f3s napl\u00f3 visszaolvas\u00e1s\u00e1val \u00e1ll\u00edtott\u00e1k el\u0151. A megold\u00e1s nagy h\u00e1tr\u00e1nya volt, hogy az egyir\u00e1ny\u00fa \u00edr\u00e1sra optimaliz\u00e1lt tranzakci\u00f3s napl\u00f3t id\u0151nk\u00e9nt vissza kellett olvasni, ami miatt megn\u00f6vekedett a HDD fejmozg\u00e1sok sz\u00e1ma, \u00edgy lecs\u00f6kkent a tranzakci\u00f3s log \u00edr\u00e1si sebess\u00e9ge.
\nSQL 2005-t\u0151l kezdve a triggerek inserted \u00e9s deleted virtu\u00e1lis t\u00e1bl\u00e1it a verzi\u00f3t\u00e1r seg\u00edts\u00e9g\u00e9vel szintetiz\u00e1lj\u00e1k. Akkor is, ha egyik snapshot \u00fczemm\u00f3d sincs bekapcsolva. Ett\u0151l megsz\u0171nik a logra gyakorolt kedvez\u0151tlen hat\u00e1s, de megn\u0151 a tempdb terhel\u00e9se.
\nA verzi\u00f3t\u00e1r m\u00e1sik jelent\u0151s\u00e9ge az online indexm\u0171veletekn\u00e9l j\u00f6n a k\u00e9pbe. SQL 2005-t\u0151l az indexm\u0171veleteket (create, drop, rebuild) az \u00e9rintett t\u00e1bla z\u00e1rol\u00e1sa n\u00e9lk\u00fcl is v\u00e9grehajthat\u00f3, ezek az online m\u0171veletek. P\u00e9ld\u00e1ul:<\/p>\n
\r\nalter index all on Production.Product\r\nrebuild with (online = on);\r\n<\/pre>\n
Amikor elkezd\u0151dik az \u00faj index fel\u00e9p\u00edt\u00e9se a szerver bel\u00fcl “\u00e1tv\u00e1lt” SNAPSHOT izol\u00e1ci\u00f3s szintre, \u00edgy a megl\u00e9v\u0151 index adatait a tranzakci\u00f3, az index \u00e9p\u00edt\u00e9s kezdet\u00e9hez k\u00e9pest konzisztens m\u00f3don k\u00e9pes \u00e1tm\u00e1solni. Mik\u00f6zben \u00e9p\u00edti fel az \u00faj, p\u00e1rhuzamos indexf\u00e1t k\u00f6zben m\u00e1s kapcsolatokon kereszt\u00fcl m\u00f3dos\u00edthatj\u00e1k az alapt\u00e1bl\u00e1t \u00e9s az indexet is. A m\u00f3dos\u00edt\u00e1sok egyszerre m\u00f3dos\u00edtj\u00e1k az eredeti indexet \u00e9s az \u00e9p\u00fcl\u0151t is. A verzi\u00f3t\u00e1rol\u00f3 a tempdb-ben k\u00f6zben sz\u00e9pen r\u00f6gz\u00edt minden v\u00e1ltoz\u00e1st, \u00edgy a m\u00f3dos\u00edt\u00e1sok nem ker\u00fclnek dupl\u00e1n \u00e1tvezet\u00e9sre.
\nAmi sz\u00e1munkra ebb\u0151l k\u00edv\u00fclr\u0151l l\u00e1that\u00f3 l\u00e9nyeg, hogy az indexm\u0171velet alatt is el\u00e9rhet\u0151 a t\u00e1bla \u00e9s az index.
\nA Multiple Active Resultset (MARS) nev\u0171 harmadik technol\u00f3gia az, ami m\u00e9g kihaszn\u00e1lja a verzi\u00f3t\u00e1rol\u00f3t, \u00e1m ennek m\u0171k\u00f6d\u00e9s\u00e9t most nem r\u00e9szletezem.<\/p>\n
Verzi\u00f3t\u00e1r takar\u00edt\u00e1s, monitoroz\u00e1s<\/strong><\/p>\n
Ha indokolatlanul nagynak t\u0171nik a tempdb vagy valamelyik snapshot szint bekapcsol\u00e1sa ut\u00e1n szeretn\u00e9nk l\u00e1tni mennyire intenz\u00edven haszn\u00e1lja a szerver a verzi\u00f3t\u00e1rat, t\u00f6bbf\u00e9le \u00faton is kutakodhatunk.
\nHa arra vagyunk k\u00edv\u00e1ncsiak h\u00e1ny sor van a verzi\u00f3t\u00e1rban, futtassuk le a k\u00f6vetkez\u0151 parancsot:
\nselect count(*) from sys.dm_tran_version_store
\nSI tranzakci\u00f3k eset\u00e9n a tranzakci\u00f3 v\u00e9g\u00e9n, RCSI tranzakci\u00f3kn\u00e1l a select lefut\u00e1sa ut\u00e1n m\u00e1r nincs sz\u00fcks\u00e9g a m\u00f3dos\u00edtott sorok verzi\u00f3t\u00f6rt\u00e9net\u00e9re. Ez\u00e9rt percenk\u00e9nt lefut egy h\u00e1tt\u00e9rsz\u00e1l a szerverben, amely kit\u00f6rli a m\u00e1r nem sz\u00fcks\u00e9ges sorokat.
\nHa a tempdb kifutna a sz\u00e1m\u00e1ra behat\u00e1rolt helyb\u0151l, akkor a takar\u00edt\u00f3 azonnal elindul, h\u00e1tha fel tud szabad\u00edtani el\u00e9g helyet, \u00edgy nem kell megn\u00f6velni az adatb\u00e1zist. Tiszt\u00e1ra olyan ez, mint a .NET Framework Garbage Collectora, csak az a  mem\u00f3ri\u00e1t s\u00f6pr\u00f6geti.
\nA Version Generation Rate \u00e9s a Version Cleanup Rate teljes\u00edtm\u00e9nysz\u00e1ml\u00e1l\u00f3k seg\u00edts\u00e9g\u00e9vel durv\u00e1n l\u00e1thatjuk mekkora a s\u00fcrg\u00e9s-forg\u00e1s a t\u00e1rban.
\nAz Update conflict ratio t\u00fal nagy \u00e9rt\u00e9ke azt sugallja, lehet, hogy \u00e9rdemes visszat\u00e9rni a z\u00e1rol\u00f3s \u00fczemm\u00f3dhoz, mert t\u00fal sok az \u00edr\u00f3 folyamat.
\nA verzi\u00f3t\u00e1r hal\u00e1la egy id\u00e9tlen tranzakci\u00f3, amely – \u00e1ltal\u00e1ban hibakezel\u00e9si hiba miatt – t\u00fal hossz\u00fa ideig fut. Azaz elfelejtik lez\u00e1rni a tranzakci\u00f3t, de az adatb\u00e1ziskapcsolatot nyitva hagyj\u00e1k. Egy ilyen tranzakci\u00f3 a z\u00e1rol\u00e1sos \u00fczemm\u00f3d eset\u00e9n hossz\u00fa blokkol\u00e1si l\u00e1ncokat, \u00edgy ak\u00e1r az eg\u00e9sz adatb\u00e1zisra \u00e9p\u00fcl\u0151 alkalmaz\u00e1s le\u00e1ll\u00e1s\u00e1t okozhatta. Most nem \u00e1ll meg az \u00e9let, de lehet, hogy a tempdb nagyon nagyra n\u0151, \u00e9s belassul az adatb\u00e1zis. A Longest Transaction Running Time nev\u0171 sz\u00e1ml\u00e1l\u00f3ban meg lehet n\u00e9zni, van-e valaki beragadva. Ha itt megl\u00e1tunk mondjuk 1800 m\u00e1sodpercet, azaz f\u00e9l \u00f3r\u00e1t, mik\u00f6zben tudjuk, hogy a tranzakci\u00f3ink 1 percen bel\u00fcl lefutnak, akkor sejtj\u00fck, hogy valaki beragadt. A b\u0171n\u00f6st a k\u00f6vetkez\u0151 lek\u00e9rdez\u00e9ssel \u00e9rhetj\u00fck tetten:<\/p>\n
\r\nselect elapsed_time_seconds, session_id \r\nfrom sys.dm_tran_active_snapshot_database_transactions\r\nelapsed_time_seconds session_id\r\n-------------------- -----------\r\n848                  52\r\n<\/pre>\n
Az 52-es session (kapcsolat) m\u00e1r 848 m\u00e1sodperce toll\u00e1szkodik, ha nem indokolt a munk\u00e1ja, kil\u0151het\u0151.
\nHaszn\u00e1ljuk vagy sem?<\/p>\n
Z\u00e1r\u00e1sul n\u00e9zz\u00fck meg, milyen szempontok alapj\u00e1n tudunk v\u00e1lasztani a k\u00e9tf\u00e9le snapshot elszigetel\u00e9s k\u00f6z\u00f6tt, illetve mire sz\u00e1m\u00edtsunk, ha \u00fagy \u00e1ltal\u00e1ban \u00e1t\u00e1llunk a z\u00e1rol\u00f3s \u00fczemm\u00f3dr\u00f3l valamelyik verzi\u00f3s \u00fczemm\u00f3dra.<\/p>\n
\u00c1ltal\u00e1noss\u00e1gban a RCSI-on \u00e9rdemes el\u0151sz\u00f6r elgondolkodni, mert:
\n\u2022\tKevesebb helyet ig\u00e9nyel a tempdb-ben mint a SI
\n\u2022\tHaszn\u00e1lhat\u00f3 elosztott tranzakci\u00f3kban is, a SI nem
\n\u2022\tNem lesznek update konfliktusok
\n\u2022\tNem kell \u00e1t\u00edrni az alkalmaz\u00e1sokat. Egyszer\u0171en be kell kapcsolni az adatb\u00e1zison RCSI-t, \u00e9s m\u00e1ris minden alkalmaz\u00e1s \u00e9lvezi az el\u0151nyeit.<\/p>\n
Mikor \u00e9rdemes ezek ut\u00e1n az SI-t bevetni?
\n\u2022\tHa \u00e1ltal\u00e1ban kev\u00e9s a p\u00e1rhuzamosan fut\u00f3 m\u00f3dos\u00edt\u00f3 folyamat, \u00edgy kicsi az update konfliktusok val\u00f3sz\u00edn\u0171s\u00e9ge
\n\u2022\tOlyan lek\u00e9rdez\u00e9seket, riportokat kell futtatni, amelyeknek fontos az id\u0151pont-konzisztencia. Magyarul ha egy tranzakci\u00f3ban t\u00f6bbsz\u00f6r is \u00e1t kell gy\u00farni az adatokat \u00e9s fontos, hogy k\u00f6zben az adathalmazunk stabil legyen, akkor ezt csak a SI tudja biztos\u00edtani, a RCSI nem. P\u00e9ld\u00e1ul a tranzakci\u00f3ban el\u0151sz\u00f6r aggreg\u00e1l\u00f3 lek\u00e9rdez\u00e9seket futtatunk egy t\u00e1bl\u00e1n, azt\u00e1n a r\u00e9szletes adatokat v\u00e1logatjuk le. SI n\u00e9lk\u00fcl inkonzisztens lehetne a kimenet, azaz a r\u00e9szletes adatok nem v\u00e1gn\u00e1nak egybe az aggreg\u00e1lt eredm\u00e9nyekkel.<\/p>\n
Vess\u00fck most \u00f6ssze a verzi\u00f3s \u00fczemm\u00f3dokat a z\u00e1rol\u00f3s \u00fczemm\u00f3dokkal.<\/p>\n
A verzi\u00f3z\u00e1s el\u0151nyei a z\u00e1rol\u00e1ssal szemben:
\n\u2022\tA select nem rak csak olvashat\u00f3 (shared) z\u00e1rakat a t\u00e1bl\u00e1ra, \u00edgy az \u00edr\u00f3k \u00e9s az olvas\u00f3k nem akad\u00e1lyozz\u00e1k egym\u00e1st (ez a legf\u0151bb \u00e9rv a verzi\u00f3z\u00e1s mellett)
\n\u2022\tA selectek id\u0151ben konzisztens k\u00e9pet adnak vissza (SI \u00e9s RCSI eset\u00e9n m\u00e1sk\u00e9pp, l\u00e1sd kor\u00e1bban)
\n\u2022\tSokkal kevesebb z\u00e1rat (lockot) kell nyilv\u00e1ntartani a szervernek, ami jelent\u0151s er\u0151forr\u00e1st takar\u00edt meg
\n\u2022\tKevesebb z\u00e1r-eszkal\u00e1ci\u00f3 t\u00f6rt\u00e9nik (amikor sok sor vagy lap szint\u0171 z\u00e1rat \u00e1tkonvert\u00e1l t\u00e1bla szint\u0171 z\u00e1rr\u00e1 a szerver, hogy er\u0151forr\u00e1sokat szabad\u00edtson fel)
\n\u2022\tKisebb a deadlockok val\u00f3sz\u00edn\u0171s\u00e9ge<\/p>\n
Term\u00e9szetesen vannak h\u00e1tr\u00e1nyai is a verzi\u00f3z\u00e1snak, m\u00e1sk\u00e9nt automatikusan ezt haszn\u00e1ln\u00e1nk. Ezek a k\u00f6vetkez\u0151k:
\n\u2022\tA selectek lelassulhatnak, ha hossz\u00fa verzi\u00f3-l\u00e1ncokat kell v\u00e9gign\u00e9zni sok nyitott tranzakci\u00f3 miatt
\n\u2022\tA tempdb-ben helyet kell neki biztos\u00edtani
\n\u2022\tAz adatm\u00f3dos\u00edt\u00f3 m\u0171veletek verzi\u00f3kat fognak gener\u00e1lni a verzi\u00f3t\u00e1rol\u00f3ban, m\u00e9g akkor is, ha nincs k\u00f6zvetlen\u00fcl r\u00e1juk sz\u00fcks\u00e9g. Azaz lassulnak az adatm\u00f3dos\u00edt\u00e1sok.
\n\u2022\tMinden sor ami a verzi\u00f3z\u00e1s bekapcsol\u00e1sa ut\u00e1n m\u00f3dosult 14 b\u00e1jttal hosszabb lesz (mutat\u00f3 a verzi\u00f3t\u00e1r megfelel\u0151 bugyr\u00e1ra)
\n\u2022\tAz update lassabb lesz a verzi\u00f3t\u00e1rol\u00e1s miatt
\n\u2022\tSI eset\u00e9n az update konfliktusba ker\u00fcl p\u00e1rhuzamos folyamatok update-jeivel, amit le kell kezelni az alkalmaz\u00e1snak
\n\u2022\t\u00dcgyelni kell a tempdb m\u00e9ret\u00e9re, nehogy megszaladjon.<\/p>\n
\u00d6sszefoglalva elmondhat\u00f3, hogy a snapshot elszigetel\u00e9si szintek megjelen\u00e9se hatalmas fegyvert\u00e9ny, amellyel sok p\u00e1rhuzamosan m\u0171k\u00f6d\u0151 rendszer m\u0171k\u00f6d\u00e9s\u00e9t lehet dr\u00e1maian felgyors\u00edtani, illetve nagyban megk\u00f6nny\u00edti olyan alkalmaz\u00e1sok \u00e1t\u00edr\u00e1s\u00e1t m\u00e1s adatb\u00e1ziskezel\u0151 rendszerr\u0151l, amely verzi\u00f3z\u00e1ssal m\u0171k\u00f6dik.<\/p>\n","protected":false},"excerpt":{"rendered":"
El\u00e9gg\u00e9 elfeledett t\u00e9ma ez az SQL Serverben, pedig \u00f6nmag\u00e1ban ez az \u00faj szolg\u00e1ltat\u00e1s eladta volna az SQL 2005-\u00f6t. Update: kor\u00e1bban itt egy…<\/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,21,58],"tags":[],"class_list":["post-809","post","type-post","status-publish","format-standard","hentry","category-adatbazisok","category-szakmai-elet","category-sql-server-2005","category-sql-server-2008"],"_links":{"self":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/809","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=809"}],"version-history":[{"count":8,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/809\/revisions"}],"predecessor-version":[{"id":1606,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/809\/revisions\/1606"}],"wp:attachment":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}