Kolik času trávíte odstraňováním problémů s výkonem jako správce databáze nebo vývojář? Sledoval jsi to někdy? Jako průměrné celkové procento vašeho dne to nemusí vypadat jako moc času, ale když je problém vážný, můžete strávit hodiny jeho sledováním a prací na analýze hlavních příčin. Někdy problém zmizí a vy neznáte pravý původ. A ještě horší? Když musíte bojovat s těmito problémy uprostřed noci nebo o víkendu. Nejen, že se snažíte vyřešit problém, ale přicházíte o svůj osobní volný čas. Jak to zmírníme? Jak z rovnice odstraníme náš čas a úsilí a zároveň napravíme výkon?
Funkce automatického ladění v SQL Server 2017 Enterprise Edition a Azure SQL Database je prvním krokem ke zkrácení času, který odborníci na data stráví odstraňováním problémů a řešením problémů s výkonem. Tato funkce zahrnuje automatickou opravu plánu a automatickou správu indexu (k dispozici pouze v Azure SQL Database), které jsou povoleny nezávisle. V tomto příspěvku se chci zaměřit na funkci Automatická korekce plánu. S automatickou opravou plánu, pokud SQL Server zjistí, že dotaz výrazně ustoupil, vynutí stabilizaci výkonu posledního známého dobrého plánu pro dotaz. V zásadě to znamená, že místo vás, správce databází nebo vývojáře, kdo bude o víkendu zavolán ohledně výkonu systému, bude to řešit SQL Server za vás. Zní to příliš jednoduše, že? Pojďme se na to podívat.
Pod krytem
Nejprve je důležité pochopit, že automatická oprava plánu používá úložiště dotazů, takže musí být pro databázi povolena. Za druhé, automatická oprava plánu je prostě automatické vynucování plánu. Zatímco Query Store je nabízen jako letový záznamník pro vaši databázi, který sleduje text dotazu, plány, statistiky běhu a statistiky čekání, ale také vám umožňuje vynutit plán pro dotaz, aby byl zajištěn konzistentní výkon. Automatická oprava plánu je vynucování plánu bez vašeho zásahu.
Povolení automatické opravy plánu
Jak již bylo zmíněno, Query Store musí být nejprve povolen pro databázi uživatelů. To lze provést v SSMS, s T-SQL a pomocí REST API pro Azure SQL DB. Všimněte si, že Query Store je ve výchozím nastavení povolený pro databáze v Azure a je od 4. čtvrtletí 2016.
Povolení úložiště dotazů prostřednictvím SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Povolení úložiště dotazů pomocí T-SQL
Výše uvedený kód je výchozí T-SQL ze SSMS, pokud jej naskriptujete. V Azure SQL Database nespouštíte příkaz USE. Pokud chcete změnit kteroukoli z výchozích možností, přečtěte si můj příspěvek Nastavení úložiště dotazů o tom, jaké jsou tyto možnosti, a úvahy o alternativních hodnotách.
Jakmile je Query Store povoleno, můžete pomocí Azure Portal, T-SQL nebo EST API povolit automatickou opravu plánu v Azure SQL Database ((a C# a PowerShell jsou v práci). Lze ji povolit pouze s T-SQL v SQL Server 2017.
Povolení automatické opravy plánu na Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Povolení automatické opravy plánu v T-SQL
Všimněte si, že automatická oprava plánu bude v blízké budoucnosti ve výchozím nastavení povolena pro nové databáze v Azure. Počínaje lednem 2018 se povoluje automatické ladění pro databáze Azure SQL Database, které ho ještě neměly, s upozorněním zasílaným správcům, takže tuto možnost lze v případě potřeby zakázat.
Jak to funguje
S povolenou automatickou opravou plánu SQL Server monitoruje výkon dotazů pomocí dat úložiště dotazů. Očekává významnou změnu* ve výkonu CPU** se 48hodinovým oknem***. Všimněte si hvězdiček v té větě... ty jsou záměrně:
- *Hranice toho, co představuje významnou změnu, není zdokumentována, protože společnost Microsoft si vyhrazuje právo ji změnit.
- **Metrika použitá k určení změny výkonu (CPU) není zdokumentována, protože společnost Microsoft si vyhrazuje právo ji změnit. To znamená, že Microsoft by mohl zvážit další dimenze, aby se podíval na výkon, pokud by to bylo lepší / výkon lepší než samotný CPU.
- ***Časové období, za které se porovnávají údaje o výkonu dotazu, není zdokumentováno ze stejného důvodu, společnost Microsoft si vyhrazuje právo jej změnit.
- Poznámka:Přestože výše uvedené položky nebyly zdokumentovány, potvrdil jsem příslušným jednotlivcům ve společnosti Microsoft, že tyto informace lze sdílet s porušením jakékoli smlouvy NDA. Je nesmírně důležité pochopit, že hodnoty nejsou pevné a mohou se měnit s očekáváním, že se změní, aby se zlepšila spolehlivost funkce.
Nedostatek dokumentace a možnost změn prahové hodnoty může být pro některé jedince frustrující, ale zde je to, co je opravdu důležité mít na paměti:
Microsoft denně zachycuje terabajty provozních telemetrických dat z SQL Azure Databases a tato data jsou kritická pro automatické funkce, které jsou vyvíjeny. Tato data zahrnují věci jako query_id, query_plan_id a query_hash a Microsoft NEZAchytává query_text nebo query_plan (nesledují vaše skutečná data). Microsoft tuto provozní telemetrii nejen archivuje nebo ji nepoužívá k řešení problémů, ale těží tato data a používá je k vývoji algoritmů a modelů, které umožní serveru SQL činit nezávislá a inteligentní rozhodnutí.
SQL Server může využít nepřeberné množství dat v Query Store, která podrobně popisuje výkon dotazů, a automatická oprava plánu začíná porovnáním aktuálního výkonu pro dotaz s minulým výkonem, aby se zjistilo, zda došlo k regresi výkonu. Snížil se výkon nebo se zhoršil, a pokud ano, je to o významnou částku?
Pokud došlo k regresi ve výkonu dotazu, pak SQL Server vynutí poslední známý dobrý plán pro tento dotaz, který je samozřejmě stažen z Query Store. Ale tím to nekončí. SQL Server pak pokračuje v monitorování výkonu – stále pomocí Query Store – aby se potvrdilo, že vynucený plán je pro daný dotaz stále dobrým plánem, což znamená, že dotaz s vynuceným plánem funguje lépe než regresní verze. Pokud tento dotaz nefunguje lépe, plán zruší. Plán lze také zrušit, pokud dojde k rekompilaci nebo pokud selže vynucení.
Tento cyklus pokračuje; pokud má dotaz vynucený plán a pak je tento plán nevynucený z jednoho z výše uvedených důvodů, může být stejný plán vynucen znovu později, nebo může být pro tento dotaz později vynucen jiný plán. Toto je nepřetržitý proces, ke kterému dochází, pokud máte pro databázi povolenou možnost Automatická korekce plánu. Nyní je zajímavé, že se můžete podívat na stejné informace, které tato funkce zachycuje, a použít je k vynucení plánů ručně. To znamená, že v SQL Server 2017 Enterprise Edition a v Azure SQL Database jsou tato data shromažďována v sys.dm_db_tuning_recommendations DMV, i když není povolena funkce Automatic Plan Correction, takže můžete tato data prozkoumat a řídit se jejich doporučeními k vynucení plánů. pro konkrétní dotazy na vlastní pěst. Všimněte si, že pokud vynutíte plán pomocí doporučení ze sys.dm_db_tuning_recommendations, nikdy nebude automaticky zrušen. Dále, pokud máte povolenou automatickou opravu plánu a ručně vynutíte plán, nikdy nebude automaticky zrušen. Pouze plány, které jsou vynuceny pomocí funkce Automatic Plan Correction, budou automaticky zrušeny.
Opravdu nechám SQL Server mít kontrolu?
Pokud jste skeptičtí a přemýšlíte, zda můžete opravdu důvěřovat SQL Serveru, že udělá rozhodnutí, které vyžaduje plán, doporučuji vám zapamatovat si následující:
- Tato funkce byla vyvinuta s ohromným množstvím dat zachycených z téměř dvou milionů Azure SQL Database. Je to nová funkce v SQL Server 2017, ale v roce 2016 se stala globální dostupností v Azure, takže tato funkce je skutečně dostupná déle než rok a byla vylepšena.
- Inženýři v průběhu času provedli změny v algoritmu, protože zachytili více dat. Nemusí najít každou regresi, která nastane – protože regrese nemusí být dostatečně závažná, ale vsadil bych se, že mnozí z vás by raději měli tuto vlastnost používat méně často než příliš často.
- Navíc, pokud je plán vynucen, ale nakonec způsobí problém, schopnost SQL Serveru se z toho zotavit a zrušit vynucení plánu je extrémně spolehlivá a probíhá velmi rychle.
Shrnutí
Možná vám nebude vyhovovat myšlenka, že SQL Server řeší problémy s výkonem za vás. Ale je to nepohodlí, protože si myslíte, že to bude špatné rozhodnutí? Nebo se obáváte, že vaši práci převezme automatizace? Docela přímá otázka, já vím. Pokud je to první, pak mým doporučením je podívat se na data zachycená v sys.dm_db_tuning_recommendations (bez povolení automatické opravy plánu) a zjistit, co by SQL Server chtěl dělat. Je to v souladu s tím, co byste dělali? Najde regrese, které byste mohli minout? Pokud tuto funkci nechcete aktivovat, protože se bojíte, že najednou nebudete mít dost práce, doporučuji vám přečíst si nedávný příspěvek Conora Cunninghama Jak rychlost cloudu pomáhá správcům databází SQL Serveru. Microsoft se vás nesnaží zbavit úlohy. Jednoduše se snaží zvládnout nízko visící ovoce, abyste se mohli soustředit na důležitější úkoly.