Obsah 1 Ladění dotazů 1 2 SQL Server Profiler 2 2.1 Sledování na straně klienta.................... 2 2.2 Sledování na straně serveru................... 4 2.3 Analýza trace souboru...................... 5 2.4 Blokování............................. 7 2.5 Profiler a Performance Monitor................. 7 3 Data Collector 9 3.1 Konfigurace............................ 9 3.2 Reporty............................... 9 4 Čekání a fronty 9 1 Ladění dotazů Pro ladění dotazů a vypisování query plánů můˇzeme vyuˇzít SSMS. V SSMS je možnost zapnout výpis query plánu při provádění dotazu. Je to icona Include actual execution plan. Po vykonání dotazu se můžeme v záložce execution plan podívat na jednotlivé operace query plánu a jejich podíl na složitosti dotazu (cost). 1
2 SQL Server Profiler Obrázek 1: Query plan dotazu 2.1 Sledování na straně klienta SQL Server Profiler (SSP) lze nálezt v nabídce Start Programy MS SQL Server Performance tools. Běžným způsobem využití profileru je zjištění ceny dotazů. Pro vytvoření nového sledování provozu (trace) je potřeba kliknout na File New Trace. Vybereme instanci SQL Serveru jenž se bude sledovat a po té můžeme v okně Trace Properties definovat detaily sledování. Obrázek 2: První záloˇzka okna Trace Properties 2
Obrázek 3: Druhá záloˇzka okna Trace Properties Na obrázku 2 je detail nastavení sledování v Trace Properties. Implicitně je výstup vypisován pouze na obrazovku, takže toto změníme na výstup do tabulky (první záloˇzka). Ve druhé záloˇzce (obrázek 2) definujeme události, jenˇz se budou zachytávat. Definujeme události SQL:BatchCompleted a RPC:Completed, aby se zachytávaly ukončené T-SQL dávky a uloˇzené procedury. Pokud klikneme na tlačítko Column Filters, pak můžeme definovat filtr na zachytávané události. Tedy například zachytávání jen událostí určitého uživatele, podle toho jak dlouho běží atd. Po nastavení můˇzeme kliknou na tlačítko Run a spustit zachytávání událostí na straně klienta. Po spuštění nějakých operací na serveru se nám tyto operace začnou zobrazovat i v profileru. Problémy profileru na straně klienta: Dá se vyuˇzít spíše pro menší mnoˇzství SQL příkazů. Můˇze značně zpomalovat jeich běh. Občas se může stát, že některý příkaz není zaznamenán jelikož SQL Server nestíhá. Sledování probíhá na straně klienta i když SQL Server Profiler spouštíme na serveru na kterém beˇzí sledovaná instance. 3
2.2 Sledování na straně serveru K SSP existuje ještě druhá varianta, která netrpí zmíněnými problémy. Jedná se o sledování na straně serveru (server-side trace), které je definována množinou uložených procedur. Toto je ovšem varianta pro zkušeného administrátora, který je schopen tyto procedury napsat. Naštěstí v profileru existuje možnost vytvořit skripty z připraveného sledování, které mohou být vyuˇzity pro sledování na straně serveru. Po vytvoření sledování v profileru dejte export Sript Trace Definition For SQL Server 2005 2008. Takto vytvoříte skript, který je možné spustit na instanci, kterou chceme sledovat. Je pouze nutné ve skriptu přepsat InsertFileNameHere na cestu k trace souboru, kde budeme ukládat sledování. Jakmile sledování vytvoříme můˇzeme vyuˇzít příkazy sp trace setstatus a fn trace getinfo ke kontrole sledování. Další podrobnosti lze nalézt v books online 1. Spuštění sledování: execute sys.sp trace setstatus @traceid, 1; go Zastavení sledování: execute sys.sp trace setstatus @traceid, 0; go execute sys.sp trace setstatus @traceid, 2; go Zjištění @traceid dostupných sledování: select * from sys.fn trace getinfo(0); go Výsledek sledování se uloží do specifikovaného trace souboru. Trace soubor je dál možné využít dvě způsoby: Pouˇzít jej jako zachycené vytíˇzení, které se spustí znova. K tomuto je moˇzné vyuˇzít šablonu TSQL Replay šablonu v okně Trace Properties profileru 2 3. Soubor zanalyzovat a zobrazit uˇzitečné statistiky. (viz. kapitola 2.3) 1 http://msdn.microsoft.com/en-us/library/ms191006.aspx 2 http://msdn.microsoft.com/en-us/library/ms189604.aspx 3 http://msdn.microsoft.com/en-us/library/ms187857.aspx 4
2.3 Analýza trace souboru Pro analýzu trace souboru je moˇzné vyuˇzít volně dostupné nástroje RML 4. Tento balík obsahuje tři základní nástroje: ReadTrace Reporter OStress Balík je již na image SQL Server 1 instalován. Pokud využíváte čistou instalaci je potřeba balík nejprve instalovat. Před analýzou trace souboru je nutné sledování nejprve zastavit. Po té v menu Start Programy RML Utilities for SQL Server spust te RML Cmd Prompt a v něm spust te příkaz: ReadTrace -I CestaTraceSouboru -o VystupniAdresar Obrázek 4: Hlavní okno analýzy v Reporter nástroji 4 http://support.microsoft.com/kb/944837/en-us?fr=1 5
Obrázek 5: Statistiky jednotlivých SQL příkazů ReadTrace provede analýzu trace souboru, která je uloˇzena v PerfAnalysis databázi a zárověň automaticky spustí Reporter, který tuto analýzu otevře a zobrazí. Na obrázku 4 a 5 můˇzeme vidět příklad statistik z nástroje Reporter. Tyto statistiky se zaměřují na základní parametry SQL dotazů, jako je počet logických přístupů (Reads), počet zápisů (Write), průměrný procesorový čas (Avg processor time), celkový procesorový čas v měřeném intervalu (Total duration). Podrobnější informace je možné získat z Perf- Analysis databáze přímými dotazy na uložená data. Poznámky: Pro odečítání statistik v SQL Serveru musíme provádět překlad kaˇzdého příkazu zvlášt. Není možné pouze příkazy předkompilovat a pak jen spouštět s různými hodnotami jako v Oracle, jinak ve statistikách zachycených v trace souboru nebudeme moci jít na úroveň jednotlivých příkazů. 6
Spouštění ReadTrace občas skončí chybou. V zásadě jsem narazil na dva důvody: Není ukončen sběr dat, zkuste spustit skript Stop.sql. Selˇze připojení k SQL Serveru přes uˇzivatele user, po té se mi osvědčilo pouze ukončení SSMS. 2.4 Blokování SSP nám umoˇzňuje sledovat i další důleˇzité události v databázi. Jejich nastavení je moˇzné provést v druhé záloˇzce Trace Properties (obrázek 3). Pokud zaškrtneme možnost Show all events zobrazí se nám další události jenž je možné sledovat. Z tohoto seznamu vybereme položku Blocked process report, které je v kategorii Errors and Warnings. Takto vytvořené sledování jiˇz bude zachycovat i blokování. Dále je nutné nastavit parametr instance Blocked Process Treshold na nějakou hodnotu čekání při jejímˇz překročení dojde k vyvolání varování (události). Pak jiˇz můˇzete otestovat, pokud paralelně spustíte ze SSMS tento kód: begin transaction select * from aukce(xlock) where id = 15; waitfor delay 00:00:30.0 -- wait for 1 minute commit transaction Jelikoˇz SQL Server pouˇzívá pesimistický přístup k zamykání je dobré sledovat také frekvenci blokování jednotlivých vláken, zda-li nedochází k nepřiměřeně vysokému blokování po nepřiměřeně dlouhou dobu. 2.5 Profiler a Performance Monitor Do sledování v SSP je možné importovat také data z performance monitoru (PM), který je součástí MS Windows. PM je nástroj, který umoˇzňuje sledovat statistiky OS a tyto data také zaznamenávat do logu. Zaznamenávání dat do tzv. counter logů je moˇzné v PM zahájit pokud v záloˇzce Performance Logs and Alerts vybereme položku Counter Logs a zde po kliknutí pravým tlačítkem na System Overview vybereme Start. Záznamy jsou ukládány do 7
souboru specifikovaném vlastnostmi toho logu. Implicitně by to měl být adresář C:\ PerfLogs. Po zastavení sledování databáze, zastavíme také ukládání dat do PM logu. V SSP otevřeme trace soubor s uloženým provozem. Po té klikneme na menu File Import Performance Data a otevřeme counter log vytvořený v PM. V SSP se vám otevře okno, které bude vypadat podobně jako na obrázku 6 a kde budou zobrazeny statistiky z PM spolu s jednotlivými zachycenými příkazy z SQL Serveru. Obrázek 6: Příkazy trace souboru zobrazené spolu s daty z Performance monitoru Po kliknutí na událost v trace logu se nám nastaví také pozice červené čáry, ukazující korespondující statistiky z PM. To je možné provést i naopak. 8
3 Data Collector 3.1 Konfigurace Tento nástroj je moˇzné konfigurovat v SSMS kdyˇz v záloˇzce Management Data Collection klikneme pravým tlačítkem a vybereme poloˇzku Configure Data Management Warehouse. Nejprve je potřeba provést vytvoření databáze do které se budou statistiky ukládat. V průvodci tedy vybereme možnost Create or upgrade a management data warehouse. V dalším kroku vytvoříme databázi DMW a přiřadíme aktuálnímu uživateli role nutné pro sběr dat. Po dokončení jsme úspěšně vytvořili Data management warehouse (DMW). Po té spustíme Configure Data Management Warehouse znovu a tentokrát v průvodci vybereme druhou možnost Set up data collection. V dalším okně vybereme databázi DMW, kterou jsme vytvořili v předchozím kroku. Specifikujeme také adresář, kde se budou ukládat data před uložením do DMW databáze. Po potvrzení změn se automaticky zahájí sběr dat tří implicitních collection set. Je možné nastavit parametry jednotlivých collection set, pokud na ně klikneme pravým tlačítkem a vybereme možnost Properties. Zde můžeme nastavit frekvenci nahrávání (Non-cached vs. cached) a nebo dobu zachování dat. 3.2 Reporty Po uložení dat do databáze je možné tyto data zobrazit pomocí reportů jenž jsou k dispozici pro jednotlivé collection set. 4 Čekání a fronty podrobnější popis lze nalézt v dokumentu: Tom Davidson, Wait and queues 5. 5 http://msdn.microsoft.com/en-us/library/cc966413.aspx 9
S touto kapitolou souvisí skripty uloˇzené v image v adresáři...\my Documents\scripts\WaitStat. Pro diagnostiku čekání je moˇzné vyuˇzít pohled sys.dm os wait stats (viz. skript PrintWaitStat.sql). Tento pohled obsahuje statistiky od spuštění SQL Serveru. Pro vynulování těchto statistik je nutné spustit příkaz: DBCC SQLPERF("sys.dm os wait stats",clear);. Pokud budeme chtít statistiky čekání sbírat průběˇzně můˇzeme vyuˇzít skripty track waitstat 2005.sql 6 a get waitstat 2005.sql 7. Jako první krok je potřeba vytvořit tabulku waitstat (skript create waitstat.sql) a po vytvoření uložených procedur je možné sledování wait statistik spustit skriptem StartWaitStat.sql. Ve výpisu, který nám zobrazí procedura get waitstat 2005.sql výsledky tří dotazů. Ve druhém dotazu jsou seřazeny jednotlivé příčiny čekání. Jedna z příčin čekání mohou být časté blokování, pak se ve výpisu objevují položky LCK *. Je potřeba zváˇzit nastavení úrovně izolace u jednotlivých transakcí a jejich délku. U SQL Serveru obecně platí, ˇze transakce by měly být co nejkratší. Další příčinou mohou být časté přístupy na disk. V tom případě se v seznamu na předních místech objevuje položka PAGEIO- LATCH, ASYNC/IO COMPLETION, nebo WRITELOG. Poslední položka souvisí se zapisováním do redo log souboru a v podstatě se dá řešit jen umístěním log soubor na rychlejší disk, nebo alespoň na disk, který není zatěˇzován dalšími procesy. V posledním dotazu je poměr mezi celkovým čekáním a čekáním způsobeným na CPU. Tato hodnota by neměla mít vyšší hodnotu než 25% jinak nemáme na danné vytížení dostatečný procesorový výkon. Pochopitelně tato hodnota může být zavádějící, pokud nemáte databázi dobře odladěnu, může docházet ke zbytečným operacím, které zaměstnávají procesor. 6 http://gallery.technet.microsoft.com/scriptcenter/en-us/ 8c90bd2e-9def-4f44-bce4-e5dae4d86f71 7 http://gallery.technet.microsoft.com/scriptcenter/en-us/ 86886b7f-8f75-4052-99d1-ef8ebd910a88 10