sql >> Databáze >  >> RDS >> Sqlserver

Proč je ladění výkonu SQL nejdůležitější dovedností správy databází

Proč je ladění výkonu SQL tak důležité pro správu databází?

Protože vám to může hodně ušetřit peníze. Vydržte se mnou a uvidíte jak.

Ladění výkonu SQL a správa databáze – spojování bodů

Většina databázových profesionálů tráví čas rozsvícením světel. Většinu svého úsilí investují do zajištění provozuschopnosti tím, že dohlížejí na zdroje, jako je paměť, úložiště a propustnost sítě. To je velká část správy databází, ale jak stále více společností přesouvá své databáze do téměř neomezených cloudových zdrojů, jako jsou AWS a Azure, další aspekty se stávají důležitějšími.

Ladění výkonu SQL je jedním z těchto aspektů. Jakmile budou kontrolky bezpečně svítit a posunete se v hierarchii potřeb ve správě databází, další věc, kterou chcete, je lepší výkon, a to vyžaduje ladění.

První otázky při ladění výkonu v SQL

Dříve nebo později se mnoho databázových profesionálů ocitne před SQL Serverem, který nevytvořili. Neexistuje mnoho návodů, jak na tuto situaci. Ladění výkonu SQL je cvičení, jak se v tom ponořit, zjistit, co je špatně, a pak to iterativně opravit.

Ve vašich prvních opravách se nemusíte příkazů SQL vůbec dotknout. Někteří databázoví profesionálové začínají na úrovni uživatele/relace. Jdou tam, kde jsou uživatelé nešťastní, poslouchají, jak zní jejich stížnosti, a kladou otázky.

  • Které obrazovky nebo stránky se vykreslují příliš dlouho?
  • Je aplikace pomalejší, když vytváří nový lístek nebo otevírá existující?
  • Trvá uložení záznamu dlouho?
  • Jak dlouho je „dlouhá doba?“

Jakmile budou mít tyto odpovědi, půjdou se podívat, co to v databázi způsobuje.

Je to lepší, než si první den sednout a rozhodnout se řešit něco jako fragmentace, která nemusí mít na uživatele vůbec vliv. Smyslem je začít tím, co uživatele zajímá.

Myslete také na úroveň instance/databáze. Ve světě Microsoftu jsou například úlohy SQL Server Agent dobrým místem, kde začít. Jedná se o sérii akcí, které obvykle definují administrativní úlohu, u které můžete sledovat úspěch nebo neúspěch. Mají být pohodlné, ale jako mnoho věcí ve správě databází mají tendenci se hromadit, když lidé zapomínají, jak vznikly a co dělají.

Můžete najít několik úloh, které dělají totéž, jako je spouštění různých verzí indexového skriptu nebo, což je ještě horší, fungující proti sobě. Prozkoumejte již nakonfigurované úlohy ve světle dvou otázek:"Co tato práce dělá?" a co je důležitější:„Když tu práci zastavím, stane se něco špatného?“

Jaké faktory byste měli hledat?

Jakmile se dostanete na úroveň ladění výkonu SQL, vezme si vodítko pro chování z několika faktorů. Jak bylo popsáno během našeho webového vysílání Ask the Experts:Database Performance Roundtable , můžete strávit méně času laděním samotného SQL, pokud najdete a správně interpretujete faktory, jako jsou tyto:

  • Blokování —  Pokud server blokuje, je to jako časovaná bomba. Předpokládejme, že skript zahájí transakci a neuzavře ji; to by mohlo vést k souboru protokolu, který se jen zvětšuje a roste, dokud nedojde místo. Blokování je špatnou zprávou pro výkon, takže ho hned hledejte.
  • Agenti —  V souvislosti s úlohami SQL Server Agent je známo, že správci neúmyslně zabalují úlohy snižující výkon do úloh. Mohou provádět transakce nebo přestavět indexy v úloze nebo zmenšit databázi v transakci. V takovém případě zvažte dočasné zakázání agenta, abyste ukončili všechny související úlohy. Je to agresivní technika, ale pokud zlepší výkon, budete vědět proč.
  • Statistiky čekání —  Zeptejte se sami sebe:"Na co server právě čeká?" Metriky jako očekávaná životnost stránky a délka diskové fronty mají určité odpovědi, ale nabízejí pouze úzký pohled. Statistiky čekání vám vše ukazují optikou typů čekání a kategorií čekání, takže se můžete soustředit na přibližně pět událostí čekání, které zaberou nejvíce času. Sp_BlitzFirst Brenta Ozara je dobře důvěryhodná uložená procedura pro zjištění, na co vaše dotazy SQL Server právě čekají. Až budete chtít studovat dlouhodobé vzorce ve statistikách čekání pro váš server, podívejte se na nástroj pro sledování výkonu.
  • Činnost správce —  To je také známé jako „chyba pilota“, protože některé problémy s výkonem vznikají z toho, co děláte vy sami. Předpokládejme, že současně používáte SQL Server Activity Monitor a SQL Server Profiler a pokoušíte se naučit Query Store. Nemůžete překonat efekt pozorovatele; když všechno takhle sledujete, jen žádáte o zpomalení databáze.
  • Indexy —  U něčeho, co by mělo být prospěšné, vám indexy jistě mohou způsobit bolest v krku. Ve skutečnosti si zaslouží víc než jen jednu kulku. Čtěte dále.

Ladění výkonu SQL znamená podrobný pohled na indexy

Ladění výkonu SQL se z velké části scvrkává na ladění indexu. Naštěstí, pokud si osvojíte místní správu databází, budou vaše dovednosti snadno přenositelné do správy databází v cloudu.

Ladění indexů nabývá na důležitosti kvůli vyvíjející se řadě indexů: shlukovaný, neseskupený, jedinečný, filtrovaný, sloupcový, hash, neklastrovaný s optimalizovanou pamětí, XML, prostorový a fulltextový, abychom jmenovali alespoň některé. Ale jedna věc, která se nikdy nezměnila, je první sloupec indexu, který řídí rozhodnutí o indexu prováděná databázovým strojem.

Mnoho dodavatelů prodává a nasazuje aplikace se spoustou dobře zamýšlených indexů, které se nakonec nikdy nepoužijí, nebo, což je ještě horší, skutečně omezují výkon. Pokud prozkoumáte nepoužívané indexové skripty nebo skripty spotřeby indexu v některých softwarových produktech, zjistíte přebytek indexů na cizím klíči. Pokud produkt používá řekněme 20 cizích klíčů, mohou dodavatelé dodat až 20 indexů plus deset jednosloupcových indexů plus dalších deset indexů na jedinečném seskupeném indexu a tak dále.

Kdykoli máte možnost, lepší způsob, jak přistupovat k architektuře databáze, je začít s jedním seskupeným indexem, o kterém si myslíte, že bude nejlépe reprezentovat tabulku. Poté nechte systém chvíli běžet sám. Pokud a jak potřebujete více indexů, vytvořte je. Přidávání indexů je cvičením, jak zde vyměňovat lepší výkon s problémy, jako je zaplnění místa na disku a zamykání tam. Je těžké vidět, jak každý další index celkově ovlivňuje systém.

V tomto případě zvažte odstranění indexů – způsob, jakým by alergici eliminovali skupiny potravin – abyste viděli, jak se změní výkon. Zkuste vypustit každý index ve vaší instanci vývojáře a zjistěte, které z nich ovlivňují vašich pět nejčastějších dotazů.

Ladění výkonu na serveru SQL Server – nástroje, které jsou s ním dodávány

Všimněte si, že v tomto úsilí nejste sami. SQL Server obsahuje funkce navržené ke zlepšení výkonu.

Průvodci plánem vám umožňují změnit způsob, jakým SQL Server spouští daný dotaz, a přestože se nejedná o čistě ladění výkonu SQL, má to vliv na výkon. Mnoho aplikací obsahuje dotazy SQL napsané externím dodavatelem, a i když tyto dotazy způsobují špatný výkon, někteří databázoví odborníci se pochopitelně zdráhají je měnit. Pomocí průvodců plánem můžete k dotazu připojit nápovědu k dotazu nebo pevný plán a ovlivnit, jak bude probíhat.

Nevýhodou plánů je však to, že ačkoli se v průběhu času nemění, prostředí kolem nich se mění. Podobně jako tištěná cestovní mapa mohou krátkodobě dobře fungovat a zanedlouho zastarají, takže pokud se na ně chcete spolehnout, měli byste je občas znovu navštívit.

S průvodci plánováním souvisí Query Store, funkce serveru SQL Server, která vám pomůže identifikovat a vyladit dotazy, které spotřebovávají nejvíce prostředků ve vašem systému. Query Store není ve výchozím nastavení povoleno pro nové databáze SQL Server a Azure Synapse Analytics (SQL DW). Ve výchozím nastavení je však v nových Azure SQL Databases povolena.

Obecně není těžké povolit Query Store, ale ne každý SQL Server to od začátku potřebuje. Někteří správci o Query Store nevědí a někteří o něm vědí, ale ještě si nenašli čas, aby ho adekvátně prozkoumali; raději to nechají deaktivované. Později, když pochopí, jak Query Store funguje, mohou jej použít k nalezení rozdílů ve výkonu způsobených změnami plánu dotazů.

Nakonec nástroj Databázový nástroj Tuning Advisor analyzuje pracovní zatížení a doporučí indexy nebo strategie dělení ke zlepšení výkonu dotazů. Spuštění nástroje Tuning Advisor ve vaší databázi je dobrý nápad; jen to nespouštěj příliš brzy. Ujistěte se, že vaše databáze obsahuje dostatek dat, aby doporučení indexu byla platná. Když poprvé vytváříte aplikaci, můžete mít v každé tabulce pouze tisíc řádků. Doporučení Tuning Advisor jsou užitečnější, jakmile se databáze rozroste.

Ukažte mi peníze

Jak jsem zmínil na začátku, ladění výkonu SQL je důležité pro správu databází, protože vám může ušetřit peníze. Jak?

Zejména v cloudu, kde je škálování pomocí kreditních karet populární, IT týmy zjišťují, jak drahé měsíční úložiště skutečně může být. A co víc, začínají chápat, že spouštění špatně napsaných dotazů a ponechání AWS a Azure spravovat jejich indexy zvyšuje jejich náklady na cloud computing. Pomalé dotazy a špatné indexy vás stojí peníze.

Při ladění výkonu SQL jde o to, aby byly všechny tyto věci správně. Tímto způsobem, ať už zůstanete ve světě on-premise OpEx nebo migrujete do světa CapEx v cloudu, budete mít kontrolu nad svými výdaji.


  1. mysql zkontrolujte, zda jsou čísla v seznamu oddělených čárkami

  2. Instalace R12.2.6 EBS krok za krokem na Virtual Box část -2

  3. Příkaz SQL INSERT INTO

  4. Transparent Data Encryption (TDE) na serveru SQL Server ve skupině AlwaysOn Availability na příkladu