it-swarm-eu.dev

Proč bych NEPOUŽÍVÁ možnost SQL Server „optimalizovat pro ad hoc pracovní zatížení“?

Četl jsem několik skvělých článků týkajících se ukládání do mezipaměti plánu serveru SQL od Kimberly Tripp, jako je tento: http://www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc -workloads /

Proč existuje dokonce možnost „optimalizace pro ad hoc pracovní vytížení“? Nemělo by to být vždy zapnuto? Ať už vývojáři používají ad-hoc SQL, nebo ne, proč byste neměli tuto možnost povolenou ve všech instancích, které ji podporují (SQL 2008+), čímž se sníží nadbytek mezipaměti?

50
SomeGuy

Vývojový tým serveru SQL Server pracuje na principu nejméně překvapení - takže server SQL Server má obecně nové funkce deaktivované v zájmu zachování chování jako předchozí verze.

Ano, optimalizace pro adhoc pracovní zátěž je skvělá při snižování nadbytku mezipaměti plánu - ale vždy to nejprve vyzkoušejte!

[Úpravy: Kalen Delaney vypráví zajímavou anekdotu, že se zeptala jednoho ze svých kolegů z inženýrů společnosti Microsoft, zda by existovaly okolnosti, za kterých by to nebylo vhodné. Vrátí se o několik dní později, aby řekl - představte si aplikaci, která má spoustu různých dotazů a každý dotaz běží celkem dvakrát celkem. Pak by to mohlo být nevhodné. Stačí říct, že takových aplikací není tolik!]

[Upravit: Pokud je většina vašich dotazů provedena více než jednou (ne přesně dvakrát); bylo by to pravděpodobně nevhodné. Obecným pravidlem by bylo, kdyby se v databázi objevilo mnoho jednorázových adhoc dotazů; stále však není mnoho takových aplikací.]

46
Peter Schofield

Níže je uveden malý kód, který vám pomůže rozhodnout, zda bude „přepínání optimalizováno pro ad hoc pracovní zatížení ZAP/VYP“ prospěšné nebo ne. Normálně to kontrolujeme jako součást naší kontroly stavu u vlastních a klientských serverů.

Je to nejbezpečnější možnost, kterou povolit a je dobře popsán Bradem zde a Glenn Berry zde .

--- for 2008 and up .. Optimize ad-hoc for workload 
IF EXISTS (
        -- this is for 2008 and up
        SELECT 1
        FROM sys.configurations
        WHERE NAME = 'optimize for ad hoc workloads'
        )
BEGIN
    DECLARE @AdHocSizeInMB DECIMAL(14, 2)
        ,@TotalSizeInMB DECIMAL(14, 2)
        ,@ObjType NVARCHAR(34)

    SELECT @AdHocSizeInMB = SUM(CAST((
                    CASE 
                        WHEN usecounts = 1
                            AND LOWER(objtype) = 'adhoc'
                            THEN size_in_bytes
                        ELSE 0
                        END
                    ) AS DECIMAL(14, 2))) / 1048576
        ,@TotalSizeInMB = SUM(CAST(size_in_bytes AS DECIMAL(14, 2))) / 1048576
    FROM sys.dm_exec_cached_plans

    SELECT 'SQL Server Configuration' AS GROUP_TYPE
        ,' Total cache plan size (MB): ' + cast(@TotalSizeInMB AS VARCHAR(max)) + '. Current memory occupied by adhoc plans only used once (MB):' + cast(@AdHocSizeInMB AS VARCHAR(max)) + '.  Percentage of total cache plan occupied by adhoc plans only used once :' + cast(CAST((@AdHocSizeInMB / @TotalSizeInMB) * 100 AS DECIMAL(14, 2)) AS VARCHAR(max)) + '%' + ' ' AS COMMENTS
        ,' ' + CASE 
            WHEN @AdHocSizeInMB > 200
                OR ((@AdHocSizeInMB / @TotalSizeInMB) * 100) > 25 -- 200MB or > 25%
                THEN 'Switch on Optimize for ad hoc workloads as it will make a significant difference. Ref: http://sqlserverperformance.idera.com/memory/optimize-ad-hoc-workloads-option-sql-server-2008/. http://www.sqlskills.com/blogs/kimberly/post/procedure-cache-and-optimizing-for-adhoc-workloads.aspx'
            ELSE 'Setting Optimize for ad hoc workloads will make little difference !!'
            END + ' ' AS RECOMMENDATIONS
END
21
Kin Shah

Myslete na produkční server, který obsluhuje pouze 5 různých dotazů, ale několik tisíc z nich za sekundu. Jste vývojový tým Microsoft SQL Server. Chystáte se pohrávat s plánováním mezipaměti. Zapínáte toto chování ve výchozím nastavení, když víte, že někteří z vašich největších a nejkritičtějších klientů (např. Interní implementace společnosti Microsoft od společnosti Microsoft) pracují ve stejném kampusu a používají stejnou jídelnu jako vy?

7
Stu

Když zapnete možnost „ Optimize for Ad Hoc Workloads “, způsobíte, že dotazy ad hoc, které jsou spuštěny podruhé, budou stejně pomalé jako první, protože bude kompilovat prováděcí plán a tahat stejná data (bez mezipaměti) těch prvních 2krát.
To nemusí být velký problém, ale při testování dotazů si to všimnete.
Takže co se stane nyní, bez , tato volba byla zapnuta a mezipaměť plná Jednorázové dotazy Ad-Hoc?

Algoritmus správy mezipaměti:

Po zavedení této funkce optimalizace byl také aktualizován algoritmus správy mezipaměti.
Článek Kimberly Tripp také uvádí Kalen Delaneyův příspěvek o této změně algoritmu.
Vysvětluje to nejlépe:

Změna skutečně vypočítá velikost mezipaměti plánu, při níž SQL Server rozpozná, že existuje tlak paměti, a začne odstraňovat plány z mezipaměti. Plány, které mají být odstraněny, jsou levné plány, které nebyly znovu použity, a to je DOBRÁ VĚC.

To znamená, že ty otravné plány s časovačem budou jako první, když potřebujete uvolnit zdroje.

Teď se otázka stává:

" Proč POTŘEBUJEME 'Optimalizovat pro pracovní zátěž Ad Hoc', když se SQL Server postará o odstranění nevyužitých plánů, když je to nutné? "

Moje odpověď na to je, že pokud pravidelně máte s-tunu dynamických sql generujících oodles ne-parametrizovaných ad-hoc dotazů, pak má smysl tuto funkci zapnout.
Chcete se vyvarovat zatěžování systémových prostředků tak, že po vyčerpání maximálního prostoru v mezipaměti vynutí vynucení plánu mezipaměti/odstranění dat.

Jak zjistím, kdy to musím zapnout?

Zde je dotaz, který jsem vám napsal, abych vám ukázal, kolik plánů Ad-Hoc máte v současné době v mezipaměti a kolik místa na disku zabírají (výsledky se během dne změní - takže si je vyzkoušejte v době velkého zatížení):

--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
       S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
       CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
       S.Total_MB_1_Use,   S.Total_MB,
       CAST( (S.Total_MB_1_Use   * 1.0 / S.Total_MB  ) as Decimal(18,2) )[Pct_MB_1_Use]
  FROM
  (
    SELECT CP.objtype[CacheType],
           COUNT(*)[Total_Plan],
           SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
           SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
           SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
           CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
           CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
                      / 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
           CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
           CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
                         ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
      FROM sys.dm_exec_cached_plans as CP
     GROUP BY CP.objtype
  ) AS S
 ORDER BY S.CacheType

Výsledek: enter image description here

Nebudu říkat, " Když máte X MB " nebo " Pokud je X% vašeho Ad Hoc na jedno použití ", zapněte to.
Neovlivňuje Sprocs, Triggers, Views nebo Parametrized/Ready SQL - pouze dotazy Ad-Hoc.
Mým osobním doporučením je zapnout se ve vašem Prod prostředí, ale zvažte jeho ponechání ve vašem Dev prostředí.
Říkám to pouze pro Dev, protože pokud optimalizujete dotaz, který trvá minutu nebo déle, pak jej nechcete spustit. 3krát předtím, než uvidíte, jak rychle to bude s tím v mezipaměti - pokaždé jednou upravte jej, abyste našli nejlepší návrh optimalizace.
Pokud to vaše práce nezahrnuje dělat celý den, pak jděte do ořechů a požádejte svého DBA, aby ho všude zapnul.

7
MikeTeeVee

„Proč bych NEMĚLA používat ...“ V průběhu některých vyšetřování výkonu může být velmi užitečné vytažení plánů z mezipaměti plánu v reálném čase, zatímco pozorování využití zdrojů může být velmi užitečné. Funkce „Optimize for adhoc workloads“ to může narušit, protože plány adhoc stub nevracejí plán při dotazování do mezipaměti. V takovém případě, pokud dotaz a plán nelze jinak identifikovat, lze nastavení pro účely šetření vypnout a znovu zapnout. Všimněte si, že od této chvíle se kompilovala změna v nastavení efektů. Při každé změně vlastnosti 'serveru' také zkontrolujte, zda není instancí prodána ve stejné verzi, abyste ověřili, zda změna vyprázdní mezipaměť plánu. Osobně nenávidím, že jsem tím překvapen. (Například změna maxdop na úrovni serveru obvykle vyprázdní mezipaměť plánu, zatímco změna dop v nástroji Resource Governor ne.)

"Zkompilovaný plánovaný blok nemá přidružený plán provádění a dotazování na popisovač plánu nevrátí XML Showplan." http://technet.Microsoft.com/en-us/library/cc645587.aspx

0
sql_handle