Ve svém posledním příspěvku „Více plánů pro „identický“ dotaz jsem mluvil o případu, kdy získáváte dva různé plány pro to, co si myslíte, že je stejný dotaz, a také o případu, kdy získáváte dvě kopie dotazu. stejné plán (a možná o tom ani nevím). Jak jsme tam zkoumali, „identický“ může být docela silné slovo.
Dalším scénářem, který vrhá lidi do smyčky, je případ, kdy obnoví databázi na jiný server – řekněme, obnoví produkční databázi na „identický“ testovací server – a získají různé výkonnostní charakteristiky nebo různé plány pro stejný dotaz (ne tentokrát citáty – opravdu mluvím o skutečně identických dotazech).
Jsou servery skutečně "identické"?
Tito kluci mohou vypadat podobně, ale nejsou zcela totožné. Pokud narazíte na tento scénář, první věc, kterou si musíte položit, je, zda jsou tyto dva servery skutečně totožné. Některé věci ke kontrole:
- Verze – Mnoho změn chování optimalizátoru a dotazů je prosazováno prostřednictvím aktualizací Service Pack a kumulativních aktualizací. Často jsem viděl lidi říkat:"No, oba jsou ročník 2008!" – když ve skutečnosti jeden byl 2008 a druhý 2008 R2, nebo byly na různých aktualizacích service pack nebo dokonce na úrovních kumulativních aktualizací. Protože mnoho lidí, kteří čtou @@VERSION, zaměňuje informace o aktualizaci service pack operačního systému za informace o aktualizaci service pack pro SQL Server, řekl bych, že je lepší následující:
SELECTSERVERPROPERTY(N'ProductVersion');Nemohu dostatečně zdůraznit důležitost použití přesně stejné verze k provedení skutečných testů jablek na jablka. Pokud používáte SQL Server 2012 nebo lepší, můžete se podívat na naše příspěvky sestavení (SQL Server 2012 | SQL Server 2014), abyste zjistili, jaký service pack nebo kumulativní aktualizace jsou potřebné, abyste se ujistili, že se verze shodují.
- Vydání – Doufejme, že na obou serverech používáte stejnou edici (nebo ekvivalentní, protože kromě licencování jsou Developer a Evaluation stejné jako Enterprise), neshody zde mohou vést k velmi odlišnému chování. Například různé edice mají různé výpočetní kapacity pro různé funkce a pak jsou tu jemnější věci, jako je možnost používat indexované zobrazení bez nápovědy NOEXPAND nebo provádět změny schématu nebo údržbu indexu online. Edice můžete porovnávat pomocí:
SELECTSERVERPROPERTY(N'Edition'); - Počet CPU – SQL Server rozhodně používá počet plánovačů, které jsou k dispozici během procesu vytváření prováděcího plánu, a nelze popřít, že počet jader může ovlivnit skutečný výkon za běhu (vynechme rychlost hodin, protože to je zřídka významný faktor v dotazu výkon). Neověřujte pouze počet jader fyzicky nainstalovaných na základním serveru, ale také zkontrolujte chybový protokol SQL Serveru pro počet CPU, které může SQL Server skutečně použít kvůli licencování. I když zapomeneme na hrubý počet jader, na systému NUMA mohou umělá omezení vést k velmi odlišným profilům výkonu. Další informace najdete v nedávném příspěvku Brenta Ozara „Proč je licencování založené na jádru důležité pro ladění výkonu“. Edice souvisí i zde, protože v SQL Server 2012 a 2014 může Standard Edition používat pouze 16 jader bez ohledu na to, jaká nastavení nebo fyzický hardware vás mohou vést k domněnce. Mezi další nastavení, která mohou ovlivnit výběr plánu na základě CPU a výkon odlišně, patří Resource Governor, MAXDOP pro celý server, afinita CPU a prahová hodnota nákladů pro paralelismus.
- Velikost paměti – Stejně jako CPU i optimalizátor vybírá plán na základě množství dostupné paměti. A stejně jako CPU nemluvím jen o množství paměti RAM nainstalované v systému, ale o množství paměti přidělené SQL Serveru a o tom, kolik skutečně využívá. Zkontrolujte nastavení maximální paměti serveru, ale také čítače výkonu pro celkovou a cílovou paměť a dokonce i DBCC MEMORYSTATUS. Mezi další věci, které si možná budete chtít prohlédnout, patří nastavení Resource Governor a Lock Pages in Memory. Existuje také nastavení, které, pokud se mezi dvěma servery liší, může mít významný vliv na to, jak velká část mezipaměti plánu se používá pro stejnou sadu dotazů:optimalizace pro zátěže ad hoc. Kimberly Tripp k tomu má skvělý příspěvek:Plánování mezipaměti a optimalizace pro adhoc zátěž. A konečně, pokud je server virtuální, uvědomte si, že zde může hrát roli prostředí – zvláště když nastavení paměti virtuálního počítače neodpovídá produkci nebo je dynamické.
- Vyrovnávací paměť / mezipaměť plánu – Když obnovujete databázi na testovacím serveru, je tu spousta věcí, které pro vás prostě nejsou hned připraveny. Fond vyrovnávacích pamětí neobsahuje žádná data, která mohla existovat na zdrojovém serveru – takže při prvním dotazu na data do paměti bude potřeba další I/O. A pokud je fond vyrovnávacích pamětí omezen jinak než produkce kvůli některým z výše uvedených faktorů, nemusí být možné dosáhnout stejných vzorců výkonu ani po vícenásobném spuštění dotazu – Paul White (@SQL_Kiwi) o tom mluví ve své odpovědi na Správci databáze. Také mezipaměť plánu nebude obsahovat žádný z plánů, které existovaly ve výrobě, takže přinejmenším – i když se nakonec zkompiluje stejný plán (což se nemusí stát kvůli jiným parametrům, než když byl plán sestaven na originálu). server) – budete mít dodatečné náklady na kompilaci. A ty se mohou změnit, pokud máte na svém místě také nějaké příznaky trasování ovlivňující plán.
- Diskový subsystém – I když rychlost a velikost používaných disků přímo neovlivní výběr plánu, rozhodně mohou ovlivnit pozorovaný výkon, což vás může přivést k zamyšlení, proč stejný dotaz se stejným plánem běží na jednom mnohem rychleji. systém než ten druhý. I/O je obvykle největším úzkým hrdlem SQL Serveru a je poměrně vzácné, že testovací server má skutečně stejný základní subsystém jako jeho produkční ekvivalent. Pokud tedy mezi těmito dvěma systémy vidíte rozdíly ve výkonu a plány a další hardwarové prvky jsou stejné, může být toto další nejlepší místo ke kontrole. A nezapomeňte, že od SQL Serveru 2014 může Resource Governor omezovat váš I/O výkon.
- Příznaky trasování – Zkontrolujte seznam globálních příznaků trasování nastavených na obou serverech; existuje několik, které mohou ovlivnit optimalizaci, chování plánu a vnímaný výkon, i když jsou všechna výše uvedená nastavení identická. Zde je 10 běžných a pozoruhodných z nich (ačkoli to rozhodně není doporučení zapnout kteroukoli z nich bez důkladného regresního testování):
Příznak Vysvětlení 2301 Donutí optimalizátor, aby strávil více času hledáním optimálního plánu. 2312 Vynutí nový odhad mohutnosti serveru SQL Server 2014. 2335 Způsobuje konzervativnější přidělení paměti. 2453 Vynutí OPTION (RECOMPILE) pro dotazy odkazující na proměnné tabulky. 2861 Umožňuje serveru SQL ukládat do mezipaměti triviální plány s nulovými náklady. 4136 Efektivně přidává OPTIMALIZOVAT PRO NEZNÁMÉ ke všem dotazům (aby se zmařilo sniffování parametrů). 4199 Deštník obsahující celou řadu oprav optimalizátoru. 8744 Zakáže předběžné načítání pro vnořené smyčky. 9481 Vypne nový odhad mohutnosti serveru SQL Server 2014.
Tento seznam příznaků trasování není v žádném případě vyčerpávající; existuje mnoho dalších, včetně těch bez dokumentů, o kterých jsem byl požádán, abych je nezmiňoval. Pokud používáte jiné, které nejsou uvedeny výše (a nedokážete vysvětlit proč), můžete najít vodítka v KB #920093, KB #2964518, Trace Flags (MSDN) nebo Trace Flags v SQL Server (TechNet). Některé cenné poznatky také najdete v různých příspěvcích Paula Whitea, buď zde, nebo na sql.kiwi. - Souběh – Pravděpodobně se testovací systém používá k jiným věcem, než které právě testujete. A pokud neprovádíte přehrávání nějakého druhu, má také pravděpodobně velmi odlišný profil zátěže. Tyto rozdíly v pracovní zátěži mohou mít samozřejmě přímý dopad na dostupnost zdrojů pro obsluhu požadavků, které testujete, a následně na vnímaný výkon těchto požadavků. Nezapomeňte zkontrolovat další služby, které nemusí existovat v produkci nebo existují, ale používají se různými způsoby (jako jsou Analysis Services, Reporting Services, Windows služby a dokonce i vaše vlastní aplikace). Naopak v produkci mohou být služby, jako je tato, které ovlivňují výkon, nebo další režie na samotné instanci, která není v testu napodobena:kromě skutečného produkčního zatížení myslete na věci, jako je trasování, rozšířené události, monitorování s vysokým dopadem, sledování změn, sběr dat změn, auditování, zprostředkovatel služeb, údržba indexu, úlohy zálohování, kontroly DBCC, zrcadlení, replikace, skupiny dostupnosti a seznam pokračuje dál a dál…
Jsou databáze stále "identické"?
Za předpokladu, že se všechny proměnné hardwaru a zátěže dostatečně shodují, může být stále náročné zajistit, aby databáze zůstaly stejné. Pokud provádíte zálohu/obnovu na testovacím systému, nová databáze začne jako identická se zdrojem (kromě fyzického umístění a zabezpečení). Ale jakmile se na něj začnete jakýmkoliv způsobem dotýkat, velmi rychle se odchýlí od produkční kopie, protože můžete provést některé nebo všechny následující:
- Změňte data, schéma nebo obojí.
- Neúmyslně spusťte automatickou aktualizaci statistik.
- Ručně přidávejte, defragmentujte nebo znovu sestavujte indexy nebo vytvářejte či aktualizujte statistiky.
- Změňte nastavení databáze, jako je úroveň kompatibility, úroveň izolace, vynucená parametrizace, selektivní indexy XML nebo kteroukoli z možností s názvem "Auto"-
. (Sakra, dokonce i umístění dat a souborů protokolu a nastavení růstu mohou ovlivnit výkon dotazů, a to včetně databáze tempdb.) - Vyprázdněte mezipaměť plánu, fond vyrovnávacích pamětí nebo obojí, přímo nebo jako vedlejší efekt jiných událostí (jako je RECONFIGURE nebo restart služby).
Jakmile začnete generovat nové plány dotazů, ještě předtím, než dojde k jakékoli z výše uvedených změn, musíte si pamatovat, že mohou být založeny na datech, která se liší od dat používaných ke generování plánů pro stejné dotazy v produkci. Například mohutnost v době, kdy byl plán sestaven ve výrobě, mohla být mezi tímto bodem a časem zálohování výrazně zkreslená, což znamená, že nový plán bude generován na základě různých statistik a informací z histogramu.
Tyto věci se ještě více rozcházejí, pokud se ve skutečnosti nejedná o nedávné obnovení – ale spíše o dvě schémata a datové sady, které udržujete synchronizované jinými způsoby (jako je ruční nasazení schémat a/nebo změn dat nebo dokonce replikace). Kvůli omezením místa na disku jste také možná vzali pouze podmnožinu produkčních dat nebo dokonce pouze klon statistik – tyto rozdíly v datech téměř jistě povedou k různým výkonnostním charakteristikám pro všechny dotazy kromě těch nejjednodušších, i když ano. hodně štěstí a s některými získejte stejné plány.
Jsou dotazy skutečně "identické"?
I když je vše výše uvedené, stále existují scénáře, kdy získáte jiný plán kvůli nastavení relace (můžete používat jinou kopii SSMS s jiným nastavením nebo úplně jiný klientský nástroj) nebo různá výchozí schémata ( můžete se například připojovat k testovacímu serveru jako jiné přihlašovací jméno pro Windows nebo SQL). Hodně jsem o těchto věcech mluvil ve svém předchozím příspěvku.
Závěr
I když existují způsoby, jak zmírnit některé rozdíly (podívejte se na DBCC OPTIMIZER_WHATIF pro oklamání vašeho testovacího serveru, aby uvěřil fenomenálním věcem o základním hardwaru), pravdou je, že bude velmi náročné zajistit, aby dva servery fungovaly spolehlivě a konzistentně identické. že existují potenciálně desítky důvodů, proč můžete získat různé plány nebo odlišný výkon na dvou podobných (nebo dokonce identických) serverech.
Máte nějaké konkrétní triky? Máte nějaké nesnesitelné bolesti s výše uvedenými myšlenkami (nebo jinými, které jsem zapomněl zmínit)? Podělte se prosím v komentářích níže!