Elsőként átteintjük, mi is került a gépünkre az SQL 2012 telepítése során. Milyen biztonsági, nyelvi és egyéb beállításokat kaptunk, és ezeknek mi a hatása az SQL Server további életére? Ezt követően végignyomkodjuk az SQL Server Management Studió legfontosabb részeit: az Object Explorert (adatbázisok, táblák, nézetek stb.), a Query ablakot (lekérdezések futtatása) és az Activity Monitort, mindegyikben végrehajtunk egy-egy jellemző feladatot (pl. adatbázis és tábla létrehozása). Vetünk egy futó pillantást a végrehajtási tervekre is, amivel komolyabban a teljesítménytuningolás fejezetben fogunk foglalkozni. Ezt követően megismerkedünk az SQL Profiler eszközzel, ami minden rendszergazda és fejlesztő csodafegyvere az SQL Server "ellen" vívott harcban.

Elsőként néhány DDL (Data Definition Lanuage) utasítással ismerkedünk meg, mint például CREATE TABLE és társaik. Ennek az a célja, hogy ne csak egerészve tudjuk objektumokat létrehozni, hanem értelmezni tudjuk a TSQL scripteket is. A DDL-szenthármas a következő utasításokból áll: CREATE, ALTER, DROP. Amikor pedig készítettünk egy egyszerű táblaszerkezetet, végigvesszük a legfontosabb SQL-parancsok működését. Lesz itt egyszerű SELECT, de persze szűrés, sorbarendezés és csoportosítás is. Emellett megnézzük, hogyan kell használni az adatmódosító utasításokat (INSERT-UPDATE-DELETE) különböző nehézségű feladatok esetén.

Összetett SELECT utasítások alatt a csoportosításokat (GROUP BY), összegzéseket, a táblák összekapcsolását végző JOIN-t, valamint a beágyazott SQL parancsokat értjük. Fontos ismeret, hogy hogyan kell több táblát összekapcsolni, és lekérdezni azokat a vevőket, akiknek a rendelésszáma nagyobb mint X, vagy éppenséggel azokat, akik nem vásároltak tűlünk semmit (OUTER JOIN). A beágyazott lekérdezések pedig lehetővé teszik, hogy mindenhová SQL-lekérdezést írjunk, ahová kifejezést lehet írni: mezők helyére, JOIN után tábla helyett stb.

Az SQL Server adattípusainak, valamint a normalizálási szabályoknak az ismeretében már bárki elkezdhet nem túl tragikus szerkezetű adatbázisokat megtervezni és létrehozni. Mi legyen az elsődleges kulcs? Mit hoz létre pontosan a PRIMARY KEY "konsztrént" Mi az az IDENTITY? Külön kisregény a változó hosszúságú (VAR...) szöveges oszlopok kérdésköre. Az egyes adattípusokon túl megismerkedünk a NULL különleges szerepével és kezelésével. Végezetü, egy picit eljátszadozunk a nem tipikus adattípusokkal: XML és Spatial. Ezek mindegyike önmagában külön tudományág, ám nem is olyan ördögnös feladat egy használható példát összerakni példul a geokoordináták tárolására alkalmas geography adattípus működésének demonstrálására.

Az SQL Serverben két különálló lépésre bomlik a bejelentkezés (autentikáció) és jogosultságszerzés (autorizáció). Az elsőt akár a Windowsra is bízhatjuk, a második azonban mindig az SQL Server feladata. Ki az az SA? És kicsoda DBO? Hogyan adjunk jogosultságot élő és élettelen (pl. IIS Service) felhasználóknak? Mit tehet a Public(um)? GRANT, REVOKE és DENY utasítások szerver- és adatbázisszinten. Hozzá kell tenni, hogy mindennapi felhasználás során gyakori, hogy az SQL-adatbázis egyfelhasználós (mondjuk egy webkiszolgáló a "felhasználója", nekünk mégis különálló hozzáférési megoldásokat kell megvalósítanunk. Egy júzer esetén hogyan? Hát nézetekkel (View) és tárolt eljárásokkal! Lássuk a nézetek (View) használatát a "mindennapokban"!

Ennek a fejezetnek az a célja, hogy demisztikáljuk a tárolt eljárásokat, függvényeket, triggereket. Ez egy hatalmas témakör, aminek csak a felszínét fogjuk érinteni, a málységeket meghagyjuk a progrmozóknak. Odáig azonban eljutunk, hogy készítünk egy-két tárolt eljárást egyszerű feladatok elvégzésére, létrehozunk minden függvénytípusból (skalár, összegző, táblatípusú) egyet-egyet, valamint készítünk egy Móricka-triggert, ami megakadályozza, hogy egy táblán "illetéktelen" módosításokat hajtsunk végre. Megismerkedünk a DELETED-INSERTED memóriatáblákkal is. A fejezet részét képezi a nem-halmazorientált parancsok ismertetése (ciklus, elágazás, változók)

Az SQL Server a legstabilabb szerverszolgáltatások egyike, pont. Ennek ellenére az adatok mentése és visszaállítsa rutinfeladat kell, hogy legyen, mert ha nem az SQL Server hal be, akkor majd a vas. Arra is van reális esély, hogy a legveszélyesebb felhasználó, a SysAdmin követ el valami halálos adatmódosítást. Egy szó mint száz, menteni kell. Az SQL Server esetén ez nem is annyira könnyű, mivel a képbe bezavar a tranzakciónapló és a recovery üzemmód. Ezeket nem csak fogalom, hanem a gyakorlat szintjén ismerni kell, hogy a megfelelő mentési stratégiát kiválaszthassuk. A visszaállítás pedig innentől már gyerekjáték ... hacsak fent nem akadunk az éles adatok védelmét és a véletlen visszaállítást kiküszöbölő szűrők valamelyikén. Ezt tanulni kell!

A pillanatfelvételek, vagy magyarul snapshotok egyszerű, egylépéses visszaállítást tesznek lehetővé azon az áron, hogy valakinek a snapshotokkal is foglalkoznia kell: létrehozás, letörlés stb.

A 2012 újdonságai közül az Always On technológiacssalád érdemel még említést: tükrözünk és (akinek egynél több gépe van) fürtözünk.

Már az előző fejezet elég erőteljesen tuningszagú volt, az igazi munka azonban csak most kezdődik. Ezidáig értelmes indexet még nem készítettünk, pedig ezek adják a teljesítményhangolás alfáját és omegáját. Megismerkedünk a kétféle indextípussal (clustered és normál), (szemet hunyunk a további indextípusok (pl. XML) felett...), felépítésükkel, készítésükkel és használatukkal. Ezen az akalmon gyakran fogjuk nézegetni a végrehajtási terveket, hogy lássuk, ténykedésünk valódi hatással járt-e. Az indexstatisztikák működésének ismerete segít belátni, hogy nem minden index jó index, sőt, vannak teljesen vacak, felesleges indexek is. Végül úgynevezett optimizer hintekkel ráerőszakoljuk egyik-másik indexünket az SQL Serverre, hadd szenvedjen, és mi lássuk, milyen is az, amikor egy nem túl jó indexszel esik neki egy feladatnak.

Komolyabb rendszereknél már nem egyedi adatmódosító utasításokkal lavírozunk, hanem bizony összefogjuk azokat egy-egy tranzakcióba. Tanuljuk meg, mitől "savas" (ACID) egy tranzakció, és ez milyen váltázásokat okoz a rendszer életében, különösen többfelhasználós környezetben. Mik azok a zárak? Kik nyitják-zárják azokat? Mi a céljuk, Ki kit zár ki, és mennyi időre? Mitől olyan TETŰ LASSÚ az SQL Server? Ki tehet róla? Hogyan lehet ezeket montorozni, az ütközéseket feltárni, a normális működést helyreállítani? Az Activity Monitor szerepe.

Végezetül "megalkotunk" egy deadlockot, hogy mindenki a saját bőrén tapasztalja, milyen is az, amikor egy tranzakció elszáll.

Az SQL Server fejlett adatátviteli képességekkel rendelkezik. Elsőként a varázslatos Export-Importot tekintjük meg, és adatot viszünk át Excelből SQL Serverbe, onnan a Felhőbe stb. Sajnos a varázslat egy bizonyos ponton megbukik: a felhőbe - érdekes módon - unintelligens módon, az IDENTITY-k elveszejtésével tud csak adatot feltolni. Ilyen esetekben az ember a parancssorba menekül, és a jó öreg BCP parancsot használja adatátvitelre.
Egy másik nagy területe az adatátvitelnek a sémaszinkronizáció. Ha egy adatbázis szerkezete változik itt, hogyan kerül át a változás amoda? Az SQL 1012 megjelenéséig erre a feladatra nem volt Microsoftos eszköz. Most van. A neve: SQL Server Data Tools.

Milyen szép is lenne, ha a mentésekkel, indexstatisztika-számításokkal, konzisztenciaellenőrzésekkel nem kellene személyesen foglalkoznunk, hanem azt az SQL Server automatikusan elvégezné! Jó hírünk van, nemcsak hogy elvégzi éjszakánként, de még ráadásul levelet is küld a feladatok sikerességéről. Ebben a fejezerben a Maintenance Wizardot és az SQL Agentet vesszük górcső alá, különös tekintettel a gyakori feladatok automatizásására.

Ebben a fejezetben - mintegy gyakorlásképpen is - az eddigi feladatokat (már ami értelmezhető a felhőben) fogjuk elvégezni SQL Azure adatbázison, kezdve az adatbázis létrehozásától a tuningolásig. Mi érhető el a felhőben, és mi nem, és ami nem, az miért? Hiányzik-e nekünk például a mentés-visszaállítás? Ezt követően a DataSync komponenssel vívunk meg, hogy lehozzuk a felhőből az adatot a mi gépünkre.

Egy mindennapi használatra szánt SQL-tanfolyam nem lenne teljes a "másik oldal" valamilyen szintű ismerete nélkül. Éppen ezért esünk neki a
Móricka-webalkalmazás elkészítésének ASP.NET MVC renszerrel. Ami itt SQL, az ott is, csak LINQ a neve. Ami itt tábla, az ott is, csak objektum
a neve. Am itt lekérdezés, az ott is, csak weblap a neve. Ami itt adatmódosítás, az ott is, csak űrlap (form) a neve. A hagyományos táblázatos megjelenítésen és szerkesztésen kívül lesz itt autentikáció, képkezelés, és sok minden más. Nem kell félni, nem fog fájni! (Egy ingyenes Visual Studióra azonban mindenkinek szüksége lesz.)

A Reporting Services ismerete nélkül nem lehhe teljes a tanfolyam. Ma már nem igazán érdemes semmiféle adatmegjelenítő oldalt kézzel összetákolni, ha egyszer a Reporting Services gyakorlatilag mindent tud. Akár varázslással is messzire lehet jutni, programozással meg aztán tényleg mindent meg lehet vele csinálni.

Utolsó fejezetünkben az SQL 2012 újdonságait fogjuk csokorba. Van itt minden, amire már régen vártunk: szekvenciaobjektum, format függvény, hibakezelési újdonságok, lapozós lekérdezések a programozói oldalon és Always On az üzemeltetői oldalon.