Pokračování na Summer Performance Palooza 2013

Dne 27. června uspořádala virtuální pobočka PASS Performance své letní představení Palooza 2013 – jakési zmenšené 24 hodin PASS, ale zaměřené výhradně na témata související s výkonem. Měl jsem relaci s názvem „10 špatných návyků, které mohou zabít výkon“ a zabýval jsem se těmito 10 koncepty:

1. VYBRAT *
2. Slepé indexy
3. Žádná předpona schématu
4. Výchozí možnosti kurzoru
5. předpona sp_
6. Povolení přeplnění mezipaměti
7. Široké datové typy
8. Výchozí nastavení serveru SQL
9. Nadměrné používání funkcí
10. „Funguje na mém počítači“

Možná si některá z těchto témat pamatujete z prezentací, jako je moje přednáška „Špatné návyky a osvědčené postupy“ nebo naše týdenní webináře Query Tuning, které pořádám s Kevinem Klinem od začátku června do tohoto týdne. (Mimochodem, těchto 6 videí bude na YouTube k dispozici začátkem srpna.)

Moje sezení mělo 351 účastníků a dostal jsem skvělou zpětnou vazbu. Něco z toho jsem chtěl řešit.

Za prvé, problém s konfigurací:používal jsem zcela nový mikrofon a netušil jsem, že každé stisknutí klávesy bude znít jako hrom. Tento problém jsem vyřešil lepším umístěním svých periferií, ale chci se omluvit všem, kterých se to týká.

Dále stahování; paluba a vzorky jsou umístěny na místě akce. Jsou dole na stránce, ale můžete si je také stáhnout přímo zde.

Nakonec, co následuje, je seznam otázek, které byly položeny během relace, a chtěl jsem se ujistit, že jsem odpověděl na všechny, které nebyly zodpovězeny během živých Q &A. Omlouvám se, že jsem to vtěsnal za necelý měsíc , ale byly hodně otázek a nechtěl jsem je zveřejňovat po částech.

A: Budete k tomu muset přistupovat případ od případu, protože to bude skutečně záviset na řadě faktorů (včetně složitosti plánu). Všimněte si také, že můžete provést rekompilaci na úrovni příkazů tak, že pouze dotčené příkazy musí přijmout přístup, na rozdíl od celého modulu. Paul White mi připomněl, že lidé často „opravují“ sniffování parametrů pomocí RECOMPILE , ale příliš často to znamená 2000-styl WITH RECOMPILE spíše než mnohem lepší OPTION (RECOMPILE) , který se nejen omezuje na příkaz, ale také umožňuje vkládání parametrů, které WITH RECOMPILE ne. Pokud se tedy chystáte použít RECOMPILE Chcete-li zmařit sniffování parametrů, přidejte jej do příkazu, nikoli do modulu.

A: Jak je uvedeno výše, bude to záviset na nákladech a složitosti plánů a neexistuje způsob, jak říci:"Ano, vždy bude velký výkon." Také to musíte porovnat s alternativou.

A: Nejsem si jistý, co znamená „čitelný v reálném světě“. Pokud chcete výstup v určitém formátu, obvykle je lepší převod na řetězec na straně klienta. C# a většina dalších jazyků, které pravděpodobně používáte v prezentační vrstvě, jsou více než schopné formátovat výstup data/času z databáze v jakémkoli regionálním formátu, který chcete.

A: Většina DMV je platná pouze od posledního spuštění služby a dokonce i další lze proplachovat častěji (dokonce i na vyžádání – nechtěně i záměrně). Mezipaměť plánu se samozřejmě neustále mění a plány AFAIK, které z mezipaměti vypadnou, si nezachovají svůj předchozí počet, pokud se objeví zpět. Takže i když v mezipaměti vidíte plán, nejsem 100% s jistotou, že můžete věřit počtu použití, který najdete.

To znamená, že to, co pravděpodobně hledáte, je sys.dm_exec_cached_plans.usecounts a můžete také najít sys.dm_exec_procedure_stats.execution_count pro doplnění informací o procedurách, kde jednotlivé příkazy v rámci procedur nejsou nalezeny v mezipaměti.

A: Hlavní obavy kolem toho jsou schopnost používat určitou syntaxi, jako je OUTER APPLY nebo proměnné s tabulkovou funkcí. Nejsem si vědom žádných případů, kdy by použití nižší kompatibility mělo přímý dopad na výkon, ale několik věcí, které se obvykle doporučuje, je znovu sestavit indexy a aktualizovat statistiky (a přimět vašeho dodavatele, aby co nejdříve podporoval novější úroveň kompatibility). Viděl jsem, že to řeší neočekávané snížení výkonu ve značném počtu případů, ale také jsem slyšel názory, že to není nutné a možná dokonce nemoudré.

A: Ne, alespoň pokud jde o výkon, jedna výjimka, kde SELECT * nezáleží na tom, je-li použit uvnitř EXISTS doložka. Ale proč byste měli používat * tady? Dávám přednost použití EXISTS (SELECT 1 ... – optimalizátor s nimi bude zacházet stejně, ale svým způsobem sám zdokumentuje kód a zajistí, aby čtenáři pochopili, že poddotaz nevrací žádná data (i když jim chybí velký EXISTS mimo). Někteří lidé používají NULL , a nemám ponětí, proč jsem začal používat 1, ale nacházím NULL také trochu neintuitivní.

*Poznámka* budete muset být opatrní, pokud se pokusíte použít EXISTS (SELECT * uvnitř modulu, který je vázaný na schéma:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Zobrazí se tato chyba:

Změňte jej však na SELECT 1 funguje v pohodě. Možná je to další argument, proč se vyhnout SELECT * i v tomto scénáři.

A: V různých jazycích jsou pravděpodobně stovky. Stejně jako konvence pojmenování jsou standardy kódování velmi subjektivní věcí. Nezáleží na tom, jaká konvence se rozhodnete nejlépe pro vás; pokud máte rádi tbl předpony, zbláznit se! Upřednostňujte Pascala před bigEndianem. Chcete před názvy sloupců přidat typ dat, například intCustomerID , nebudu ti v tom bránit. Důležitější je, abyste definovali konvenci a používali ji *konzistentně.*

To znamená, že pokud chcete mé názory, nemám o ně nouzi.

A: Nevím o žádných plánech na ukončení podpory XACT_ABORT takže by to mělo fungovat dobře. Upřímně řečeno, nevidím, že se to teď používá příliš často, když máme TRY / CATCH (a THROW od SQL Server 2012).

A: Netestoval jsem to, ale v mnoha případech může mít nahrazení skalární funkce funkcí s inline tabulkovou hodnotou velký dopad na výkon. Problém, který jsem zjistil, je, že provedení tohoto přepnutí může znamenat značné množství práce na systému, který byl napsán před APPLY existovaly nebo jsou stále spravovány lidmi, kteří tento lepší přístup nepřijali.

A: Napadají mě dvě věci:(1) zpoždění souvisí s dobou kompilace nebo (2) zpoždění souvisí s množstvím dat, která se načítají pro uspokojení dotazu, a když poprvé musí přijít z disku. a ne paměť. Pro (1) můžete provést dotaz v SQL Sentry Plan Explorer a stavový řádek vám ukáže čas kompilace pro první a následující vyvolání (ačkoli minuta se zdá být v tomto případě poněkud přehnaná a nepravděpodobná). Pokud nenajdete žádný rozdíl, může to být jen povaha systému:nedostatečná paměť pro podporu množství dat, které se pokoušíte načíst pomocí tohoto dotazu, v kombinaci s jinými daty, která již byla ve fondu vyrovnávacích pamětí. Pokud nevěříte, že by se jednalo o problém, zjistěte, zda dvě různá provedení skutečně dávají různé plány – pokud existují nějaké rozdíly, zveřejněte plány na answer.sqlperformance.com a my se rádi podíváme . Ve skutečnosti zachycování skutečných plánů pro obě provedení pomocí Průzkumníka plánů vás v každém případě může také informovat o jakýchkoli rozdílech v I/O a může vést k tomu, že SQL Server tráví čas při prvním, pomalejším běhu.

A: Ne, nemyslím si, že nastavení Optimalizovat pro ad hoc zátěž tomuto scénáři pomůže, protože sniffování parametrů znamená, že následná provedení stejného plánu jsou použita pro různé parametry a s výrazně odlišným chováním při výkonu. Optimalizace pro zátěže ad hoc se používá k minimalizaci drastického dopadu na mezipaměť plánu, ke kterému může dojít, když máte vysoký počet různých příkazů SQL. Pokud tedy nemluvíte o dopadu mnoha různých příkazů na mezipaměť plánu, které posíláte do sp_executesql – což by nebylo charakterizováno jako sniffování parametrů – myslím, že experimentování s OPTION (RECOMPILE) může mít lepší výsledek, nebo pokud znáte hodnoty parametrů, které *produkují* dobré výsledky v různých kombinacích parametrů, použijte OPTIMIZE FOR . Tato odpověď od Paula Whitea může poskytnout mnohem lepší přehled.

A: Jistě, stačí zahrnout OPTION (RECOMPILE) v dynamickém textu SQL:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Výsledky:1 řádek zobrazující Sales.SalesOrderHeader dotaz.

Nyní, pokud některý příkaz v dávce NEOBSAHUJE OPTION (RECOMPILE) , plán může být stále uložen do mezipaměti, jen jej nelze znovu použít.

DBCC FREEPROCCACHE(0x06.....);