Az SQL Server 2008 adatbáziskezelő

Az SQL Server 2008 adatbáziskezelő

Hallgatói segédanyag

a Szoftver Laboratórium 5. tárgy 1. gyakorlatához

Készítette: Benkő András 2009 augusztus

1

Tartalomjegyzék 1. BEVEZETŐ .................................................................................................................................................................. 3 2. AZ SQL SERVER SZOLGÁLTATÁSAI .................................................................................................................... 3 2.1 ADATBÁZIS MOTOR (DATABASE ENGINE) .................................................................................................................. 3 2.2 REPLIKÁCIÓ .............................................................................................................................................................. 3 2.3 GLOBÁLIS KERESÉS (FULL-TEXT SEARCH) ................................................................................................................ 3 2.4 ANALYSIS SERVICES .................................................................................................................................................. 3 2.5 INTEGRATION SERVICES ............................................................................................................................................ 4 2.6 REPORTING SERVICES ............................................................................................................................................... 4 3. ARCHITEKTÚRA ....................................................................................................................................................... 4 3.1 ALAPFOGALMAK ....................................................................................................................................................... 4 3.2 KAPCSOLÓDÁS .......................................................................................................................................................... 4 3.3 LOGIKAI FELÉPÍTÉS ................................................................................................................................................... 5 3.4 FIZIKAI FELÉPÍTÉS ..................................................................................................................................................... 5 3.5 MENEDZSMENT ÉS FELÜGYELET ............................................................................................................................... 5 4. LOGIKAI MODELL.................................................................................................................................................... 5 4.1 KOMPONENSEK ......................................................................................................................................................... 5 4.2 ADATTÍPUSOK (DATA TYPES) ..................................................................................................................................... 6 4.3 INDEXELÉS ................................................................................................................................................................ 8 4.4 RENDSZERADATBÁZISOK (SYSTEM DATABASES)........................................................................................................ 8 4.5 RENDSZERTÁBLÁK (SYSTEM TABLES) ....................................................................................................................... 9 5. FIZIKAI MODELL .................................................................................................................................................... 10 5.1 ADATFÁJLOK (DATA FILES) ...................................................................................................................................... 10 5.2 LAPOK ÉS EXTENTEK (PAGES & EXTENTS) .............................................................................................................. 10 5.3 FÁJLCSOPORTOK (FILEGROUPS)............................................................................................................................... 11 5.4 PARTÍCIÓK (PARTITIONS) ......................................................................................................................................... 11 5.5 FILESTREAM............................................................................................................................................................ 11 6. TRANZAKCIÓKEZELÉS ........................................................................................................................................ 12 6.1 ATOMICITÁS ............................................................................................................................................................ 12 6.2 KONZISZTENCIA ...................................................................................................................................................... 12 6.3 IZOLÁCIÓ ................................................................................................................................................................ 12 7. BIZTONSÁG............................................................................................................................................................... 13 7.1 LOGIN ÉS FELHASZNÁLÓ ......................................................................................................................................... 13 7.2 JOGOSULTSÁGOK..................................................................................................................................................... 13 7.3 SZEREPEK ............................................................................................................................................................... 14 7.4 SÉMÁK (SCHEMAS) ................................................................................................................................................. 14 7.5 SZINONIMÁK (SYNONYMS) ..................................................................................................................................... 14 8. RENDSZERMENEDZSMENT ................................................................................................................................. 14 8.1 KAPCSOLÓDÁS A SZERVERHEZ ................................................................................................................................ 15 8.2 OBJECT EXPLORER .................................................................................................................................................. 15 8.3 EGYÉB PANELEK...................................................................................................................................................... 15

2

1. Bevezető Az SQL Server a Microsoft által kifejlesztett relációs-adatbáziskezelő, és mint ilyen alapvetően kliens-szerver felépítésű. Az adatbázisban tárolt adatokhoz való hozzáféréshez a kliensek az ANSI által szabványosított SQL nyelvet használják, amelyet az adatbáziskezelő értelmez és végrehajt, majd az eredményt visszaküldi a kliensnek. Az SQL nyelv első szabványosítása 1986-ban történt, de a nyelv azóta is változik/bővül. Az SQL ugyan szabványos lekérdező nyelv, de az egyes adatbázis-kezelők más-más dialektusát beszélik, tehát sajnos a gyakorlatban mégse teljesen független a fejlesztő az adatbázistól. Az SQL Server a Transact-SQL nyelvet használja, amely – ahogy az összes más adatbáziskezelő saját nyelve - kibővíti az SQL szabványt, és egyúttal lehetőséget teremt a szerveroldali programozásra (bővebben később). Jelen segédlet célja, hogy bemutassa az SQL Server 2008 adatbáziskezelő logikai és fizikai felépítését, illetve a működésének a fontosabb aspektusait. A segédlet feltételezi az Adatbázisok c. tárgy anyagának az ismeretét is.

2. Az SQL Server szolgáltatásai 2.1 Adatbázis motor (Database engine) Az adatbázis motor a relációs adatbázisok fő funkcionalitását adja: adattárolás, hozzáférés, indexelés, szerveroldali programozás és tranzakciókezelés stb (OLTP – Online Transaction Processing). Ezen segédlet (és az egész félév) elsősorban ennek a szolgáltatásnak a felépítéséről és az alkalmazásairól szól. Az adatbázis manipulálásához SQL Server Management Studio-t használhatunk (SSMS), ha monitorozni akarjuk az adatbázis működését, akkor pedig az SQL Server Profiler áll rendelkezésünkre (események elkapása).

2.2 Replikáció A replikációs módszerek lényege adatok megosztása különböző adatbázis-csomópontok között a redundancia és ezáltal a megbízhatóság növelése érdekében. Fontos részét képezi ennek az adatok közötti szinkronizáció fenntartása illetve annak a megállapíthatósága, hogy két különböző helyről kiolvasott adat vajon ugyanazt a mögöttes tartalmat hivatott-e jelképezi (ugye a tartalomszinkronizáció szükségessége is ezután válik eldönthetővé, amennyiben ez a tartalom nem egyezne).

2.3 Globális keresés (Full-text search) Egzotikus szolgáltatás, amellyel a tárolt strukturálatlan adatokon (pl. sztring) lehet keresni és a keresést az adatbázis végzi. A full-text keresés kezdeményezése szintén SQL-en keresztül lehetséges. Támogatja a szóközelség alapú- vagy több kulcsszavas kereséseket is. Komoly követelményeket támaszt az adatbázissal szemben (speciális indexstruktúrák).

2.4 Analysis Services Az Analysis Services a különböző távoli forrásokból származó adatok mélyebbre ható elemzését teszi lehetővé, azaz adatbányászati képességekkel is rendelkezik, így az OLAP (Online Analytic Processing) fő funkcióit nyújtja, amelyeket elsősorban az üzleti döntéstámogatásban alkalmaznak. Az adatok ábrázolása teljesen testreszabható komplex logika szerint, emiatt eltérő jellegű adatbázist képvisel, mint a klasszikusak, az OLTP-adatbázisok és általában egy vagy több ilyenre is épül.

3

2.5 Integration Services Az Integration Services a több, akár különböző fajtájú adatforrásból (nem feltétlen adatbázisból) származó adatot egységesít, hogy azok ezentúl egy adatbázisnak látszódjanak leegyszerűsítve az adminisztrációt tehát végeredményben adatbázist virtualizál. Egyik fontos felhasználási területe az üzleti folyamatok automatizálása.

2.6 Reporting Services Ezen szolgáltatás egy összetett monitorozó funkciót ad hozzá az érintett adatbázisokhoz. A közölt adatok fajtája és a közlés (reporting) módja persze változhat így használata előnyös lehet a rendszermenedzsment több területén (pl. esemény-monitorozás, biztonsági naplózás, teljesítményelemzés).

3. Architektúra 3.1 Alapfogalmak A szerver alatt egy szerverpéldányt (instance) értünk, ami a szerver futtatásához szükséges folyamatok, szálak összessége illetve egy vagy több adatbázist (database), amelyben tárolódnak a felhasználói- és rendszeradatok. Egy számítógépen több szerverpéldány is futhat és egy szerverpéldányhoz több adatbázis is tartozhat. Tehát az egyes adatbázisok elsődlegesen a szerverrel köthetők össze. Az adatbázisok a szerverről lecsatolhatók (néhány kivételével) majd hozzácsatolhatók más szerverekhez. Az SQL Server lehetőséget teremt a különböző szerverekhez tartozó – tehát akár térben elosztott - adatbázisok közötti adatintegrációra is. Ez transzparens módon működik a kliens számára.

1. ábra: Az SQL Server általános architektúrája

3.2 Kapcsolódás Az SQL Server – akárcsak a legtöbb adatbáziskezelő – nagymértékben párhuzamos igénybevételre van tervezve. Nem szükséges több szerverpéldányt futtatni ugyanazon a gépen ha egyszerre több felhasználót szeretnénk beengedni a rendszerbe. Egy szerveren akár többezer több adatbázist érintő tranzakció futhat egyszerre. Amikor egy felhasználó csatlakozik a szerverhez rögtön egy adatbázishoz lesz hozzárendelve (amennyiben nincs specifikálva, hogy melyikhez a profiljában szereplő alapértelmezett adatbázishoz), azonban a szerveren tárolt összes adatbázis elérhető lesz számára (ha engedélyezve van az ezekhez való hozzáférése) és válthat melyiken kíván dolgozni.

4

Kétféle hitelesítési módszer létezik: Windows autentikáció és SQL Server autentikáció. A Windows autentikáció egybe van építve a szervert futtató Windows fiók autentikációjával. Az SQL Server autentikáció kiválasztásával viszont kizárólag a szerver saját címtárából fog történni a hitelesítés.

3.3 Logikai felépítés A tárolás legfőbb logikai egysége az adatbázis, amelyből egy szerveren több is lehet. Egy adatbázis valójában tipizált oszlopokból álló táblák gyűjteménye. Az adatbázisok alapvetően két csoportba oszthatók a bennük tárolt adatok alapján: rendszeradatbázis, amely rendszeradatokat tárol és szerverenként egyedi illetve felhasználói adatbázis, amely tetszőleges adatot tárol. Az adatbázisban levő adatok strukturáltak és táblákban vannak eltárolva (bővebben 4. Logikai modell).

3.4 Fizikai felépítés Az adatbázis fizikailag ugyanúgy fájlok gyűjteménye a szerverszámítógépen, ahogy bármely más adat. A strukturált adatok adatfájlokban tárolódnak a számítógép merevlemezén, bár vannak kivételek is (lásd 5.5 Filestream). Az SQL Server az adatbázis logikai modelljét láttatja számunkra, ezen az interfészen keresztül történik az összes keresés és adatmanipuláció ezek leképződnek a fizikai műveletekre (bővebben 5. Fizikai modell).

3.5 Menedzsment és felügyelet Az Transact-SQL utasításokkal teljes mértékben konfigurálható és használható a szerver. Azonban a rendszermenedzsmentet lényegesen leegyszerűsíti a kliensen futó, grafikus megjelenítéssel is rendelkező SQL Server Management Studio. A Management Studio magában foglalja az összes SQL Server szolgáltatás (mint pl. a Reporting Services) menedzsment felületét egyetlen szoftverben (bővebben 8. Rendszermenedzsment).

4. Logikai modell 4.1 Komponensek Az adatbázis (akár rendszer, akár felhasználói) főbb komponensei:  Tábla (table): az adattárolás alapegysége. Az adatok struktúrált tárolásáért felelős. Oszlopokból és sorokból áll mely megfeleltethető egy relációnak, az oszlopoknak megadható a típusa, amely meghatározza, hogy a sorok (a rekordok) az adott mezőn milyen jellegű adatot tartalmazhatnak.. A tábla, a tábla oszlopai és a táblában tárolt rekordok egyedien azonosíthatóak.  Partíciók (partitioning): A tábla partíciókra osztható, a rekordok csoportjai szét vannak osztva az egyes partíciók között (vízszintes felbontás). Alapértelmezetten az egész tábla egyetlen partíció, nincsen felbontás. Többpartíciós táblákkal skálázhatóbbá tehető az adatbázis, de bevezetésük inkább nagyméretű tábláknál javasolt, ahol sok erőforrás spórolható meg ha nem a tábla egészét szükséges módosítani/lekérni/karbantartani. Kívülről nézve a tábla, mint logikai egység atomi, a partícionálás transzparens módon működik.  Nézet (view): virtuális tábla. Különböző táblákból összeállított adatok megjelenítésére alkalmas. Fizikai tárolása azonban nincs, az adatokat csak származtatja a táblákból. Az adatbázisban is csak a nézetet létrehozó utasítás (SQL select) tárolódik. A nézetek alkalmasak arra, hogy korlátozzák a felhasználó által látható adatokat illetve, hogy átformálják az adatokat. Erre lehet példa táblák összekapcsolása, értékek aggregálása (összegzése) egy oszlopban.  Kulcs (key): az adat, amely alapján biztosan azonosítható a rekord. Egy táblának lehet több kulcsa is, de csak egyetlen elsődleges kulcsa és csak erre jönnek létre automatikusan 5

indexek.  Index: Az adatok a táblákban rendezetlenül helyezkednek el. Az indexek a rekordokhoz való hozzáférést gyorsítják és külön struktúrában tárolódnak az adatbázisban. Általában olyan oszlopra érdemes indexet létrehozni, amelyre várhatóan gyakran lesz megfogalmazva keresés. Az indexek épülhetnek olyan oszlopokra is, amelyekre nincs megkövetelve a rekordok egyedisége. Kétféle index létezik:  Fürtözött index (clustered index): az indexrekordok tárolási sorrendje megegyezik az adatrekordok tárolási sorrendjével. Mivel egynél több ellentmondásmentes rendezési sorrend nem feltétlen definiálható fürtözött index is csak egyetlen oszlopra épülhet. Az SQL Serverben a fürtözött indexek B*-fa struktúrában tárolódnak (lásd Adatbázisok, ritka index). Az indexfa alsó szintjén pedig adatblokkok (SQL Server terminológiában lapok) szerepelnek.  Nem-fürtözött index (non-clustered index): az indexrekordok sorrendje független a tárolási sorrendtől. A nem-fürtözött indexek csak olyan táblákon hozhatók létre, amelyeken szerepel már fürtözött index. Szintén B*-fa struktúrában tárolódnak ám az alsó szint speciális. Ha a tábla rendelkezik fürtözött index-szel, akkor a megfelelő kulcs lesz a levélelemben. Ha ilyen nincs, akkor egy mutató az adatrekordra.  Kényszer (constraint): az adatintegritást elősegítő szabályok egy oszlop mezőire. A tábla rekordjainak be kell tartaniuk ezen szabályokat. Miután létrehoztuk a kényszereket az SQL Server automatikusan ellenőrzi a betartásukat.  Kitöltött (not null): nem szerepelhet egyetlen rekord érintett mezőjén sem NULL érték. A NULL az adatbázisokban az ismeretlen, üres értéket jelöli.  Egyediség (unique): az összes rekord adott mezőjének értéke eltérő kell, hogy legyen.  Érték (check): az oszlop mezőinek értékére fogalmaz meg szabályokat (pl. jegy 1-5). Az érték-jellegű kényszerek akár igen összetettek is lehetnek. Például megfogalmazható, hogy az értékhatárok a rekord más mezőiből számolódjanak vagy függjenek az aktuális rendszeridőtől stb. A kényszereket egy tetszőleges igazra vagy hamisra kiértékelődő Transact-SQL kifejezéssel kell megadni. További információk: http://msdn.microsoft.com/en-us/library/ms179491.aspx  Elsődleges kulcs (primary key): gyakorlatilag a kitöltött és egyediség kényszerek együtt.  Külső kulcs (foreign key): az oszlop mezői csak egy másik tábla rekordjainak megfelelő mezőjéből kerülhet ki. A külső kulcs kényszer tehát táblák közötti kapcsolatok azonosítására szolgál (pl. kapcsolótábla, amely az emberek közötti barátságokat ábrázolja).  Alapértemezett érték (defaults): a kényszerekhez hasonló módon oszlopokra definiálható. Az alapértelmezett értéket hordozza, amivel inicializálódik a rekord, amennyiben a létrehozásakor az érintett mezőt üresen hagyták. Az érték-jellegű kényszerekhez hasonlóan bonyolult számítások eredménye is lehet egy alapértelmezett érték, de akár egy konstans is.  Tárolt eljárás és függvény (stored procedure): egy tárolt eljárás T-SQL utasítások gyűjteménye, amely a szerveroldalon futtatható (pl. egy bonyolult fáradtságos többtáblát érintő feltételes adatmódosítás) egyetlen felhasználói utasításként. Annak megfelelően, hogy ad-e vissza értéket vagy sem beszélhetünk tárolt eljárásról illetve tárolt függvényről.  Trigger: eseményekre aktiválódó tárolt eljárás. Közvetlenül nem hívható meg.

4.2 Adattípusok (data types) A táblákban tárolt adatok tipizálhatóak, az SQL Server által támogatott típusok a következőek:

6

bigint

binary

datetimeoffset decimal int

money

smalldatetime smallint timestamp

tinyint

bit float

char

date

datetime

geography geometry hierarchyid

datetime2 image

nchar

ntext

numeric

nvarchar

real

smallmoney

sql_variant

sysname

text

time

uniqueidentifier

varbinary

varchar

xml

Jelmagyarázat:  Fehér: alább kifejtett típusok.  Világosszürke: típusok melyekről nem lesz szó.  Sötétszürke: redundáns és/vagy deprecated típusok. Fontosabb típusok  Integer: Az elsődleges egész szám típus. A tinyint 1 byte-os (0-255), a smallint 2 byte-os, az int 4 byte-os, a bigint 8 byte-os.  Char(n), NChar(n): Fix hosszúságú (n hosszú) karakterlánc egyenként 1 byte-on ábrázolva ASCII kódolással. N értéke maximum 8000 lehet. Az NChar típus annyiban különbözik, hogy az Unicode kódolást és 2 byte-ot használ karakterenként, tehát maximum 4000 hosszú.  Varchar(n | max), Nvarchar(n | max): Változó hosszúságú – n-hosszúságú (n értéke 1-8000) - karakterlánc. A kódolás és a mérethatár ugyanaz, mint a Char típusnál. Az NVarchar pedig az NChar megfelelője (n értéke 1-4000) csak változó hosszúságú. A Varcharnak és az NVarcharnak is adhatunk max hossz-indikátort. Ez nem a 8000 byte-os mérethatárt jelenti hanem azt jelzi, hogy nagy objektumot tárol a rekord. A mérethatár ekkor 2^31 byte (~2GB) illetve NVarchar esetében a 2 byte-os karakterek miatt 2^30 byte.  Numeric(p,s): rögzített pontosságú és skálájú számok. A p értéke meghatározza, hogy hány számjegyből áll a szám, az s pedig azt, hogy ebből mennyi a tizedesjegy. A p maximális értéke 38. Ha nem adunk meg skálát, akkor alapértelmezetten egy lesz. A Numeric mérete a pontosság függvényében 5-17 byte.  Float(n): Lebegőpontos szám n hosszú mantisszával (törtrésszel), a mantissza maximális hossza 53 számjegy és a hosszának függvényében 4 illetve 8 byte-os a típus.  Binary(n), varbinary(n|max): Fix illetve változó hosszúságú – n* 8 bit hosszúságú – bináris adat. A varcharhoz hasonlóan n maximális értéke 8000, azaz 8000 byte. A Varbinary(max) ugyancsak a nagy objektumot jelöli, mint a varcharnál. A nagy bináris objektum maximális mérete szintén 2GB körüli.  Date: A rendszere alapdátuma (1900-01-01) óta eltelt napok száma 3 byte-on tárolva. Alapértelmezett sztringalakja YYYY-MM-DD, de több alak is használható.  Time(p): Az éjfél óta eltelt időt tárolja másodpercben. A pontossága - a p értéke - 0-7-ig változtatható, tehát maximum 100 ns-os felbontást tesz lehetővé. Az alapértelmezett sztringalakja hh:mm:ss.[nnnnnnn], ahol a n-ek száma a pontosság függvénye, de akárcsak a Date esetében a sztringalak itt is változtatható.  Datetime: A dátumot (4 byte) és az időt (4 byte) reprezentáló típus a datetime. A dátumrész 4 byte-ja a napok számát tárolja a rendszer alapidejétől számítva, ami 1900. január 1. Azonban korábbi dátumok is eltárolhatók 1753-tól kezdve. Az időrész 4 byte-ja az éjféltől eltelt 1/300-ad másodperceket számolja, azaz a pontossága 3,3 ezredmásodperc.  Smalldatetime: Felépítése hasonló: mind a dátum- mind az időrész hossza 2 byte ez már nem képes 1900 január elseje előtti dátumokat tárolni és a pontossága is csak 1 perc körüli.  Datetime2(p): A datetime rugalmasabb alakja. Ebben már bármilyen időszámításunk utáni 7

dátum eltárolható i.u.: 10000-ig. Pontossága a Time típuséval megegyezően szabályozható és ennek megfelelően a mérete is változik 6-8 byte között.  Datetimeoffset: A Datetimeoffset típusban tárolt dátum és idő időzóna-érzékeny (tehát nem az adatbázisszerver helyi idejét jelzi).  Uniqueidentifier: 32 karakteres, 16 byte-os egyedi azonosító. A Uniqueidentifier típusú rekordok értéke automatikusan generálódik vagy megfelelő formájú sztringből konvertálható nem javasolt. Redundáns típusok:  Text, NText, Image, Decimal, Real: megfelelnek rendre a Varchar(max)-nak, az NVarchar(max)-nak, a Varbinary(max)-nak, a Numeric-nek illetve a Float(24)-nek. A Decimal kivételével visszafele-kompatibilitási okokból szerepelnek az SQL Server 2008ban és használatuk nem javasolt. További információk: http://msdn.microsoft.com/en-us/library/ms187752.aspx

4.3 Indexelés Fürtözött index automatikusan felépül az elsődleges kulcs oszlopára. Azonban az indexek épülhetnek más, egyediség kényszerrel ellátott vagy akár azt nélkülöző oszlopokra is. Épülhetnek több oszlopra is, ekkor összetett indexről beszélünk. Ha egyáltalán nincs fürtözött index egy táblán akkor azt heapnek nevezzük (rendezetlen kupac). Egy nem-fürtözötten indexelt oszlopon való keresés két fabejárást idéz elő. Először megkeressük a nem-fürtözött indexstruktúrában a levelet, amely egy mutató a fürtözött indexekre, tehát másodjára abban keresünk. A helyzet bonyolódik ha az így indexelt oszlopra nincs megkövetelve az egyediség: ekkor a nem-fürtözött indexfát ugyan elég egyszer bejárni, de a fürtözött indexfát már többször - a keresett érték kardinalitásától függően - és minden egyes fabejárás után biztos újra be kell olvasni egy adatblokkot. Ha fürtözött, nem-egyedi indexstruktúrában keresünk többszörösen előforduló értékeket nincs szükség a fa többszöri bejárásra és az adat többszöri beolvasására – ez akkor egyetlen bejárás és néhány vagy akár egyetlenegy I/O művelet – mivel tudunk következtetni, hogy hol a következő rekord. Ha indexhalmazon keresnénk (tólig keresések), akkor ez fürtözött indexek esetén ugyancsak egyetlen fabejárást jelent. Nem-fürtözött indexek esetén viszont már rengeteg bejárást jelentene mindkettő indexfában. Ez akkora I/O-költséget jelenthet, aminél a rendszer akár egy lineáris kereséssel is jobban jár. Ha ez a helyzet az SQL Server nem használ indexelést. Az indexek jelenléte általában tehát gyorsítja az adathozzáférést, de nem naprakész statisztikákra épülő rosszul tervezett indexek esetén ez már nem egyértelmű. Az SQL Server támogatja a statisztikák megfelelő frissítését azonban végsősoron a tervezés a legkritikusabb. Ez igen nagy szakértelmet igénylő munka.

4.4 Rendszeradatbázisok (system databases) Az SQL Serveren a felhasználói adatbázisok száma tetszőleges míg minden szerverhez pontosan 4 darab rendszeradatbázis tartozik. Ezek a következők:  master: ezen adatbázisban levő táblák tárolják a szerver-szintű információkat.  model: az új adatbázisok létrehozásakor használatos „sablon-adatbázis”, tartalmazza a felhasználói adatbázisokban levő rendszertáblák alapértelmezett beállításait is.  msdb: a beépülő SQL Server Agent által használt adatbázis jobok és riasztások ütemezésére.  tempdb: a szerveren az összes ideiglenes adat ebben az adatbázisban levő táblákban 8

tárolódik. A tempdb mindig üres a szerver kikapcsolt állapotában. Amikor elindul az SQL Server felépül ez az adatbázis, majd folyamatosan nő a kapcsolat ideje alatt (lekérdezések részeredményei stb.). Az egyes felhasználókhoz tartozó ideiglenes adatok addig élnek, amíg a kapcsolat aktív. Ha senki sincs bejelentkezve a tempdb üres.

2. ábra: Rendszer- és felhasználói adatbázisok egy szervergépen

4.5 Rendszertáblák (system tables) Mind a rendszer-, mind a felhasználói adatbázisban vannak kitüntetett táblák, ún. rendszertáblák, amelyek szerver- illetve adatbázis-szintű információkat tárolnak. A rendszertáblák elérése különösen kritikus biztonsági szempontból, mert ezekben tárolódnak azok a metaadatok, amely alapján az egész adatstruktúra és konfiguráció leírható. Manuális módosításuk nem is lehetséges, azonban a megfelelő szerveroldalon tárolt eljárásokkal konfigurálhatóak. A rendszertáblák közvetlen lekérdezése sem ajánlott és biztonsági szempontból is megkérdőjelezhető ezeknek az engedélyezése. Ehelyett a metaadatok kinyerésére a következő főbb módszerek állnak rendelkezésre:  Gyári tárolt eljárások és függvények: előre megírt tárolt eljárások, amelyek a rendszer metaadatait módosítják vagy szolgáltatják vissza, de a részleteket elrejtik a felhasználók elől Nem igazán rugalmas megoldás.. A tárolt eljárások az azt indító felhasználó nevében futnak és ennek megfelelően biztonsági akadályokba ütközhetnek.  Információs séma (Information schema views): a rendszertáblákból összeszerkesztett nézetek, amelyek megfelelnek az ISO információs séma szabványnak. Ezen nézetek leírása minden adatbázisban megtalálható az INFORMATION_SCHEMA nevű sémában. Ez metaadatokat szolgáltat az aktuális adatbázisról.  Rendszerkatalógus (system catalog): a rendszertáblákból összeszerkesztett nézetek. Az összes adatbázissal kapcsolatos metaadatot lefedik. Hatékonyabb módszer a metaadatok kinyerésére. A nézetek elfedik a belső implementációt és kategorizálják az adatokat, amely alapján átlagos ismeretekkel rendelkező felhasználók is elboldogulhatnak a metaadatokkal. Amennyiben egy felhasználónak valamit nem lenne joga megtekinteni a nézet lekérdezése nem adja vissza a megfelelő sort. Az SQL Server régebbi változataiban a rendszertáblák közvetlenül elérhetőek voltak és így számított, hogy rendszer- vagy felhasználói adatbázisból próbálunk a metaadatokhoz hozzáférni. A rendszerkatalógus viszont minden adatbázisból elérhető és minden adatbázisból majdnem ugyanazt 9

a funkcionalitást biztosítja - néhány nézet az msdb, tempdb rendszeradatbázisokból érhető el kizárólag. Ami nagyban különbözhet, azok az adatbázis-szintű rendszeradatok (triviális) és a felhasználók jogosultságai: ha valakinek valami megtekintésére nincs jogosultsága, a megfelelő adatrekord nem jelenik meg hiába a megfelelő nézetet kéri le. Ez egy fontos előrelépés – a táblák lekérdezésénél sorszintű biztonsági előírások definiálása igen körülményes. Azonban a nézetet leíró adatstruktúra (valójában egy lekérdezés) pont megfelel erre a célra.

5. Fizikai modell 5.1 Adatfájlok (data files) Az egyes adatbázisok adatfájlokban tárolódnak. Háromféle adatfájl létezik:  Elsődleges (primary): az adatbázist leíró fő fájl .mdf kiterjesztéssel, minden adatbázis pontosan egy elsődleges adatfájllal rendelkezik.  Másodlagos (secondary): bármilyen információ, amely nem kapcsolódik szorosan az elsődleges fájlhoz kerülhet a másodlagos, .ndf kiterjesztésű fájlba. A másodlagos adatfájl megléte nem kötelező, másodlagos fájlból több is lehet.  Tranzakciós napló (log): A log-információk tárolása történik ebben a .ldf kiterjesztésű fájlban. A napló tárolása tehát független az adatoktól, ide kerül az összes tranzakció összes művelete a megfelelő naplózás kritikus fontosságú az adatbázis működése szempontjából. Megkülönböztetjük az adatbázis logikai és fizikai nevét. A fizikai név (os_file_name) a fájlrendszeren tárolt adatfájl neve, míg a logikai név az SQL Serveren belül az adott adatbázisra való hivatkozás. A leképezés a kettő között a sysdatabases – a már említett master adatbázisban tárolt tábla - segítségével történik. Az adatfájlok NTFS illetve FAT fájlrendszereken tárolhatóak. A méretük automatikusan nő, de adható felső korlát is.

5.2 Lapok és Extentek (pages & extents) Az adatfájlok lapokat tárolnak. Egy adatfájlhoz rendelt lemezterület egyenként 8kB méretű lapokra van osztva. Az összes I/O-művelet lapszinten hajtódik végre – az SQL Server teljes lapokat olvas be vagy ír. Nyolc (a fájlban egymást követő) lap alkot egy extentet, így egy extent mérete 64 kB. Az extent egy számítógép fájlrendszerében egy fájl számára előre lefoglalt folytonosan elhelyezkedő lemezterület. Míg a lapok a fő műveleti egységek az extentek az elsődleges allokációs egységek. Egy tábla adatrekordjai (sorai) a lapokon vannak eltárolva. A lapoknak különböző típusa lehet, amely a lap fejrészében van leírva, Néhány laptípus:  Text/Image: a lapon tárolt rekordokban nagy méretű strukturálatlan objektum van (pl. text, image, varchar(max), nvarchar(max) típusú mezők). Szintén ilyen típusú lapon tárolódnak a változó hosszúságú mezőket tartalmazó sorok, amennyiben a sor összmérete meghaladja a lapméretet (varchar, nvarchar, varbinary típusú mezők). Amennyiben egy módosítás után változik a sor mérete és túllépi ezt a határt, az SQL Server automatikusan széttördeli a legnagyobb méretű oszlop alapján a rekordot.  Data: ez tárolja az összes többi – nem speciális – adatrekordot.  Index: indexrekordokat tároló lap.  Page Free Space: információ a tárolt lapokról és a szabad helyről a lapokon. 10

 Global Allocation Map: információ az allokált extentekről. Az extentek sem egyenrangúak. Megkülönböztethetjük az egyedi (uniform) és a vegyes (mixed) extenteket. Az egyedi extentekben csak egyetlen objektum adatai vannak, a vegyesben többnek. Amikor egy tábla vagy index létrejön vegyes extentbe kerül. Ahogy nő a mérete és túllépi a 64kBos limitet az SQL Server saját, egyedi extentet allokál a számára. Egyébként egy extentben több tábla és több indexstruktúra is lehet, amennyiben az adatrekordok elférnek.

5.3 Fájlcsoportok (filegroups) A fájlok és egyéb objektumok fájlcsoportokba szervezhetők a könnyebb adminisztráció érdekében. Alapesetben minden adatfájl (és így minden adatbázis) az elsődleges fájlcsoportban tárolódik. Az új adatbázisokat, táblákat, az indexeket és a nagyméretű strukturálatlan adatblokkokat létrehozásukkor azonban hozzárendelhetjük más fájlcsoportokhoz is (adatbázisokat nem ajánlott). A fájlcsoportnak rendelkeznie kell legalább egy másodlagos adatfájllal (új adatbázis esetén elsődlegessel), amiben tárolhatók a létrejövő objektumok lapjai. Az adatbázist leíró információ (elsődleges adatfájl) és a benne tárolt táblák tehát nemcsakhogy külön fájlban, de külön fájlcsoportban is lehetnek.

3. ábra: Az SQL Server fizikai tárolási hierarchiája

5.4 Partíciók (partitions) Az adatbázistáblák illetve indexstrukturák partícionálása lehetővé teszi, hogy az egyes partíciókat is szétoszthassuk a fájlcsoportok között, de logikailag ugyanahhoz az adatbázishoz kell tartozniuk. A különböző fájlcsoportokhoz való tartozás tehát azt is jelenti, hogy külön fájlokba is kerülnek a partícionált adatok. A teljes tábla összeállítása több fájlban található partíciókból ugyan overheadet jelent, de a teljes táblára sokszor egyáltalán nincs szükség viszont a vízszintes felbontása egy sok szempontból kényelmes rekord-csoportosítás. Végeredményben akárcsak az indexek tervezése a megfelelő mértékű partícionálás is egy nagy körültekintést igénylő tervezési folyamat.

5.5 Filestream Egzotikus tárolási lehetőség az SQL Server Filestream szolgáltatása, aminek a támogatását szerverszinten lehet engedélyezni/tiltani. Ez a nagy, struktúrálatlan adatok (text, image) közvetlen tárolását teszi lehetővé a szerverszámítógép fájlrendszerében. Azonban ezen adatok számára létre kell hozni egy referenciát, aminek segítségével megtalálhatóak a bizonyos fájlrendszerben, ezeket tárolják ekkor a táblák. A fájlrendszerben való tárolás hátránya az adatok lassú elérése (újabb hierarchiaszint), az SQL Server speciális buffer-kezelést használ az overhead minimalizálása végett.

11

6. Tranzakciókezelés A tranzakciókezelés az adatbáziskezelőkben elsősorban az ACID-elveket (atomicitás, konzisztencia, integritás, tartósság) hivatott megvalósítani.

6.1 Atomicitás Az atomicitás megköveteli, hogy egy tranzakció vagy teljesen hajtódjon végre vagy sehogyan sem. Amennyiben több műveletet végez egy T1 tranzakció és ebből néhány sikertelen törölni kell a T1 tranzakció összes hatását, ez a rollback.

6.2 Konzisztencia Az adatbázis-konzisztencia fenntartása elsősorban az adatok integritásának (helyességének) megőrzését jelenti. Az adatok helyességének definiálása modellezési/tervezési kérdés és mint ilyen elsősorban az adatbázis logikai modelljéhez kapcsolódik (bővebben 4.1 Kényszerek). Ezen konzisztencia-szabályok definiálása a kényszerek segítségével történik meg. A tranzakciók amelyek megsértenék a konzisztencia-szabályokat megszakításra kerülnek.

6.3 Izoláció Az egyidejűleg futó tranzakciók különböző anomáliákat / inkonzisztenciákat okozhatnak (hamis eredmények), amelyek visszavezethetők a köztük levő izoláció hiányára:  Elveszett módosítás (lost update): ha egy T1 tranzakció módosít egy adategységet és később újra beolvassa a saját módosítását nem biztos, hogy látja, mert időközben egy T2 tranzakció felülírhatja a módosítást mivel nincsenek írási zárak.  Piszkos olvasás (dirty read): ha egy T1 tranzakció ír egy adategységet és még a futása közben egy T2 olvassa ugyanezt az adategységet piszkos olvasást követ el, mert a T1 tranzakció akár meg is szakadhat a jövőben. Ha ez történik akkor egy inkonzisztens állapotban olvasott a T2 és ezért hamis eredményekre juthatott.  Nem-megismételhető olvasás (non-repeatable read): ha egy T1 tranzakció futása során kétszer olvassa ugyanazt az adategységet a rekordok tartalma különböző lehet, mert egy T2 közben módosíthatja az adategységet mivel nincsenek olvasási zárak.  Fantom rekordok: Olyan rekord, amelyek egy T1 tranzakció valamely adategységen végrehajtott két olvasása között beszúrásra vagy törlésre kerülnek egy T2 tranzakció által. Ez akkor lehetséges ha a zárak rekordokra vonatkoznak és nem táblaszintűek. A konkurrencia kezelése az SQL Serverben zárakkal valósul meg. Többféle zár létezik: megosztható (shared) ~ readlock, nem-megosztható (exclusive) ~ writelock, módosító (update) stb. A zárak vonatkozhatnak sorokra vagy táblákra is. Az előbbi nagyobb konkurrenciát tesz lehetővé a tranzakciók között, az utóbbinek kisebb az overheadje a kevés kezelendő zár miatt. Az SQL Server többféle tranzakció izolációs szintet támogat. Szinttől függetlenül amikor egy tranzakció ír egy adategységet, az adategységre nem-megosztható zár kerül, ami csak a tranzakció kommitjával szabadul fel ennek következtében elveszett módosítás egyik szinten sem fordulhat elő. A tranzakció izolációs szintek:  Read Uncommitted: A tranzakciók olyan adategységet is olvashatnak, amelyen nemmegosztható zár van. Ez potenciális inkonzisztenciákhoz vezethet (mindhárom anomália), de a tranzakciók konkurrenciája ezen a szinten a legnagyobb.  Read Committed: A nem-megosztható zár csak az író tranzakció kommitjával szabadul fel és blokkolja az adategység olvasását, így az csak már kommittált tranzakciótól származó adaton engedélyezett. Emiatt piszkos olvasás nem történhet. Az SQL Server 12

alapértelmezetten ebben a módban működik..  Repeatable read: Amikor egy tranzakció olvas egy adategységet az olvasott rekordokra megosztható zár kerül. A zár miatt amíg az olvasó tranzakció nem kommittál ezen rekordokat módosítani vagy törölni már nem lehet. Emiatt ezen az izolációs szinten már nincs nem-megismételhető olvasás és rekordok sem tűnhetnek el a két olvasás között, azonban továbbra is beszúrhatók mivel a zárak sorszintűek.  Serializable: A tranzakciók egymástól teljesen függetlenül hajtódnak végre, mintha egymás után futnának le. Párhuzamosan csak akkor futhatnak ha fenntartható a soros végrehajtás illúziója – nincsenek hatással egymásra. Ezen a szinten már fantom rekordok se fordulhatnak elő. Erős zárhasználat és emiatt tranzakcióvárakoztatás illetve holtpontok jellemzik. A holtpont elkerülhető ha a tranzakciók együttműködnek és azonos sorrendben foglalnak le erőforrásokat, de ez jelentős overheadet jelenthet mivel a kliensek együttműködése többnyire nem tételezhető fel és az adatbáziskezelőnek kell a holtpontelkerülésről gondoskodnia. Mivel nagy mértékben blokkolja a konkurrenciát ezért sok esetben nem praktikus ezen izolációs szint használata.  Snapshot: Ez az izolációs szint többverziós konkurrenciakezelést használ. Az egyes tranzakciók futásuk során az adategység azon verzióját fogják olvasni illetve írni, amelyik akkor létezett, amikor először hozzáfértek az adategységhez ennek következtében nincsen sorszintű zárakra szükség. Egyik anomália sem fordul elő.

7. Biztonság A felhasználókezelés legfőbb egységei a hozzáférő (principal) és az erőforrás (securable). Hozzáférőnek minősül mindazon entitás, amihez az erőforrásokat hozzá lehet rendelni. Erőforrásnak minősül minden objektum az adatbázisban, amit az SQL Server egy hozzáférőhöz hozzá tud rendelni. Az adatbázis is erőforrásnak minősül. Az SQL Server hozzáférői két csoportba oszthatók. Egyik csoport a szerver-szintű hozzáférők: szerver-szerepek (pl. jogosultság rendelhető hozzá) és loginok (pl. szerver-szerep rendelhető hozzá). Léteznek adatbázis-szintű hozzáférők ezek közé tartoznak a felhasználók és az adatbázis szerepek.

7.1 Login és Felhasználó A login egy azonosító, aminek segítségével egy kliens bejelentkezhet a szerverre. A kliensek azonban mindig egy adatbázishoz kapcsolódnak. Ennek eszköze a felhasználó (user). Míg a loginhoz megadható az alapértelmezett adatbázis, amihez végülis hozzá fog férni a kliens, a felhasználó összerendelhető egy loginnal. Tehát a felhasználó hozzáférő és erőforrás egyben. Amennyiben a kliens olyan adatbázisba jelentkezne be, amelyben nincs a loginjához rendelt felhasználó a vendég felhasználó fiókját fogja használni.

7.2 Jogosultságok Az engedélyezés feladata a jogosultságok kiosztása, annak eldöntése, hogy egy hozzáférő – felhasználó – milyen erőforráshoz férhet hozzá és azon milyen műveletet hajthat végre. A különböző jogosultságokból rengeteg van, fáradtságos lenne minden egyes felhasználó számára egyedileg hozzárendelni a jogosultságokat. A megoldás erre: szerepek Miután kiválasztjuk a hozzáférőt és az erőforrást az objektumoktól függően rengeteg jogosultság engedélyezhető (grant), letiltható (deny) vagy engedélyezhető továbbadással (with grant). Amennyiben egyik sincs beállítva az objektum vagy művelet elérhetetlen lesz alapértelmezetten a hozzáférő számára. A letiltás értelme, hogy egy felhasználó több jogosultsága vonatkozhat ugyanarra az objektumra és ezek felülbírálhatók a letiltással. A továbbadásos engedélyezés beállításával a jogot megkapó hozzáférő saját maga is továbbadhatja a jogokat. 13

A jogosultság-eldöntő algoritmus ha valamelyik vonatkozó jogosultságon letiltást talál, akkor felülír bármilyen engedélyezést. Ha nem talál letiltást, de talál engedélyezést, akkor a művelet végrehajtható. Az algoritmus működése ennél azért valamivel összetetteb: befolyásolhatják a jogosultság-adó szerepei is illetve az objektumok hierarchiája az adatbázisban (pl. ha valaki letiltást kap az adatbázis szerkesztésére, akkor hiába engedélyeztük az adott sémákra - a letiltás tehát átszivárog a hierarchia felsőbb rétegeiből).

7.3 Szerepek A szerep egy olyan engedélyezési csoport, amelyhez hozzárendelhetők felhasználók és jogosultságok. Ezután ha szerephez kötjük a jogosultságot az engedély/tiltás az összes felhasználóra érvényes lesz, akikhez hozzá van rendelve a szerep. Megkülönböztetjük az szerver- és adatbázisszintű a szerepeket (a táblázatban szürkével) az utóbbiakból újak is definiálhatók. Az SQL Server számos gyárilag beépített szerepet biztosít számunkra, ezekből néhány: sysadmin

A szerep tagjai a szerveren bármilyen tevékenységet képesek elvégezni.

securityadmin

A tagok az összes szerver-szintű ill. adatbázis-szintű engedélyezési feladatot elláthatják.

dbcreator

Adatbázisok készítése, módosítása vagy eldobása.

public

Az alapértelmezett szerver-szintű szerep.

db_owner

Az adatbázis korlátlan urai, az adatbázis eldobását csak ők kezdeményezhetik.

db_securityadmin

Az adatbázis-szerep tagságok szabályozása és a jogosultságok kiosztása.

db_datawriter

Az adatbázis összes tábláján képesek beszúrni, módosítani vagy törölni adatokat.

db_denydatawriter

Az adatbázis a szerep tagjai számára read-only. Semmilyen változtatásra nem képesek.

Léteznek alkalmazás szerepek is. Ezek elsősorban akkor hasznosak ha a kliens gépen futó alkalmazás lép kapcsolatba az adatbázissal és saját felhasználó-szerű engedélyezés lenne szükséges.

7.4 Sémák (Schemas) Az SQL Server sémái az adatbázison belül elhelyezkedő névterek, amelyek objektumok csoportjait tárolják (pl. táblákat, nézeteket). Minden objektum az adatbázisban sémákba van rendezve. A sémák hozzá lehetnek rendelve egy felhasználóhoz vagy adatbázis-szerephez, korlátozva ezzel az általuk elérhető objektumokat az adatbázison belül. A saját sémában levő objektumokra nem kell előtaggal együtt hivatkozni. Ha egy felhasználó hozzá akar férni más séma objektumához és van erre jogosultsága ezt megteheti, amennyiben a másik sémában levő objektumra a séma nevével együtt hivatkozik (pl. séma.tábla).

7.5 Szinonimák (Synonyms) A nem saját sémában levő objektumokhoz való hozzáféréshez a teljes nevükkel kell rájuk hivatkozni. Ez feltételezi a másik séma ismeretét is, ami kellemetlen követelmény. A sémagazdák és az erre jogosultak létrehozhatnak szinonimákat a saját sémájukban a külső sémákban levő objektumokra (amennyiben ahhoz hozzáférnek természetesen). A szinonima ezután bárhol használható, ahol a névtérrel kiegészített objektumnévre lenne szükség. A szinonimák tehát alternatív névként funkcionálnak elfedik a külső séma jellegezetességeit és egyben erőforrások is, amelyek engedélyekhez köthetők, így rugalmasabbá tehetők a sémák közötti műveletek.

8. Rendszermenedzsment Az SQL Server Management Studio-t innen tölthetjük le (express változat, de a labor céljaira tökéletes), ez a menedzsment fő eszköze: 14

http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=08e52ac2-1d62-45f6-9a4a4b76a8564a2b&displaylang=en

8.1 Kapcsolódás a szerverhez Az SQL Server Management Studiot elindítva az első ablak, amivel találkozunk. A szervernév mezőben ki kell választanunk a megfelelő szervert (ez alapesetben a helyi gépen illetve a helyi hálózaton elérhető adatbázisszervereket jelenti). Az interneten átívelő adatbázis-kapcsolatokhoz szükséges az adatbázisszervernek egy connectionstringet biztosítania, amely tartalmazza titkosítva az autentikációs információkat, a szerver domainjét, hálózati protokollt és esetleg a szerverpéldány nevét is. A kapcsolódási opcióknál ezt a connectionstringet meg lehet adni. Kényelmesebb a kapcsolat felépítése alias-ok alkalmazásával. Az aliasokat a bármilyen SQL Server termékkel együtt feltelepülő SQL Server Configuration Manager-ben lehetséges definiálni. Egy alias igazából a szerver URL-jét helyettesítheti, így a kapcsolódáskor elegendő ezt megadnunk. A bejelentkezési információk megadása minden esetben szükséges.

8.2 Object Explorer Ebben a fában csoportosítva szerepelnek a szerveren tárolt objektumok. Az mappákra/objektumokra jobb gombbal kattintva egy helyi menüt hozhatunk elő, amelyekből – bár változatos tartalmúak – többnyire el lehet navigálni az adott objektum tulajdonságaihoz, esetleg lehet módosítani vagy bizonyos csoportosító mappáknál (pl. tables, logins) így lehet új objektumot hozzáadni. A Databases csomóponton belül láthatjuk a rendszer- és felhasználói adatbázisokat. Az egyes adatbázisokon belül további számos csomópontot láthatunk, amelyek közül a fontosabbak:  Database Diagrams – tábla- és kapcsolatszerkesztő diagram.  Tables: itt vannak felsorolva a felhasználó sémájában levő táblák illetve az adatbázis rendszertáblái. A helyi menüjéből lekérdezhetjük a táblát (select), adhatunk hozzá rekordokat (edit) illetve változtathatjuk a sémáját (design).  Views: itt vannak felsorolva a felhasználó sémájában levő nézetek illetve a rendszerkatalógus.  Synonyms: a felhasználó által elérhető szinonimák.  Security: ezen belül tekinthetőek és változtathatóak meg az adatbázis felhasználói, szerepei, sémái stb. A Security csomóponton belül a szerver-szintű biztonsággal kapcsolatos objektumok szerepelnek (pl. loginok, szerver-szerepek) illetve ezeket lehet menedzselni. A Management csomópont sokféle objektum gyűjtőhelye (erőforrás tervező – resource governor, log megtekintése, házirendek megtekintése stb.). Az SQL Server Agent az SQL Serverbe beépülő ágens, amellyel a különböző szervert érintő munkafolyamatok (jobok) automatizálhatók.

8.3 Egyéb panelek Az ablak közepén a konzol helyezkedik el, ahova a Transact-SQL utasításokat lehet írni. A lekérdezések eredményei a konzol alatt egy táblázatban láthatóak. A fejlécen elhelyezkedő gombsor is számos lehetőséget ad: Új konzoltabot a 'new query', 'database engine query' gombokkal kezdeményezhetünk. Ha több adatbázis is elérhető vigyázni kell, hogy melyik adatbázist kérdezzük le. A lekérdezés végrehajtását az execute-al kezdeményezhetjük. A lekérdezést a query options alatt specializálhatjuk. A gombsoron elérhető az előzetes lekérdezési terv is. A jobboldali panel a Properties nevet viseli. Mikor felépítjük az adatbázist és különböző 15

objektumokat hozunk létre ez azokról hordoz információt és itt szerkeszthetjük is azokat. Így nem kell külön ablakban szerkeszteni a tulajdonságokat.

9. Rendszernézetek referencia Eme referencia semmiképp nem tekinthető hivatalosnak vagy teljeskörűnek. A nézetek témák szerint vannak csoportosítva, a csoportosítás nagyrészt megfelel a Microsoft hivatalos dokumentációjában levőnek. A gyakorlatban viszont nincsenek csoportosítva az egyes rendszernézetek. A teljes rendszernézet referencia: http://msdn.microsoft.com/en-us/library/ms177862.aspx Adatbázis-szintű objektumkatalógus (object catalog):  sys.check_constraints: az adatbázisban érvényes érték-jellegű kényszerek.  sys.columns: azadatbázisban található oszlopok (a rendszertáblák oszlopai nincsenek listázva).  sys.events: azon események, amelyek értesítést vagy triggert indítanak el.  sys.foreign_keys: az adatbázisban levő oszlopok, amelyeken külső kulcs kényszer van definiálva.  sys.foreign_key_columns: az adatbázisban levő azon oszlopok, amelyek külső kulcsok.  sys.identity_columns: az adatbázisban lévő egyediség kényszerrel ellátott oszlopok.  sys.indexes: az adatbázisban levő indexstruktúrák.  sys.index_columns: az adatbázisban levő indexelt oszlopok listája.  sys.key_constraints: az adatbázisban érvényes elsődleges-kulcs kényszerek.  sys.objects: az adatbázisban levő összes objektum (táblák, indexek, kényszerek stb.)  sys.partitions: az adatbázishoz tartozó tábla- illetve indexpartíciók.  sys.procedures: az adatbázishoz tartozó tárolt eljárások.  sys.schemas: az adatbázisban létrehozott sémák.  sys.synonyms: az adatbázisban tárolt szinonimák.  sys.tables: az adatbázisban tárolt táblák (a rendszertáblák nincsenek listázva)  sys.triggers: a tábla- illetve adatbázis-szintű triggerek.  sys.types: a szerveren érvényes típusok  sys.views: az adatbázisban tárolt nézetek Adatbázisok és adatfájlok katalógus (database and files catalog):  sys.databases: a szerveren található adatbázisok.  sys.database_files: az adatbázishoz tartozó fájlok  sys.filegroups: az adatbázishoz tartozó fájlcsoportok  sys.master_files: a szerveren található összes adatbázishoz tartozó fájlok Biztonság és engedélyezés:  sys.database_permissions: az összes adatbázis-szintű engedély.  sys.database_principals: az adatbázis-szintű hozzáférők (user, role).  sys.server_permissions: az összes szerver-szintű engedély.  sys.server_principals: a szerver-szintű hozzáférők (login, role).  sys.sql_logins: a szerveren érvényes loginok Dinamikus menedzsment  sys.dm_db_index_usage_stats: szerver-szintű indexhasználat. 16

        

sys.dm_exec_cached_plans: a szerver által cache-elt végrehajtási tervek. sys.dm_exec_query_stats: a cache-elt végrehajtási tervek teljesítmény-statisztikái. sys.dm_exec_connections: a szerver által létesített kapcsolatok. sys.dm_exec_requests: a szerveren végrehajtás alatt levő kérések. sys.dm_exec_sessions: a szerveren futó sessionök. sys.dm_tran_active_transactions: a szerveren futó tranzakciók. sys.dm_tran_current_transaction: információk a nézetet lekérdező tranzakcióról (1 soros). sys.dm_tran_database_transactions: az aktuális adatbázisban futó tranzakciók. sys.dm_tran_locks: a szerver zárkezelőjéhez beérkezett zárkérések és a már lefoglalt zárak

Egyéb:  sys.messages: a szerver lehetséges hibaüzenetei.  sys.server_events: azon szerver-szintű események, amelyek értesítést vagy triggert aktiválnak.  sys.server_event_sessions: a külön sessionben futó eseménykezelő eljárások.  sys.servers: a helyi szerver illetve azon távoli szerverek tulajdonságai, amivel a helyi szerver összeköttetésben van

17