Soci blog

A következő néhány hónapban minden nap rászánok kevés időt, hogy az SQL Server 2008-ba belemélyedjek, közben igyekszem dokumentálni a blogomban az újdonságokat. A cikkekben semmilyen tematika vagy sorrend nem lesz, egyszerűen csak magozok az elém kerülő újdonságokból.

Az első új fícsör a tábla típusú paraméterátadás. Ez finom dolog lesz, nem kell stringekbe serializálni a paramétereket, nem kell xmlt használni, hanem egyszerűen át lehet passzintani egy tábla típusú változót a hívott eljárásnak.

Ehhez a CREATE TYPE került felokosításra, ami már nem csak aliasokat tud (SQL Server 7), vagy CLR típusokat (SQL Server 2000), hanem tábla típusokat is (SQL Server 2008). Pl.

CREATE TYPE LocationTableType AS TABLE
(
LocationName VARCHAR(50),
CostRate INT
)

Aztán paraméterként így lehet használni mondjuk spben:

CREATE PROC Ize
(
@par LocationTableType
)

Komplett példa itt látható.

Belül mint egy sima táblát lehet joinolni, stb.

Miért is jó a BOL szerint:

Do not acquire locks for the initial population of data from a client.
Do not cause a statement to recompile.
Provide a simple programming model.
Enable you to include complex business logic in a single routine.
Reduce round trips to the server.
Can have a table structure of different cardinality.
Are strongly typed.
Enable the client to specify sort order and unique keys.

Az első pont mindjárt kíváncsivá tett, hogy lehet ADO.NET-ből feltölteni a tábla paramétert. Zseniálisan egyszerűen, sima DataTable-t kell feltölteni, és már mehet is be a szervernek. Állat.

Ezer éve foglalkoztat ez a kérdés, hátha valaki tudja rá a választ. Minek megadni az sp_addmessage-nél a severity levelt, state-et és egyéb paramétereket, ha ezek úgyis kötelezők, amikor RAISERROR-ral felnyomjuk a hibát?

Ugye, ő akkor hívódik meg, ha a connection poolból az ADO.NET elővesz egy használt connection-t (és, ha nem kapcsoljuk ki :).

Nos, itt a lista, mit is csinál ő:

It resets all error states and numbers (like @@error)
It stops all EC’s (execution contexts) that are child threads of a parent EC executing a parallel query
It will wait for any outstanding I/O operations that is outstanding
It will free any held buffers on the server by the connection
It will unlock any buffer resources that are used by the connection
It will release all memory allocated owned by the connection
It will clear any work or temporary tables that are created by the connection
It will kill all global cursors owned by the connection
It will close any open SQL-XML handles that are open
It will delete any open SQL-XML related work tables
It will close all system tables
It will close all user tables
It will drop all temporary objects
It will abort open transactions
It will defect from a distributed transaction when enlisted
It will decrement the reference count for users in current database; which release shared database lock
It will free acquired locks
It will releases any handles that may have been acquired
It will reset all SET options to the default values
It will reset the @@rowcount value
It will reset the @@identity value
It will reset any session level trace options using dbcc traceon()

Eszembe jutott három mítosz, amely gyakran rosszul van implantálva az emberek agyába (sokáig belém is).

1. A tábla típusú változók memóriában laknak. NEM, NEM, NEM. Sajnos sokáig én is terjesztettem ezt, annak ellenére, hogy állandóan ott volt a fejemben, hogy ha nagy a tábla, akkor page-elni fog a szerver, amit utál? Nem, a tábla típusú változó nem más, mint speciális temp tábla.
Bővebben itt. Érdemes figyelni (és kihasználni) a tranzakcionális különbségeket és a recompiling viselkedés különbözőségét (2005-től mondjuk már nem akkora gáz az újrafordítás az utasítás-szintű újrafordítás miatt).

2. A BACKUP DATABASE (full backup) truncate-olja a logot. NEM, NEM, NEM. Ez még valahol logikus is lenne amúgy, hisz minek a log, ha úgyis van full backup, csak az utána következő log lehet érdekes. Nos, itt paranoiás módon álltak a kérdéshez. Ha esetleg elveszne az utolsó full backup, de még megvan az utolsó előtti, és a tranzakciót se csonkolták, akkor a kettőből összerakható a teljes kép.

3. A TRUNCATE TABLE gyors, de nem visszagörgethető, mert nem logolt művelet. CSUDÁKAT, NEM! Nem nem logolt, minimálisan logolt. Csak azt rakják be a logba, hogy mely lapokat érintett a művelet, és nem soronként logolnak, így sokkal gyorsabb, mint a delete. De logol, és visszagörgethető. Tessék kipróbálni.