Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

11-15. előadás Barabás Péter. Témakörök  Függvények  Létrehozása  Determinisztikus és nem determinisztikus függvények  Tárolt eljárások  Létrehozása.

Hasonló előadás


Az előadások a következő témára: "11-15. előadás Barabás Péter. Témakörök  Függvények  Létrehozása  Determinisztikus és nem determinisztikus függvények  Tárolt eljárások  Létrehozása."— Előadás másolata:

1 előadás Barabás Péter

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

3 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 ([ [ AS ][ type_schema_name. ] parameter_data_type [ = default ] } [,...n ] ] ) RETURNS return_data_type [ WITH [,...n ] ] [ AS ] BEGIN function_body RETURN scalar_expression END [ ; ]

4 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 ( [ [ AS ] [ type_schema_name. ] parameter_data_type [ = default ] } [,...n ] ] ) TABLE [ WITH [,...n ] ] [ AS ] BEGIN function_body RETURN END [ ; ]

5 Determinisztikus és nem determinisztikus függvények  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ő

6 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

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

8 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

9 Tárolt eljárások IV.  Használathoz futtatási jog szükséges  GRANT EXECUTE ON TO  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

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

11 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

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

13 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ó

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

15 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

16 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.

17 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  lockolja azt adatbázist és blockolja az összes tranzakciót  Tesz egy jelölést a tranzakció logba  Felengedi az adatbázis lockolást  A két log jelölés közötti tranzakciókat hozzáfűzi a backup- hoz

18 Teljes mentés III.  Parancs:  BACKUP DATABASE TO DISK=‘ \ ’ 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

19 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ó.

20 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

21 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

22 Különbségi mentés IV.  Parancs:  BACKUP DATABASE TO DISK=‘ \ ’ WITH DIFFERENTIAL

23 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

24 Tranzakció log mentés II.  Parancs:  BACKUP LOG TO DISK=‘ \ ’ WITH INIT

25 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

26 Filecsoport mentés II. • Parancs:  BACKUP DATABASE FILEGROUP = ‘ ’ TO DISK=‘ \ ’  BACKUP DATABASE FILEGROUP = ‘ ’ TO DISK=‘ \ ’ WITH DIFFERENTIAL

27 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

28 Tükrözött mentés II.  BACKUP parancs opcionális része:  [[MIRROR TO [,…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

29 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

30 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

31 Részleges mentés II.  Jelentése:  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’

32 Részleges mentés II.  Jelentése:  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’

33 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!

34 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

35 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.

36 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.

37 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

38 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

39 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

40 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)

41 Példák  Visszaállítási folyamat (full+diff+TR)  Full  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

42 Példák II.  Visszaállítási folyamat (full+multiple TR)  Full  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

43 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

44 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

45 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 SET PAGE_VERIFY CHECKSUM  Alaphelyzetben ki van kapcsolva  Korrupt lapok a suspect_pages táblába loggolódnak az msdb adatbázisban

46 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  GO  RESTORE DATABASE PUBS PAGE=‘1:88’ FROM DISK=‘C:\HA\DEMO\BACKUP\PUBSMIRROR1.BAK’ WITH RECOVERY  GO  Tranzakciók a TR logba  USE MASTER  GO  RESTORE LOG PUBS FROM DISK=‘C:\HA\DEMO\BACKUP\PUBS1.TRN’ WITH RECOVERY  GO

47 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

48 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

49 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 […,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

50 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

51 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

52 Detach/Attach II.  Detach 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

53 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ő

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

55 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

56 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

57 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

58 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.

59 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

60 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;

61 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

62 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_fregmentation_in_percent > 10  REORGANIZE  avg_page_space_used_in_percent 15  REBUILD

63 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)

64 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

65 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

66 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

67 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

68 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

69 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.

70 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)

71 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

72 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

73 Gyakorlás  Futtassuk a DBCC CHECKDB parancsot!

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

75 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

76 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

77 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

78 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

79 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

80 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

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

82 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

83 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

84 Snapshot használata helyreállításhoz III.  RESTORE DATABASE FROM DATABASE_SNAPSHOT =

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

86 Aktív adatbázis elemek  Agentek  Jobok  Alertek

87 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

88 Agent Job létrehozása  Magas szintű lépések:  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ó

89 Agent Job létrehozása II.

90

91 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

92 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

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

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

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

96 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

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

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

99 Gyakorlás  Hozzunk létre jobot!

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

101 Maintenance Plan Wizard II.

102 Maintenance Plan Wizard III.

103 Maintenance Plan Wizard IV.

104 Maintenance Plan Wizard V.

105 Maintenance Plan Wizard VI.

106 Maintenance Plan Wizard VII.

107 Maintenance Plan Wizard VIII.

108 Maintenance Plan Wizard IX.

109 Maintenance Plan Wizard X.

110 Maintenance Plan Wizard XI.

111 Maintenance Plan Wizard XII.

112 Maintenance Plan Wizard XIII.

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

114 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.

115 Operátorok konfigurálása II.

116 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

117 Riasztások II.

118 Riasztások III.

119 Riasztások IV.

120 Riasztások V.

121 Gyakorlás  Defináljunk alerteket!

122 Monitorozás  SQL Server Profiler  System Monitor  Tuning Advisor

123 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ó

124 Trace definiálása

125 Trace definiálása (events) II.

126 Filterek definiálása

127 Oszlopok szervezése

128 Trace futtatása

129 Trace futtatása II.

130 Start, Stop, Pause Trace  Pause:  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

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

132 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

133 Showplan események

134 XML Showplan kezelés

135 ShowPlan XML megjelenítés

136 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

137 Replay Trace II.

138 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

139 Counter Log megadása

140 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

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

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

143 Analysis Session konfigurálása

144 Tuning opciók megadása

145 Analízis folyamata

146 Teljesítmény előírások

147


Letölteni ppt "11-15. előadás Barabás Péter. Témakörök  Függvények  Létrehozása  Determinisztikus és nem determinisztikus függvények  Tárolt eljárások  Létrehozása."

Hasonló előadás


Google Hirdetések