11-15. előadás Barabás Péter SQL Server 11-15. előadás Barabás Péter

Témakörök Függvények Tárolt eljárások Triggerek Létrehozása Determinisztikus és nem determinisztikus függvények Tárolt eljárások Újrafordítása Jogok és szerepkörök Triggerek DDL triggerek Rekurzív triggerek Egymásba ágyazott triggerek

Függvények implementálása Skalár függvények Input paraméterek: 0 v. több Visszatérési érték: egyszerű skaláris érték Megszorítások: nem változtathatják meg az objektumok állapotát CREATE FUNCTION [ schema_name. ] function_name ( [ { @parameter_name [ AS ][ type_schema_name. ] parameter_data_type      [ = default ] }      [ ,...n ]   ] ) RETURNS return_data_type      [ WITH <function_option> [ ,...n ] ]      [ AS ]      BEGIN                  function_body          RETURN scalar_expression      END [ ; ]

Függvények implementálása II. Tábla értékű függvények Hasonló a skaláris függvényekhez Különbség: visszatérési értéke tábla Használata: SELECT utasítás FROM részében CREATE FUNCTION [ schema_name. ] function_name ( [ { @parameter_name [ AS ] [ type_schema_name. ] parameter_data_type      [ = default ] }      [ ,...n ]   ] ) RETURNS @return_variable TABLE < table_type_definition >      [ WITH <function_option> [ ,...n ] ]      [ AS ]      BEGIN                  function_body          RETURN      END [ ; ]

Determinisztikus és nem determinisztikus függvények Ugyanazon bemenő paraméterekre mindig ugyanazt a visszatérési értéket szolgáltatja Pl. sin(), cos(), … Az eredmény indexelhető Nem determinisztikus függvények Hívásonként más visszatérési értéket szolgáltat Pl. : GETDATE() Hívhat nem determinisztikus függvényt vagy tárolt eljárást Az eredmény nem indexelhető

Tárolt eljárások Bármilyen SQL Server által futtatható parancsot tartalmazhat Biztonsági funkció: Futtatási jog a tárolt eljárásra Az adatokra, amin dolgozik nem kell jogot adni Elrejti az adatbázis szerkezeti megvalósítását a user elől

Tárolt eljárások II. CREATE { PROC | PROCEDURE } [schema_name.] procedure_name [ ; number ] [ { @parameter [ type_schema_name. ] data_type } [ OUT | OUTPUT ] ] [ ,...n ] [ WITH <procedure_option> [ ,...n ] ] [ FOR REPLICATION ] AS { <sql_statement> [;][ ...n ] | <method_specifier> } [;] <procedure_option> ::= [ ENCRYPTION ] [ RECOMPILE ] [ EXECUTE_AS_Clause ] <sql_statement> ::= { [ BEGIN ] statements [ END ] } <method_specifier> ::= EXTERNAL NAME assembly_name.class_name.method_name

Tárolt eljárások III. Jellemzők: Egyedi nevük van Tetszőleges számú input paraméterekkel rendelkezik Kimeneti paraméterek definiálására is lehetőség van ENCRYPTION: az eljárás titkosítva tárolódik RECOMPILE: minden futtatáskor újrafordítódik A törzs nem tartalmazhatja a következőket: SET SHOWPLAN_TEXT SET SHOWPLAN_ALL USE <database>

Tárolt eljárások IV. Használathoz futtatási jog szükséges GRANT EXECUTE ON <stored procedure> TO <database principle> A futtatási joggal automatikusan elérhetővé válnak a tartalmazott objektumok és parancsok DE! Direktben nem érhetők el, csak az eljáráson keresztül

Triggerek Típusai: DML triggerek DDL triggerek Rekurzív triggerek AFTER INSTEAD OF DDL triggerek Rekurzív triggerek Nested triggerek

DML triggerek Egy adott táblához tartozik Esemény bekövetkezésének hatására fut le, nem lehet direkt meghívni Események: INSERT, UPDATE, DELETE Módok: AFTER INSTEAD OF Törzsben nem használhatóak: Create, alter, drop, backup, restore

DML triggerek II. Speciális táblák: INSERTED DELETED CREATE TRIGGER [ schema_name . ] trigger_name ON { table | view } [ WITH <dml_trigger_option> [ ,...n ] ] { FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] } [ WITH APPEND ] [ NOT FOR REPLICATION ] AS { sql_statement [ ; ] [ ,...n ] | EXTERNAL NAME <method specifier [ ; ] > } <dml_trigger_option> ::= [ ENCRYPTION ] [ EXECUTE AS Clause ]

Rekurzív és nested triggerek Rekurzív triggerek: Trigger akciója kiválthatja újra önmagát Egy mechanizmus kezeli a végtelenséget RECURSIVE_TRIGGERS opció állításával Nested triggerek: Egy trigger akciója kiváltja egy másik trigger „tüzelését” A másik trigger pedig kiváltja az előző lefutását NESTED_TRIGGERS paraméter állításával szabályozható

DDL triggerek Használata: Szintaktika: CREATE TRIGGER trigger_name Korlátozhatja a DDL utasítások használatát Szintaktika: CREATE TRIGGER trigger_name ON { ALL SERVER | DATABASE } [ WITH <ddl_trigger_option> [ ,...n ] ] { FOR | AFTER } { event_type | event_group } [ ,...n ] AS { sql_statement [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier > [ ; ] } <ddl_trigger_option> ::= [ ENCRYPTION ] [ EXECUTE AS Clause ] <method_specifier> ::= assembly_name.class_name.method_name

Adatbázisok mentése Teljes mentés Különbségi mentés Tranzakció log mentése File csoport mentés Tükrözött mentés Részleges mentés

Teljes mentés Minden adat mentésre kerül, ami az adatbázisban található Használható adatbázis újralétrehozására is A visszaállítási modelltől függetlenül mindig alkalmazható. A lehető leggyorsabban történik az elvégzése minimális erőforrás használat mellett. A backup engine lapokat ír backup device-re, a sorrend figyelembe vétele nélkül A sorrendi függetlenség miatt ezt a műveletet több szál közt osztja szét és így a gyorsaság csak az eszköz sebességgétől függ.

Teljes mentés II. Logikai inkonzisztencia léphet fel Userek bejelentkezett állapota és aktivitása miatt SQL Server a következőképpen küszöböli ezt ki lockolja azt adatbázist és blockolja az összes tranzakciót Tesz egy jelölést a tranzakció logba Felengedi az adatbázis lockolást Menti az összes lapot A két log jelölés közötti tranzakciókat hozzáfűzi a backup-hoz

Teljes mentés III. Parancs: TO rész: WITH rész: BACKUP DATABASE <database_name> TO DISK=‘<directory>\<filename>’ WITH INIT TO rész: A backup device-t lehet megadni DISK,TAPE: explicit útvonalat lehet kijelölni WITH rész: Több, mint egy tucat paramétere lehet INIT: mindent írjon felül a backup eszközön

Különbségi mentés Az utolsó teljes mentés óta változott extenteket menti. Előnye: a tranzakciós log mentések számát csökkenti. Csak teljes mentés után használható Visszaállítási modelltől függetlenül haszálható.

Különbségi mentés II. Nem inkrementális backup Inkrementális backup: az utolsó inkrementális backup óta eltelt változásokat menti Az utolsó TELJES MENTÉS óta eltelt változásokat menti. Pl. teljes mentés éjfélkor történt 4 óránként van különbségi mentés Minden mentés az éjfél óta eltelt változásokat tartalmazza

Különbségi mentés III. Extent map Egy másik adatlap az adatbázisban Minden bit az oldalon egy extent-et reprezentál Amikor az extent változik, az extent bitje 0-ról 1-re változik Teljes mentésnél minden bit 0-ra állítódik. Mivel az adatbázisok mérete korláltlan és az adatlapok mérete 8KB lehet, 8192 extentenként jön létre mapping oldal

Különbségi mentés IV. Parancs: BACKUP DATABASE <database_name> TO DISK=‘<directory>\<filename>’ WITH DIFFERENTIAL

Tranzakció log mentés Teljes vagy bulk-logged recovery model esetén használható Teljes mentés után használható Adatok egy részhalmazát tartalmazza és szükséges egy teljes mentés a visszaállításhoz Az aktív logot menti Az előző log backup utáni Log Sequence Number-rel (LSN) kezdi. Mindaddig menti a tranzakciókat, amíg egy nyitott tranzakciót el nem ér A mentett tranzakciók a logból eltávolíthatók

Tranzakció log mentés II. Parancs: BACKUP LOG <database_name> TO DISK=‘<directory>\<filename>’ WITH INIT

Filecsoport mentés Alternatív mentési stratégia a teljes mentéshez Az adatbázis mentése helyett az egyes filecsoportokat menti az adatbázisból Kiindulásként szükséges egy mentés az össze filecsoportról Teljes vagy Bulk-logged recovery modell szükséges

Filecsoport mentés II. Parancs: BACKUP DATABASE <database_name> FILEGROUP = ‘<filegroup_name>’ TO DISK=‘<directory>\<filename>’ BACKUP DATABASE <database_name> FILEGROUP = ‘<filegroup_name>’ TO DISK=‘<directory>\<filename>’ WITH DIFFERENTIAL

Tükrözött mentés Minden backup létrehoz egy egyszeri másolatot az adatokról egy eszközön. Az adminisztrátor duplikálhatja ezt az esetleges eszközhibák miatt. A duplikáció fárasztó és időigényes folyamat. Létrehozható másolat a mentésről az SQL Serverben: tükrözött mentés

Tükrözött mentés II. BACKUP parancs opcionális része: [[MIRROR TO <backup_device> [,…n]][…next-mirror]] 4 másolat létrehozása lehetséges, ebből 3 a MIRROR TO részben definiált Korlátozások: Az eszköznek az összes másolathoz ugyanolyan típusúnak kell lenni. Mindegyiknek hasonló tulajdonságokkal kell rendelkeznie. Pl. ha a backup disk-re történik, a másolatok is disk-re kell kerüljenek

Tükrözött mentés III. Példa: BACKUP DATABASE PUBS TO DISK=‘C:\DEMO\BACKUP\PUBS1A.BAK’, DISK=‘C:\DEMO\BACKUP\PUBS1B.BAK’ MIRROR TO DISK=‘\\BAKSERVER1\BACKUP\PUBSMIRROR1A.BAK’, DISK=‘\\BAKSERVER1\BACKUP\PUBSMIRROR1B.BAK’ MIRROR TO DISK=‘\\BAKSERVER2\BACKUP\PUBSMIRROR2A.BAK’, DISK=‘\\BAKSERVER2\BACKUP\PUBSMIRROR2B.BAK’ MIRROR TO DISK=‘\\BAKSERVER3\BACKUP\PUBSMIRROR3A.BAK’, DISK=‘\\BAKSERVER3\BACKUP\PUBSMIRROR3B.BAK’ WITH FORMAT GO

Részleges mentés Lehetőség van írható és csak olvasható filecsoportok kezelésére Előző verziókban a backup a csak olvasható filecsoportokra is kiterjedt, ami ugyebár nem változhatott Új paraméter: READ_WRITE_FILEGROUPS

Részleges mentés II. Jelentése: Példa: A backup figyelmen kívül hagyja a csak olvasható filecsoportokat Időt és helyet takaríthatunk meg vele Példa: BACKUP DATABASE PUBS READ_WRITE_FILEGROUPS TO DISK=‘C:\DEMO\BACKUP\PUBS1.BAK’

Részleges mentés II. Jelentése: Példa: A backup figyelmen kívül hagyja a csak olvasható filecsoportokat Időt és helyet takaríthatunk meg vele Példa: BACKUP DATABASE PUBS READ_WRITE_FILEGROUPS TO DISK=‘C:\DEMO\BACKUP\PUBS1.BAK’

Gyakorlás 1. Mentsük az adatbázist teljes, különbségi és tranzakció log mentéssel! 2. Készítsünk filecsoport, filcsoport különbségi és tranzakció log mentéseket!

Adabázisok visszaállítása Full backup visszaállítása Differential backup visszaállítása Transaction Log visszaállítása Részleges visszaállítás Korrupt oldal visszaállítás Visszaállítás eszköz hibákkal Visszaállítás validálása Adatbázis mozgatása

Full backup visszaállítás Legtöbb visszaállítás az adatbázis újralétrehozásával kezdődik egy adott időben Aztán a következő backup-ok visszaállítása a cél ideig Ez a folyamat a teljes mentésből történő visszaállítással kezdődik.

Full backup visszaállítás II. A teljes mentés az teljes adatbázist tartalmazza A visszaállítási műveletnek az oldalakat szekvenciális sorrendben kell visszatenni az adatbázisba A folyamat végén egy teljesen koherens adatbázist kapunk.

Full backup visszaállítás III. Példa: RESTORE DATABASE PUBS FROM DISK=‘C:\DEMO\BACKUP\PUBSFULL.BAK’ WITH REPLACE, STANDBY = ‘C:\DEMO\BACKUP\PUBSSTANDBY.STN’ REPLACE opció: Írja felül a már létező ugyanolyan nevű adatbázist STANDBY opció: Az adatbázist visszaállítás állapotban hagyja: Írás nem megengedett De a userek kapcsolódhatnak az adatbázishoz és lekérdezéseket végezhetnek WITH RECOVERY, WITH NORECOVERY opciók

Differential Backup visszaállítás Kiindulópont: Teljes backup visszaállítás szükséges Példák: RESTORE DATABASE PUBS FROM DISK=‘C:\DEMO\BACKUP\PUBSFULL.BAK’WITH NORECOVERY RESTORE DATABASE PUBS FROM DISK=‘C:\DEMO\BACKUP\PUBSFULL.BAK’WITH RECOVERY

Differential Backup visszaállítás II. Filecsoport visszaállítás példa: RESTORE DATABASE AdventureWorks FILEGROUP=‘FG1’ FROM DISK=‘C:\TEST\AWFG1.BAK’ WITH NORECOVERY RESTORE DATABASE AdventureWorks FILEGROUP=‘FG1’ FROM DISK=‘C:\TEST\AWFG1.BAK’ WITH RECOVERY

Transaction Log visszaállítás Az adatbázis előregörgetése egy adott pontig Teljes vagy különbségi backup visszaállítás után lehetséges. A TL Backup tranzakció sorozatot tartalmaz az LSN-nel azonosítva Lehetőség van egy bizonyos LSN-nél leállítani a recovery folyamatot (STOPAT)

Példák Visszaállítási folyamat (full+diff+TR) Full Differential RESTORE DATABASE AdventureWorks FILEGROUP=‘FG1’ FROM DISK=‘C:\TEST\AWFG1.BAK’ WITH NORECOVERY Differential RESTORE DATABASE AdventureWorks FROM DISK=‘C:\TEST\FG1DIFF1.BAK’ WITH NORECOVERY Transaction log RESTORE LOG AdventureWorks FROM DISK=‘C:\TEST\AW2.TRN’ WITH RECOVERY

Példák II. Visszaállítási folyamat (full+multiple TR) Full TR log RESTORE DATABASE AdventureWorks FILEGROUP=‘FG1’ FROM DISK=‘C:\TEST\AWFG1.BAK’ WITH NORECOVERY TR log RESTORE LOG AdventureWorks FROM DISK=‘C:\TEST\AW1.TRN’ WITH NORECOVERY RESTORE LOG AdventureWorks FROM DISK=‘C:\TEST\AW2.TRN’ WITH RECOVERY

Részleges visszaállítás Az adatbázis egy részének visszaállítása Az adatbázis többi része elérhetővé válik a kérések számára Amennyiben a kérésekhez nincs szükség a visszaállítandó részre, a usereknek semmi sem tűnik fel

Korrupt oldal visszaállítása Egy vagy több oldal korrupttá válhat Előző verziókban server hiba okozta és az adtabázis offline módba került Javítás az oldal típusától függő volt: Index oldal vált korrupttá: Droppolás után újragenerálódott Adat oldal vált korrupttá: Visszaállítás backupból, A backup alatt a DB offline

Korrupt oldal visszaállítása II. PAGE_VERIFY CHECKSUM Ezen verifikáció engedélyezése után bármely korrupttá vált oldal loggolódik és karanténba kerül Verifikáció engedéleyezése: ALTER DATABASE <database_name> SET PAGE_VERIFY CHECKSUM Alaphelyzetben ki van kapcsolva Korrupt lapok a suspect_pages táblába loggolódnak az msdb adatbázisban

Korrupt oldal visszaállítása III. A log végének mentése BACKUP LOG PUBS TO DISK=‘C:\HA\DEMO\BACKUP\PUBS1.TRN’ WITH INIT GO Korrupt lap visszaállítása USE MASTER RESTORE DATABASE PUBS PAGE=‘1:88’ FROM DISK=‘C:\HA\DEMO\BACKUP\PUBSMIRROR1.BAK’ WITH RECOVERY Tranzakciók a TR logba RESTORE LOG PUBS FROM DISK=‘C:\HA\DEMO\BACKUP\PUBS1.TRN’ WITH RECOVERY

Visszaállítás eszköz hibákkal a hiba ritkán detektálható a backup előtt Visszaállításnál a létező adatbázis tartalma kisöprődik A visszaállítás abortálódik a hiba miatt Marad egy teljesen érvénytelen adatbázis

Visszaállítás eszköz hibákkal II. A RESTORE utasításnak van egy opciója, melynek hatására a hibás szektorok átugrásra kerülnek és a visszaállítási folyamat ezáltal befejeződhet WITH CONTINUE_AFTER_ERROR Nincs rá garancia, hogy a visszaállítás során az adatbázis használható lesz Hiba esetén az adatbázis emergency módba kerül Kapcsolódhatunk az adatbázishoz Select utasításokat kiadhatunk Adatváltoztatás nem lehetséges

Backup validálása Honnan tudható, hogy a backup használható? Módja: Adatok visszaállítása és verifikációja Igen időigényes és ritkán praktikus Helyette: RESTORE VERIFYONLY FROM <backup_device> […,n] Ellenőrzi a media header-t Verifikálja a backup checksum-ot Olvassa a belső lap láncokat és újraszámítja a backup checksum-ot az összehasonlításhoz

Adatbázis mozgatása Szükség lehet adatbázisok szerveren belüli v. szerverek közötti mozgatására 3 mechanizmus létezik erre: Backup és restore Detach/attach Copy Database Wizard

Detach/Attach Detach: az adatbázis unmount-olása az SQL Serverből A system táblák bejegyzései eltávolításrakerülnek Nem használható tovább az adatbázis Az adatfájlok még jelen vannak a rendszerben Leválasztás után szabadon másolhatók Újra elérhetővé tétel az attach paranccsal A rendszer táblákba hozzáfűzi a megfelelő bejegyzést

Detach/Attach II. Detach példa Attach példa EXEC sp_detach_db ‘AdventureWorks’, ‘true’ Attach példa CREATE DATABASE AdventureWorks ON (FILENAME=‘C:\TEST\AdventureWorks_Data.mdf’), (FILENAME=‘C:\TEST\AdventureWorks_Log.ldf’) FOR ATTACH

Copy Database Wizard Objektumok másolása egy másik instance-ba, vagy egy másik adatbézisba, de ugyanazon instance-ba Grafikus felületen keresztül elérhető

Tárolási paraméterek kezelése Fregmentáció kezelése Statisztikai adatok gyűjtése Adatbázisok méretkarbantartása

Index fregmentáció Indexelés, optimális lekérdezés végrehajtás Indexek elveszthetik hatékonyságukat, ha nincsenek megfelelően menedzselve (fregmentáció) fregmentáció: Ha az adat a táblában módosul és kihat az index lapra INSERT, DELETE, UPDATE  kihat az indexekre

Belső fregmentáció DELETE utasítás hatására Az index lapok nincsenek kellően tele Kevésbé hatékony diszk terület használat Oldalak számának növekedéséhez vezethet Olvasások száma is megnövekedik ennek hatására Ki-belapozásokra lehet szükség, ami lassítja a folyamatot

Külső fregmentáció INSERT, UPDATE hatására Új adatot kellene bevinni az indexek közé Nincs hely  a lap osztódik, új lap generálódik és az adatok a két lapra kerülnek megosztva A page split biztosítja a sorok logikai sorrendjét, de a fizikait nem A lapok nem lesznek fizikai sorrendben  külső fregmentáció Nem folyamatos index lapokat okoz a diszken, Új lapok távol kerülnek az eredeti laptól, és a fizikai sorrend különbözik a logikai sorrendtől

Index fregmentáció azonosítás Dynamic management function (DMF): sys.dm_db_index_physical_stats SELECT utasítással lekérdezhetők: avg_fregmentation_in_percent avg_page_space_used_in_percent Külső fregmentáció esetén az első érték eléri a 10-et. Belső fregmentáció esetén a második érték eléri a 75-öt.

Példa SELECT OBJECT_NAME(dt.object_id), si.name, dt.avg_fregmentation_in_percent, dt.avg_page_space_used_in_percent FROM (SELECT object_id, index_id, avg_fregmentation_in_percent, avg_page_space_used_in_percent FROM sys.dm_db_index_physical_stats (DB_ID(‘AdventureWorks’), NULL, NULL, NULL, ‘DETAILED’) WHERE index_id<>0) as dt INNER JOIN sys.indexes si ON si.object_id=dt.object_id AND si.index_id=dt.index_id

Index fregmentáció kezelése ALTER INDEX … REORGANIZE Defregmentálja a cluster és nem klaszterindexek levél szintjét Fizikailag újrarendezi a lapokat, hogy a logikai, balról-jobbra sorrendnek megfeleljenek. Kompaktabbá teszi az indexeket, ami a kitöltési faktortól függ sys.indexes katalógus nézetben található a „fill factor” Példa: USE AdventureWorks; ALTER INDEX PK_Employee_EmployeeID ON HumanResources.Employee REORGANIZE;

Index fregmentáció kezelése II. ALTER INDEX … REBUILD Minkét típusú fregmentációt megszünteti Eldobja majd újragenerálja az indexeket. Példa: USE AdventureWorks; ALTER INDEX PK_Employee_EmployeeID ON HumanResources.Employee REBUILD; ONLINE opció: ON esetben az indexek rendelkezésre állnak lekérdezéshez és adatmódosításhoz

REORGANIZE vs. REBUILD Amennyiben az indexek nem túlságosan fregmentáltak  REORGANIZE Kisebb erőforrásigényű Automatikusan online fut Erősebb fregmentáció esetén a REBUILD lehet a megoldás. Megoldás: Periodikusan futtassuk a már említett SELECT utasítást a fregmentáció meghatározásához 60<avg_page_space_used_in_percent<75 vagy 15>avg_fregmentation_in_percent > 10  REORGANIZE avg_page_space_used_in_percent<60 or avg_fregmentation_in_percent>15 REBUILD

Statisztikák menedzselése A lekérdezés optimalizálás egy másik fontos összetevői a statisztikai adatok. Oszlop és index statisztika esetén: DB engine rendezi az oszlop értékeit és egy hisztogramot készít A hisztogram 200 oszlopértéket vesz az intervallumokhoz Sorok száma, mely az intervallumra esik Sorok száma, mely az intervallumok közé esik Az intervallumban tárolt értékek sűrűsége Az optimalizálónak segítenek a statisztikák dönteni, hogy index használata megnöveli a lekérdezések hatékonyságát. Emellett a string típusú oszlopokra külön statisztika készül (LIKE)

Automatikus statisztika generálás Index létrehozása során az indexelt oszlopokról statisztikák készülnek AUTO_CREATE_STATISTICS ON A nem indexelt oszlopokról is statisztikák készülnek (LIKE) AUTO_UPDATE_STATISTICS  ON Automatikusan frissülnek a statisztikai adatok periodikusan, ha az adatok változnak

Manuális statisztika generálás sp_createstat tárolt eljárás használatával CREATE STATISTICS UPDATE STATISTICS sp_updatestats tárolt eljárással DROP STATISTICS

Oszlop statisztikák megtekintése sp_autostats térol eljárással sys.stats katalógus view : statisztika sorokat mutat tábla típusú objektumokról sys.stats_columns : egy sort mutat minden oszlopra, ami a sys.stats statisztika része STATS_DATE függvény az adott index statisztika utolsó módosítás dátuma DBCC SHOW_STATISTICS: az aktuális eloszlás statisztikákat mutatja ez adott célra

Méretkarbantartás Nagy törlési műveletek során vagy egyidejű adat betöltés során az adatbázis fájlok mérete nagyobb lehet, mint szükséges Lehetőség van a nem használt lapok eltávolítására és diszk terület felszabadítására Automatikusan és manuálisan is lehet az adatbázis file-ok méretét zsugorítani

Automatikus méretkarbantartás ALTER DATABASE … AUTO_SHRINK ON periodikusan ellenőrzi a DB engine a tárterület használatot és csökkenti az adatbázis fájlok méretét Alapértelmezetten OFF-ra van állítva Lassíthatja a rendszert

Manuális méretkarbantartás Előny: megválasztható, hogy a zsugorítás mikor történjen DBCC SHRINKDATABASE DBCC SHRINKFILE A kezdeti méretnél kisebbre nem lehet zsugorítani.

Tranzakció log méretezése A database tranzakció log fix méretekkel jön létre. A virtuális log file méreténél nem lehet kisebbre zsugorítani. Példa TR log file mérete 10GB 50 virtuális log file-t tartalmaz 200MB/file shrink: töröljük a nem használt VL file-okat 2 marad : 400MB (aktív, vagy uncommitted tr-t tartalmaz)

Adatbázis integritás ellenőrzés DBCC CHECKDB Allokáció verifikáció Szerkezeti integritás Logikai integritás DBCC CHECKALLOC DBCC CHECKTABLE DBCC CHECKCATALOG Service Broker adatok validálása Indexelt view-k tartalmának vizsgálata

DBCC CHECKDB Nagyobb adatbázisok átvizsgálása PHYSICAL_ONLY opció: gyakori ellenőrzések esetén Fizikai konzisztencia ellenőrzése Sérült lapok Ellenőrző összeg hibák Hardware hibák Teljes integritás ellenőrzéshez periodikusan érdemes futtatni a DBCC CHECKDB-t opciók nélkül Hiba esetén: RESTORE Amennyiben nem lehet (méretgondok pl) Repair opciók: REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST, REPAIR_REBUILD

Gyakorlás Futtassuk a DBCC CHECKDB parancsot!

Adatbázis snapshot Adott idejű, csak olvasható másolat Nem tartalmaz tranzakció logot a forrás adatbázis nagyon kis méretű

Copy-On-Write Technology Kezdetben a Database SnapShot nem tartalmaz adatlapokat vagy bármilyen információt a forrás adatbázisról. Amikor egy adatlap változik, az SQL szerver az oldal eredetijét beleírja a DS-ba

Catalog of Changed Pages Egyedi struktúra: bittérkép Oldalak listáját tartalmazza, melyek változtak a snapshot létrehozása óta Az eredeti kép snapshotba írásakor a lap bitje 0-ról 1-re változik

DB Snapshot létrehozása CREATE DATABASE paranccsal Speciális része van Követelmények: Minden egyes fájlcsoporthoz szükség van egy bejegyzésre Minden fájlcsoport logikai nevének egyezőnek kell lennie a forrás adatbázisban levő névvel AS SNAPSHOT OF részt kell a parancsban használni

DB Snapshot létrehozása II. CREATE DATABASE database_snapshot_name ON ( NAME = logical_file_name, FILE = ‘os_file_name’ ) [ , … n ] AS SNAPSHOT OF source_database_name

Korlátozások Nem lehet backup-olni, visszaállítani vagy lecsatolni Ugyabban az instance-ban kell léteznie, mint a forrás DB Full-text indexelés nem támogatott Nem lehet a forrás adatbázist droppolni, lecsatolni, visszaállítani, ha a snapshot jelen van System adatbázisokról nem hozható létre snapshot Szerkezeti változások (pl. fájlcsoportok hozzáadása, törlése) nem engedélyezett

Adatok kinyerése snapshotból SELECT utasítással Az eredményhalmaz 2 helyről származhat: Az adatok, melyek nem változtak a DS létrehozása óta, a forrás adatbázisból jönnek Az adatok, melyek a snapshot létrehozása óta változtak, a DS adatlapjaiból jönnek

Gyakorlás Hozzunk létre adatbázis snapshotot!

Snapshot használata helyreállításhoz Mivel egy adott időpillanatban történt másolatot tartalmaz, lehetséges a visszaállítás belőle Hiba esetén (sérülés, adminisztrációs hiba) INSERT, UPDATE utasításokkal visszaállítható a tartalom Az adatbázis állapotát egy bizonyos időpillanatban mentett állapotára állítja vissza Nem lehet utána további visszaállítást csinálni

Snapshot használata helyreállításhoz II. Korlátozások: Csak egy single DB SnapShot lézethet a forrás adatbázishoz Minden full-text katalógus droppolásra majd újra létrehozásra kerül a forrás adatbázisban A tranzakció log újraépül, mely megtöri a log láncot A forrás adatbázis és a snapshot offline a visszaállítás idejéig

Snapshot használata helyreállításhoz III. RESTORE DATABASE <database_name> FROM DATABASE_SNAPSHOT = <database_snapshot_name>

Gyakorlás Állítsunk vissza adatbázist snapshotból!

Aktív adatbázis elemek Agentek Jobok Alertek

Agent Job SQL Server Agent egy ütemező motor Képes jobokat futtatni megadott időközönként Használat: Backupolás Indexelés Integritás ellenőrzés Egy Job lépésekből áll (job steps) Job tulajdonos biztosítja a biztonsági környezetet és a job futtatásának ütemezését

Agent Job létrehozása Magas szintű lépések: Létrehozásához: Hozzuk létre a jobot, adjunk neki nevet, adatbázis környezetet és tulajdonost Adjunk hozzá egy v. több job lépést Opcionálisan rendelkezzünk az ütemezésről Létrehozásához: SQL Server Agent Node alatt az Object Explorer-ben Job neve: 64 karakter hosszú lehet, legyen kifejező Job kategória: beépítettek v. saját is definiálható

Agent Job létrehozása II.

Agent Job létrehozása II.

Job Owner megadása Csak a job owner vagy sysadmin csoportbeli user módosíthatja a jobot Biztosítani kell a megfelelő jogokat a job ownernek Proxy accounts Replication SSIS Analysis Services CmdExec ActiveX

Job lépések létrehozása Név és típus megadása Parancs definiálása Loggolási és értesítési akciók definiálása

Job lépések létrehozása II.

Job lépések létrehozása III.

Job lépések létrehozása IV.

Job ütemezések létrehozása A job lépések létrehozása után Egy v. több ütemezés kapcsolható a jobhoz

Job ütemezések létrehozása II.

Job ütemezések létrehozása III.

Gyakorlás Hozzunk létre jobot!

Maintenance Plan Wizard Full, differential, transakció log backup Integritás ellenőrzés Újraindexelés Létrehozás: SQL Server Maintenance Plan Wizard

Maintenance Plan Wizard II.

Maintenance Plan Wizard III.

Maintenance Plan Wizard IV.

Maintenance Plan Wizard V.

Maintenance Plan Wizard VI.

Maintenance Plan Wizard VII.

Maintenance Plan Wizard VIII.

Maintenance Plan Wizard IX.

Maintenance Plan Wizard X.

Maintenance Plan Wizard XI.

Maintenance Plan Wizard XII.

Maintenance Plan Wizard XIII.

Gyakorlás Hozzunk létre Maintenance Plan-t!

Operátorok konfigurálása Értesítések fogadásához definiálhatók operátorok Elnevezést és értesítési módozatot kell beállítani, ill. egyéb paramétereket, mint pl. email

Operátorok konfigurálása II.

Riasztások Az adminisztrátorok értesítése speciális feltételek teljesüése esetén Konfigurálás: Új alert létrehozása Típusának meghatározása Monitorozandó feltételek konfigurálása Akció definiálása a feltétel teljesülése esetén Üzenetkezelő opciók definiálása

Riasztások II.

Riasztások III.

Riasztások IV.

Riasztások V.

Gyakorlás Defináljunk alerteket!

Monitorozás SQL Server Profiler System Monitor Tuning Advisor

SQL Server Profiler Lekérdezés minták analizálása teljesítmény problémák felderítéséhez SQL Trace: Eseménykezelő alrendszer : SQL Trace Külső API alapú Sokféle paraméterrel meghívható Szűrők alkalmazhatók Transact-SQL-lel v. SQL SMO-val használható

Trace definiálása

Trace definiálása (events) II.

Filterek definiálása

Oszlopok szervezése

Trace futtatása

Trace futtatása II.

Start, Stop, Pause Trace Pause: Stop: Start: Adat gyűjtés felfüggesztésre kerül Az események nem kezelődnek a pause alatt Stop: Bezárja a trace session-t Start: Újraindításnál az adatgyújtés resetelődik, előő adatok elvesznek

Trace Log mentése Trace definiciók mentése Trace adatok mentése Export->Script Trace Definition Trace adatok mentése Save to file Save to table

ShowPlan adatok gyűjtése Értékeléshez sok, különböző adatra van szükség Különböző lekérdezési tervek különböző eredményeket szolgáltatnak Showplan: lekérdezés mentése amely a terv során lefutott Tervek összehasonlítása ugyanazon lekérdezés több permutációjára

Showplan események

XML Showplan kezelés

ShowPlan XML megjelenítés

Replay Trace Trace ismétlését teszi lehetővé Követelmények: SQL Server autentikáció Specifikus események kezelése, melyek a Replay template-ben definiáltak

Replay Trace II.

System Monitor Monitorozott adatok gyűjtésére való ez is Counter Log létrehozása System Monitoradd counterstart analysis Minden adat live módban kerül feldolgozásra, nincs mód loggolásra egy file-ba akésőbbi analízis céljából System MonitorPerformance Logs And Alerts Counter Logs New Log settingsnév megadása

Counter Log megadása

Tuning Advisor Query optimalizálás fontos szereplője Indexekre, indexelt nézetekre, particiókra ad követelelményeket „Brute force”-hoz hasonló vizsgálat az indexeknél Veszi a workload file-t inputként Teszteli a query-ket az összes lehetséges index permutációra A legjobb megoldás elérése a cél

Workload File létrehozása Trace file Trace table Transact-SQL scripttel SQL Server Profiler Tuning trace template  save result to file, vagy table

DTA konfigurálása DTA futtatása és kapcsolódás a szerverhez Workfile kiválasztása Tuning opciók megadása

Analysis Session konfigurálása

Tuning opciók megadása

Analízis folyamata

Teljesítmény előírások