Monitorozás Általános bevezető Eszközök Kiragadott példák Demó { +néhány gondolat } Hangolás

Minél kevesebb hatás a felügyelt rendszerre Rontja a teljesítményt Hamisíthatja a mért adatokat Tetszőleges részletességű monitorozás Pl. lockok: instance – adatbázis – tábla – lap szinten Pont a szükséges adatokat monitorozzuk „ami elmúlt, soha nem jön vissza már” (Máté Péter) A sok logot soha senki nem akarja kielemezni

Mi lehet a probléma? Nem elég csak akkor monitorozni, amikor probléma van – kell a viszonyítási alap Időnként alaposan, folyamatosan átfogóan Processzor, memória, diszk, hálózat, tranzakciók, lockok Probléma esetén a megfelelő részt tovább bontani Teljesítményszámláló Érték Processor:%Processor time\_Total PhysicalDisk:Avg Disk Write Queue Length\_Total 5 SQLServer:Buffer Manager\Page life expectancy 51 SQLServer:Transactions\ Transactions 119

Performance Studio SQL Profiler SQL Trace Data Collection (Performance Data Warehouse) Data Collection (Performance Data Warehouse) Performance Counterek Performance Counterek Extended Events (xEvents) DMV-k SQL Server Management Studio ??

(Performance Data Warehouse) Proaktív/preventív monitorozás eszköze Baseline készítésére kiváló Különböző adatforrások egységes kezelése Pillanatnyilag kezelt adatforrások (collector type): Teljesítményszámlálók SQL Trace T-SQL lekérdezések Lekérdezés statisztikák (előre definiált halmaz) Bővíthető Központi monitorozás 3-5% többletterhelés msdb és Management Data Warehouse adatbázisok

Data provider: egy definiált adatforrás, ami egy collector type szerinti adatokat szolgáltat Collector type: logikai egységesítő réteg, ami a különböző típusú adatforrásokból történő tényleges adatkinyerést meghatározza Collection item: egy collector type egy példánya Collection set: collection item-ek csoportja, a kezelhető adatgyűjtési egység Collection mode - cached: az adat nem kerül be azonnal az adatbázisba (később)

Data providerek Collection Set Collector type Collection item MDW Data Collector Cache Riportok

Sok eddig rejtett belső esemény kinyerhető Pl. kapcsolatonkénti várakozások Korrelálható az operációs rendszer eseményeivel Kernel trace-szel összevethető Event Tracing for Windows (ETW) segítségével Nincs GUI Minimális többletterhelés a rendszer számára 2GHz-es CPU-n 2  s / eseményfeldolgozás Folyamatosan futtatható Egy esemény többszörösen feldolgozható

{ SQL 2008 teljesítménymonitorozás }

Sokkal hatékonyabb működés Az SQL Server 2008 Integration Services 1.18 TB adatot 29 perc 54 másodperc alatt töltött be (szövegfájlokból) Eddig senki nem mutatott fel jobb eredményt

Kihívások Hová tegyem a clustered indexet? Hová tegyem a clustered indexet? A plusz indexek rontják a DML utasítások hatékonyságát  Rosszul megírt alkalmazáslogika  Tűzzünk ki célt Kevesebb I/O művelet Egy gyakori lekérdezés gyorsítása Egy erőforrásigényes lekérdezés optimalizálása Monitorozzunk előtte-utána { baseline } { Statisztika? Index fragmentáció? }

Database Engine Tuning Advisor* Tranzakció izolációs szintek* Particionált táblák* Minimally logged insert Policy-based Framework Adat és backup tömörítés OPTIMIZE FOR* {UNKNOWN} Plan Guide* Plan Forcing* Filtered index FORCESEEK Resource Governor * SQL Server 2005 (SP2)

CPU és memória szabályozása A rendszerprocesszek védettek (DAC is) A ki nem használt minimum memória elveszett CPU soft, memória hard limit CPU-t ad többet, ha lehet, memóriát nehéz visszavenni Versengés esetén nem ígér arányos elosztást A max 70%-os pool kaphat több erőforrást, mint a 100%- os

defaultinternal KiskerPoolRiportPool RiportKisker Classifier UDF KiskerWG internal default RiportWG Max CPU: 20% Max mem: 20% KR Min CPU: 60% Max CPU: 100% Max mem: 100% Max CPU: 100% Max mem: 100% Min CPU: 20% Max CPU: 100% Max mem: 100%

RiportPool min:10%, max 30% KiskerPool min:30%, max 80% Default min: 0%, max 100% dbo.tbl1... Megosztott memória

Adatot sor vagy lap alapon, csak a lapon tárolt adatokat! Mentés számszerűen: BACKUP DATABASE AdventureWorks TO ‘AdvBAK’ WITH COMPRESSION (tömörítetlen adatbázis) Tömörítetlen mentés Tömörített mentés Backup I/O2410 Backup CPU93126

Csak a rekordok egy részére készül el az indexfa Kevesebb helyet igényel Gyorsabb futás Nemcsak filtered index, de filtered statisztika is van (join-t segítheti) CREATE INDEX IX_Address ON Person.CustomerData(City, Address) WHERE is_active = 1 CREATE INDEX IX_Address ON Person.CustomerData(City, Address) WHERE is_active = 1

Full table scan vs. Index seek Segítség, ha ismerünk összefüggést az adatok között (pl. ügyfélszámok és regisztrációs dátumok), és azok egyenetlen eloszlásúak Ha nincs megfelelő index, akkor elbukik { csak akkor használjunk hinteket, ha pontosan felmértük a helyzetet és a következményeit } SELECT * FROM Person.Address WITH (FORCESEEK) WHERE StateProvinceID = 8 SELECT * FROM Person.Address WITH (FORCESEEK) WHERE StateProvinceID = 8

Bizonyos esetekben nem nyúlhatunk az alkalmazáshoz és a lekérdezésekhez Külső fejlesztés, több telepített példány, stb. Megadhatunk teljes végrehajtási tervet (XML) vagy csak hinte(ke)t EXEC = = = N'SELECT TOP 233 * FROM = N'SELECT TOP 233 * FROM = = = = = = = N'OPTION (MAXDOP = N'OPTION (MAXDOP 1)' EXEC = = = N'SELECT TOP 233 * FROM = N'SELECT TOP 233 * FROM = = = = = = = N'OPTION (MAXDOP = N'OPTION (MAXDOP 1)'

{Teljesítményhangolás}

Az SQL Server 2008 sokat ad hangolhatóság terén is Próbálják ki az SQL Server 2008-at minél előbb Ez csak egy rövid áttekintés volt ? ?

{ Viszontlátásra}