Az első egy kicsi, de hasznos apróság: az OUTPUT clause vagy ahogy Serény tanár úr írná, a klóz. Mire jó? Tipikus jelenet, hogy kell update-elnem rekordokat egy OLTP adatbázisban, azaz az adat változik alattam, de szeretném tudni, hogy pontosan melyeket update-eltem meg. Erre a gyenge megoldás a

select primary_key into #temptabla from tabla
where status = 'NEW'

update tabla where primary_key in (select primary_key from #temptabla)
set status = 'ACTIVE'

drop table #temptabla

Ez egy egész jó megközelítés, két feltétel teljesülése esetén:

1. Nulla konkurrencia lehetséges, azaz pl. nem akar egyszerre két alkalmazásszerver dolgozni az adatbáziban, ekkor ugyanis ők lelkesen dolgozzák fel a rekordokat – egyszerre. Ezt nem részletezném, hogy miért gáz.
2. 2008-at vagy kevesebbet írunk. Azóta ugyanis van OUTPUT clause.

A dolog roppant egyszerű: bele van dugva egy belső trigger gyakorlatilag, ami a következőt tudja: ha beletömjük az OUTPUT-ot az INSERT/UPDATE/DELETE utasításba, akkor lesz inserted és/vagy deleted táblánk, és lehet kiszipkázni az adatokat, akár csak kiechózni, akár betenni táblaváltozókba. Az OUTPUT helye a WHERE feltétel előtt van még, erre figyeljetek. Valahogy így:

UPDATE tabla
SET status = 'ACTIVE'
OUTPUT inserted.primary_key
WHERE status = 'NEW'

Valljuk be, hogy jobban néz ki. Ha el akarjuk menteni az outputot későbbi reszeléshez vagy csak nyakonvágni a teljesítményt, akkor pedig a fenti példa így néz ki:

DECLARE @tablacska table (primary_key int);
UPDATE tabla
SET status = 'ACTIVE'
OUTPUT inserted.primary_key INTO @tablacska
WHERE status = 'NEW';
SELECT primary_key FROM @tablacska;

Ez egyébként fokozható, például ha már így előjött a konkurrencia, mint probléma, kiválóan megoldható a sok alkalmazás egy táblát túr probléma ezzel meg egy kis locking hinteléssel:

UPDATE tabla WITH (READPAST)
SET status = 'ACTIVE'
OUTPUT inserted.*
WHERE status = 'NEW'

Így ha több szerver dolgoz fel egy queue-t, hogy szépen mondjam, nem kell nagyon foglalkozniuk a másikkal. Egy konkrét szerver odamegy, kivesz annyi rekordot, amennyit akar (mert lehet TOP-ot is mondani az update-ben), ha valaki más is éppen update-el, akkor az általa lockolt rekordokat átugorja, és keres olyat, ami nincs lockolva. Ez a READPAST ajándéka: átugorja a lockolt rekordokat, így nem akadnak fenn egymáson a párhuzamos processzek.

(disclaimer: épp nincs SQL szerverem, ezért a példákat fejből írtam, ha nem működnek, bocsi, kijavítom :)

Van egy elég általános probléma alkalmazásfejlesztésben: folyamatos sorszámozás az adatbázisban – a klasszikus példa a számlaszám, amiben nem lehetnek lyukak, mert attól a könyvelő is meg az APEH is ideges. Erre van többféle megoldás, némelyik jó, némelyik nem. Nézzük előbb a rosszakat:

1. Használjunk identity oszlopot! Ez minden sikertelen beszúrásnál is növelni fogja a sorszámot, és lukak maradnak utána.
2. Kérdezzük le az utolsó kiadott sorszámot, és tároljuk el az eggyel nagyobbat. Ez csábítóan egyszerű, és speciális esetekben akár jó is lehet, a probléma a konkurrencia: ha ketten egyszerre kérdezik le a legutolsó sorszámot, ugyanazt fogják kiosztani következőnek.

És nézzünk egy jót: Tároljuk el a számlarekordot, egyelőre számlaszám nélkül, egy másik egyedi azonosítóval (ez lehet akár egy identity oszlop is), és tartsunk fenn egy táblát, aminek egyetlen oszlopa identity. Minden számlarekord eltárolás után húzzunk egy sorszámot (azaz szúrjunk be egy rekordot), és azt tegyük el számlaszámként. Mivel itt nem lehet sikertelen beszúrás, a sorszámozás folyamatos lesz. De mit csinálunk a nagyra nőtt sorszámgeneráló táblával? a TRUNCATE TABLE nem jó, mert az ugyan gyorsan üríti a táblát, de reseteli az identity értéket is, tehát megint az elejéről kezdjük osztani a számlákat. A DELETE technikailag jó, de sok rekord törlésénél esetleg lock eszkalációba futunk, aminek az lesz a vége, hogy senki nem fog új számlát készíteni egy darabig.

A problémára gyógyír Itzik egy kis mintascriptje:

USE tempdb;
CREATE TABLE dbo.AsyncSeq(val INT IDENTITY);
GO
CREATE PROC dbo.usp_AsyncSeq
 @val AS INT OUTPUT
AS
BEGIN TRAN
 SAVE TRAN S1;
 INSERT INTO dbo.AsyncSeq DEFAULT VALUES;
 SET @val = SCOPE_IDENTITY()
 ROLLBACK TRAN S1;
COMMIT TRAN
GO

Ez a dbo.usp_AsyncSeq tárolt eljárás tulajdonképpen az Oracle szekvencia implementációja. Fog egy táblát, amibe mindig beszúr, de nem menti el a beszúrást igazából, csak lekéri az identity értéket. Így a tábla mindig üres, és a karbantartása meg van oldva gyárilag. Használata kb. a következő:

USE tempdb;
-- készítünk egy számla táblát
CREATE TABLE dbo.Szamla (
a int identity,
b varchar(10) PRIMARY KEY,
--csak azért kell ez a primary key, mert így a legkönnyebb sikertelen beszúrásokat szimulálni később
szamlaszam int)
GO

-- meg egy tárolt eljárást
CREATE PROCEDURE dbo.usp_UjSzamla
@b varchar(10)
AS
-- ha nem sikerül a számlarekord elmentése, ez a beállítás megakadályozza, hogy továbbfusson a script, és feleslegesen húzzon sorszámot
SET XACT_ABORT ON
declare @a int, @szla int
INSERT INTO dbo.Szamla(b) VALUES(@b)
SELECT @a = SCOPE_IDENTITY()
-- itt hívjuk meg a sorszámosztót, ha sikeresen elmentettük a számlát
EXEC dbo.usp_AsyncSeq @val = @szla OUTPUT;
UPDATE dbo.Szamla SET szamlaszam = @szla WHERE a = @a;
-- kikapcsoljuk a szigorúságot
SET XACT_ABORT OFF
GO

--és kipróbáljuk:
EXEC dbo.usp_UjSzamla 'PROBA'
EXEC dbo.usp_UjSzamla 'PROBA'
EXEC dbo.usp_UjSzamla 'PROBA2'

select * from dbo.Szamla
select * from dbo.AsyncSeq

Az eredeti tárolt eljárásban megüthette az ember szemét a SAVE TRAN(SACTION) utasítás. Ez pont olyan, mint a SAVE GAME a játékokban: vissza lehet állni a mentett állapotra. Igen, egy tranzakción belül, tulajdonképpen részleges rollback, ami ugye nincs. De mégis van. Erről a témáról hamarosan lesz egy cikk a Technet portálon, egyelőre érjétek be ennyivel.

1. Az adatbázis recovery modellje simple vagy (full és bulk-logged esetén) az adott naplórész le lett backupolva.
2. A tranzakciós log szóban forgó része nem tartalmaz aktív tranzakciót, azaz minden olyan tranzakció, ami a log írásakor aktív volt, már véget ért (ha rollback lett ,akkor a rollback is véget ért).
3. Az adatbázis nincs replikálva vagy ha igen, akkor a Log Reader Agent már elolvasta az adott részt

Ezeknek a feltételeknek egyszerre teljesülniük kell. Azaz ha leállítom a Log Reader Agentet, akkor elkezd nőni a tranlog az égig, hogy ne rontsa el a replikációt. Hasonlóan elkezd nőni a log, ha sikerült egy tranzakicónak nyitva maradnia az adatbázisban, és lassan az egész tranlog aktívvá válik miatta.
Tehát ha megnő a log, érdemes a fenti pontokat ellenőrizni, körülbelül ebben a sorrendben (recovery model/utolsó log backup; legrégebbi nyitott tranzakció; replikáció esetén LRA).
Ja, még egy utolsó: a TRUNCATE LOG parancsok margójára: ha valaki rendszeresen kiadja a truncate log parancsot, akkor gondolkozzon el azon, hogy miért van full recovery model beállítva, és gyorsan állítsa át simple-re. Köszi.

1. Egy rekord többszöri kiolvasása – ha egy rekordot módosítanak, és hátrébb kerül az indexfában, uncommitted szinten simán kétszer kiolvasható.
2. Egy rekord kihagyása – pont mint az előző, csak fordítva: ha előre kerül a rekord, és átugorja az olvasás aktuális pozícióját, sosem látjuk az eredményhalmazban.
3. Sosem létezett rekord olvasása – ha egy tranzakció beszúr egy rekordot, majd később rollback lesz a sorsa, akkor az a rekord ugyan sosem került be az adatbázisba, mi mégis kiolvashattuk, ha épp arra jártunk.
4. Létező rekord kihagyása – az előző fordítottja: ha egy tranzakció töröl egy rekordot, majd később rollback lesz a sorsa, akkor az a rekord ugyan sosem került ki az adatbázisból, mi mégsem láttuk az eredményhalmazban.

Ezek után felmerül a kérdés, hogy miért volna valaki olyan állat, hogy használja? Hát, például mert őt ezek az apróságok nem zavarják. Például (úgy) tudja, hogy olyan információkat kérdez így le, amiket nem befolyásolnak a fenti esetek. Egyszerű példa: azt akarom tudni, hogy hány előfizetőm van éppen, és mindegy, hogy 15643 vagy 15641 lesz a végeredmény. És amiért az üzemeltető él-hal a read uncommitted szintért: amikor fut egy masszív update/insert, ami mondjuk tízmillió rekordot darál végig, akkor a read uncommitted tökéletesen alkalmas arra, hogy megnézzük, hol is tart a processzünk, hacsak nem lőttünk annyira a teljesítményre, hogy belockoltuk az egész táblát, mert az ellen nem véd. Én például gyakran használom erre, sikerrel.
Aki hatékonyságra vágyott, az a read committed és uncommitted párokkal játszhatott, már SQL 2000 óta, és azért gondolkodhatott el a fejlesztők nyílt lángnak való kitételén, mert esetleg kikacsintott a világba, és látta, hogy az Oracle hogyan kezeli ezt az érdekes kérdést. Ott row versioning (sorverziózás) volt (van), és nem kellett választani, hogy kétes adatokat olvasson az alkalmazás, vagy nem-sokkal-többfelhasználós legyen. Egyszerűen annyit tett az adatbázis motor, hogy a módosuló soroknak az eredeti verzióját eltárolta, és aki ki akarta olvasni őket, azt a tárolt másolathoz irányította. Ez az evolúciós előny azért nem maradt az Oracle sajátja, az SQL 2005 enterprise babérokra töréséhez elengedhetetlen volt egy ilyen vagy hasonló megoldás megjelenése. Végül az ilyen mellett döntöttek. Mondhatni, hogy koppintották az ötletet, én sokkal inkább a migráció megkönnyítésére szavazok :)
Szóval az SQL Server 2005-ben megjelent a SNAPSHOT isolation level, amit egyrészt külön be kell kapcsolni az adatbázisban, másrészt kétféleképpen használható: használhatjuk teljesen új izolációs szintként, akár a korábban emlegetett kettőt, illetve lecserélhetjük a read committed izolációs szintet adatbázis szinten snapshot működésre (miután a snapshotot magát engedélyeztük), azaz ha valaki azt gondolja, hogy a default read committed szinten van, akkor téved, mert valójában snapshoton lesz. Ez tuljadonképpen azt jelenti, hogy akkor a default read committed szint helyett igazából default snapshot (sorverziózós) izolációs szintünk lesz, mint az… Oracle-ben… (mondtam már, hogy a migráció…? :) Persze megrögzött mániákus read committed rajongók számára van kiút (vagy visszaút) innen is.
Ennyi blabla után némi kód, először egy szálon, csak hogy ízlelgessük az utasításokat:

USE AdventureWorks
-- (1) Ha nem mondunk semmi extrát...
SELECT * FROM Sales.Currency
-- (2) ...akkor az olyan, mintha azt mondtuk volna, hogy
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM Sales.Currency
-- (Már ha az adatbázisunkon nem állítottuk be a READ_COMMITTED_SNAPSHOT értéket, amit nézzünk is meg, az ALLOW_SNAPSHOT_ISOLATION opcióval együtt.)
SELECT * FROM sys.databases
WHERE name = 'AdventureWorks'
-- Tekintsük meg a snapshot_isolation_state, snapshot_isolation_state_desc és is_read_committed_snapshot_on oszlopok tartalmát.
-- Alaphelyzetben minden ki van kapcsolva.

Persze ez az egész akkor lesz érdekes, amikor több tranzakciónk fut egyszerre. Úgyhogy nyissunk három query ablakot (A és B konkurrálgatnak, C-ben pedig megfigyelünk), és teszteljünk (a kommentben lévő sorszámok jelzik a futtatási sorrendet, a betűk pedig a processzeket):

-- (1) A
USE AdventureWorks
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT * FROM Sales.Currency WITH (HOLDLOCK)
WHERE CurrencyCode = 'HUF'

-- (2) B
USE AdventureWorks
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
SELECT * FROM Sales.Currency WITH (HOLDLOCK)
WHERE CurrencyCode = 'HUF'

Ezek eddig boldogan lefutottak. Az explicit read committed deklaráció amúgy felesleges, a with (holdlock) locking hint és a tranzakció pedig azért vannak ott, hogy meg tudjuk nézni az allokált lockokat, különben azok azonnal eltűnnének ahogy lefutott a lekérdezés.

-- (3) C
select request_session_id, resource_type, resource_database_id, resource_description, request_mode, request_type, request_status from sys.dm_tran_locks
where request_session_id in (61, 62)
order by request_session_id

Látszik, hogy mindenen két lock van, és a rekordunk KEY alapján van lockolva, mégpedig shared (S) formában, azaz többen is olvashatják egyszerre (mint mi most). (61 és 62 az A és B ablakok SPID-jei, igény szerint módosítandóak)
Próbáljunk meg írni:

-- (4) B
ROLLBACK
BEGIN TRAN
UPDATE Sales.Currency
SET [Name] = 'Magyar Forint'
WHERE CurrencyCode = 'HUF'

A B szál nem fut le, futva marad, mivel szeretné exkluzív (X) lockolni a módosításhoz a rekordot, de azon – mivel éppen olvassák – S lock van, úgyhogy várni kell. Hogy néz ez ki a lockok nyelvén?

-- (5)
select request_session_id, resource_type, resource_database_id, resource_description, request_mode, request_type, request_status from sys.dm_tran_locks
where request_session_id in (61, 62)
order by request_session_id

A B szál tett egy update (U) lockot a S lock mellé a rekordra, és szeretné megkapni az X lockját, de az CONVERT státuszban maradt, mert az S mellé nem fér oda az X (általában: semmi mellé nem fér oda az X). Dobjuk el az A szál által nyitott tranzakciót, hadd fusson ez tovább, és rögtön kérdezzünk is egyet:

-- (6) A
ROLLBACK
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

Megfordultak a szerepek, most A vár B-re, aki a ROLLBACK kiadásakor hirtelen lefutott, és betette az X lockját végre. Nézzük is meg:

-- (7) C
select request_session_id, resource_type, resource_database_id, resource_description, request_mode, request_type, request_status from sys.dm_tran_locks
where request_session_id in (61, 62)
order by request_session_id

Látjuk, hogy az A szálnak WAIT-ben maradt a S lockja. Rollbackeljük B tranzakcióját is! (Grétsy tanár úr sem mondta volna szebben)

-- (8) B
ROLLBACK

(A 9-es lépés eltűnt, mivel kivettem a tranzakció nyitását a 6-osból, így nem kell rollback.)
Most nézzük meg az uncommitted szintet is! Nyissunk egy update tranzakciót:

-- (10) B
BEGIN TRAN
UPDATE Sales.Currency
SET [Name] = 'Magyar Forint'
WHERE CurrencyCode = 'HUF'

A (6)-nál már láttuk, hogy ilyenkor kiakadunk read committed szinten. Nézzük mi történik uncommitted esetben:

-- (11) A
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

Simán lefutott, és visszaadta azt az értéket, amit a B tranzakción belül adtunk meg, ami még nyitott, és nincs kommittálva. Megállapíthatjuk, hogy találó nevet kapott a read uncommitted. Rollbackeljük a tranzakciót…

-- (12) B
ROLLBACK

… és kérdezzük le megint ugyanezt:

-- (13) A
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

Most a megfelelő, konzisztens értéket kapjuk vissza.
Lépjünk tovább a SQL 2005 nagyszerű újítása, a nem lockokkal operáló snapshot szint felé:

-- (14) B
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

Szép piros outputot kapunk, melyben elmeséli a SSMS, hogy szerinte nem jó vicc olyan adatbázisban snapshot izolációs szintet használni, ahol nincs engedélyezve. Nézzük meg ezt
T-SQL-ből is (15a), majd engedélyezzük (15b) egy egyszerű alter database paranccsal a snapshotot:

-- (15a) C
SELECT name, database_id, snapshot_isolation_state_desc, is_read_committed_snapshot_on FROM sys.databases
WHERE name = 'AdventureWorks'
-- (15b) C
ALTER DATABASE AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION ON

SELECT name, database_id, snapshot_isolation_state_desc, is_read_committed_snapshot_on FROM sys.databases
WHERE name = 'AdventureWorks'

Most még egyszer ugorjunk neki az előzőnek:

-- (16) B
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

A transaction isolation level már be lett állítva az előbb, hiszen az a session tulajdonsága, nem az adatbázisé, nem is tudom miért írtam ki még egyszer… Na, kezdjük újra az író-olvasó találkozót, és írjunk egyet az A szálon:

-- (17) A
BEGIN TRAN
UPDATE Sales.Currency
SET [Name] = 'Magyar Forint'
WHERE CurrencyCode = 'HUF'

Nézzük meg, melyik szinten mit látunk B-ben. (18a)-t és (18b)-t külön futtassuk:

-- (18a) B
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

-- (18b) B
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

USE tempdb

Az első esetben a snapshot szinten az utolsó kommitolt értéket olvashattuk ki, várakozás nélkül. Ez a sorverziózás áldása, nem kell várakozni vagy szemetet olvasni. A második esetben az uncommitted szinten kiolvastunk valamit, ami még nincs is hivatalosan az addatbázisban. A harmadik esetben pedig lógva maradtunk, hiszen az X lock megakasztott minket. Rollbackeljük a tranzakciónkat. (a USE tempdb-ről később)

-- (19) A
ROLLBACK
USE tempdb

És most, hogy mindkét processzünket kiraktuk az AdventureWorksből, megtehetjük azt, ami nekem nagy kedvencem ebben az egész játékban:

-- (20) C
ALTER DATABASE AdventureWorks SET READ_COMMITTED_SNAPSHOT ON

Ehhez a művelethez nem lehet más az adatbázisban, csak az az egy processz, amelyik kiadja a parancsot, ezért mentek át a többiek a tempdb-be. És mostantól kezdve amikor az mondjuk, hogy read committed, akkor az SQL Server 2005 az AdventureWorks adatbázisban sorverziózást fog használni. Játsszuk újra az előző ki mit lát játékot:

-- (21) A
USE AdventureWorks
BEGIN TRAN
UPDATE Sales.Currency
SET [Name] = 'Magyar Forint'
WHERE CurrencyCode = 'HUF'

És kérdezzük végig a három szintet:

-- (22) B
USE AdventureWorks
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

SET TRANSACTION ISOLATION LEVEL SNAPSHOT
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM Sales.Currency
WHERE CurrencyCode = 'HUF'
-- hoppa :)

Jé, most lefut a read committed is, pedig neki várnia kellene az X lock miatt… de nem teszi… mert ő egy álruhás snapshot igazából. Ezt a kis trükköt egyedül a sys.databases-ből lehet kideríteni (lásd (15a)), mert ha a sys.dm_exec_sessions nézetből kérdezzük, ott is read committed a szint.

-- (23) C
SELECT name, database_id, snapshot_isolation_state_desc, is_read_committed_snapshot_on FROM sys.databases
WHERE name = 'AdventureWorks'

Tüntessük el játszadozásunk nyomait:

-- (24) A
ROLLBACK

kill 61
kill 62
ALTER DATABASE AdventureWorks SET READ_COMMITTED_SNAPSHOT OFF
ALTER DATABASE AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION OFF

Ennyit elsőre, később majd az innen kimaradt, konkurrenciát csökkentő szintekről is esik némi szó, de ezt is két hónapja kezdtem el írni :)

A demo script letölthetőitt.