it-swarm-eu.dev

Proč by SET ARITHABORT ON dramaticky urychlil dotaz?

Dotaz je jediný výběr obsahující mnoho úrovní seskupení a přitěžujících operací. S SET ARITHABORT ON trvá méně než sekundu, jinak to trvá několik minut. Toto chování jsme viděli na serverech SQL Server 2000 a 2008.

79
Jonathan Allen

Trochu starý, ale pro kohokoli, kdo tady skončí s podobným problémem ...

Měl jsem stejný problém. Pro mě se ukázalo, že se jedná o parametrické čichání, které jsem zpočátku nechápal dost, abych se o to postaral. Přidal jsem „zapnutou aritmetiku“, která problém vyřešila, ale pak se vrátila. Pak jsem četl:

http://www.sommarskog.se/query-plan-mysteries.html

Vyčistilo to všechno. Protože jsem použil Linq k SQL a měl jsem omezené možnosti k vyřešení problému, skončil jsem pomocí průvodce plánem dotazů (viz konec odkazu), abych vynutil plán dotazů, který jsem chtěl.

63
Jason

Aplikace .NET se ve výchozím nastavení připojují k zakázané možnosti, ve výchozím nastavení je však povolena v Management Studio. Výsledkem je, že server ve skutečnosti ukládá 2 samostatné plány provádění pro většinu/všechny postupy. To má vliv na to, jak server provádí numerické výpočty a jako takový můžete získat velmi odlišné výsledky v závislosti na postupu. To je opravdu jen jeden ze 2 běžných způsobů, jak může proc dostat strašlivý plán provádění, druhým je parametr čichání.

Podívejte se na https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored- Procedure-Performance.aspx pro trochu více diskuse o tom.

30
Ben Hoffman

Tvrdil bych, že to bylo téměř jistě šňupání parametrů.

Často se uvádí, že SET OPTIONS může ovlivnit výkon tímto způsobem, ale zatím pro tento požadavek nevidím jediný autoritativní zdroj s výjimkou případu, kdy používáte indexovaná zobrazení/přetrvávající vypočítané sloupce.

V tomto případě (pro SQL2005 + a pokud vaše databáze není v režimu kompatibility SQL20 ). Pokud máte oba ARITHABORT a ANSI_WARNINGSOFF pak zjistíte, že index není používán, takže může mít prohledávání spíše než požadované vyhledávání (a některé režie, protože nelze použít trvalý výsledek výpočtu). Zdá se, že ADO.NET má výchozí hodnotu ANSI_WARNINGS ON z rychlého testu, který jsem právě udělal.

Tvrzení v Benově odpovědi , že „způsob, jakým server provádí numerické výpočty“, může přidat výsledek k výsledku, který by jinak trval méně než sekundu, se mi nezdá věrohodné. Myslím, že to, co se obvykle stává, je to, že po prozkoumání problému s výkonem se Profiler používá k identifikaci problematického dotazu. To se vloží do manažerského studia a okamžitě se spustí a vrátí výsledky. Jediný zjevný rozdíl mezi připojeními je ARITH_ABORT možnost.

Rychlý test v okně manažerského studia ukazuje, že když SET ARITHABORT OFF je zapnuto a je spuštěn dotaz, který opakuje problém s výkonem, takže je zjevně uzavřen případ. Zdá se, že se jedná o metodologii odstraňování problémů používanou v odkazu Gregg Stark .

To však ignoruje skutečnost, že s touto sadou možností můžete nakonec získat stejný špatný plán z mezipaměti .

Toto opětovné použití plánu může nastat, i když jste přihlášeni jako jiný uživatel, než používá připojení aplikace.

Testoval jsem to provedením testovacího dotazu nejprve z webové aplikace, poté z manažerského studia s SET ARITHABORT OFF a viděli uživatelské účty vycházející z níže uvedeného dotazu.

SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 

Aby toto sdílení sdílených plánů skutečně nastalo, musí být všechny klíče mezipaměti plánu stejné. Stejně jako samotné arithabort, některé další příklady jsou prováděcí uživatelé, kteří potřebují stejné výchozí schéma (pokud se dotaz spoléhá na implicitní rozlišení jmen) a připojení vyžadují stejnou sadu language.

Úplnější seznam klíčů mezipaměti plánu zde

21
Martin Smith

Vím, že jsem na tuto párty pozdě, ale pro budoucí návštěvníky je Martin přesně správný. Setkali jsme se se stejným problémem - SP běžel velmi pomalu pro klienty .NET, zatímco to rychle žhnulo pro SSMS. Při zkoumání a řešení problému jsme provedli systematické testování, které Kenny Evitt se ve svém komentáři k Martinově otázce ptá.

Pomocí varianty Martinova dotazu jsem v mezipaměti procedury hledal SP) a našel jsem dva. Při pohledu na plány bylo ve skutečnosti případ, že jeden měl ARITHABORT ON a druhý měl ARITHABORT OFF Verze ARITHABORT OFF měla hledání indexu, zatímco verze ARITHABORT ON použila pro stejný výstup skenování indexu. Vzhledem k zahrnutým parametrům by hledání indexu vyžadovalo vyhledávání desítek milionů záznamů pro výstup.

Vymazal jsem tyto dva postupy z mezipaměti a nechal klienta .NET znovu spustit SP, s použitím stejných parametrů (které představovaly široké časové období pro zákazníka se spoustou aktivity). SP okamžitě vráceno. Plán v mezipaměti použil stejné skenování indexu, jaké bylo dříve uvedeno v plánu ARITHABORT ON - tentokrát však byl plán na ARITHABORT OFF. Spustili jsme SP se stejnými parametry v SSMS a znovu jsme dostali výsledky okamžitě. Nyní jsme viděli, že byl pro ARITHABORT ON se skenováním indexu uložen druhý plán.

Poté jsme vyčistili mezipaměť, spustili SP v SSMS s úzkým časovým obdobím a dostali okamžitý výsledek. Zjistili jsme, že výsledný plán v mezipaměti měl hledání indexu, pro stejný výstup byl předtím zpracován se skenováním (což bylo také hledat v původním plánu s ARITHABORT OFF). Opět ze SSMS jsme spustili SP, tentokrát se stejným širokým časovým obdobím, a viděli jsme stejný strašný výkon, jaký jsme měli v původním požadavku .NET. .

Stručně řečeno, disparita neměla nic společného se skutečnou hodnotou ARITHABORTu - s tím, co bylo zapnuto nebo vypnuto, od kteréhokoli klienta, jsme mohli získat přijatelný nebo hrozný výkon: Vše, na čem záleželo, byly hodnoty parametrů použité při kompilaci a ukládání do mezipaměti plánu.

Zatímco MSDN naznačuje, že ARITHABORT OFF může mít negativní dopad na optimalizaci dotazů, naše testování potvrzuje, že Martin je v pořádku - příčinou bylo vyčichávání parametrů a výsledný plán není optimální pro všechny rozsahy parametrů.

13
mdoyle

Právě měl tento problém. Jak zde lidé říkali, hlavní příčinou jsou více plánů dotazů, z nichž jeden není optimální. Chtěl jsem jen ověřit, že ARITHABORT může problém skutečně způsobit sám (protože dotaz, který jsem měl, neměl problémy, neměl žádné parametry, což z parametru odstraňuje parametry).

1
Alan D. Nelson

To mi připomíná stejný problém, jaký jsem zažil na serveru SQL Server 2008 dnů. V našem případě jsme najednou zjistili, že jedna úloha sql se náhle zpomalila (obvykle několik sekund a nyní 9+ minut), úloha potřebuje přístup k propojenému serveru, přidali jsme sadu ARITHABORT v kroku úlohy a zdálo se, že problém byl vyřešen na několik dní a pak se vrátil.

Později jsme otevřeli lístek s podporou MS, a zpočátku to nemohli zjistit ani, a lístek byl eskalován do velmi nadřízeného týmu PFE a dva podpůrné PFE se pokusily zjistit tento problém.

Posledním důvodem je to, že pověření uživatele (ke spuštění kroku úlohy) nemůže přistupovat ke statistikám podkladových tabulek (na straně propojeného serveru), a proto není prováděcí plán optimalizován.

Podrobně uživatel nemá oprávnění k DBCC SHOW_STATISTICS (ačkoli uživatel si může vybrat z tabulky). Podle MSDN se toto pravidlo oprávnění změní po sql 2012 SP1

Oprávnění pro SQL Server a SQL Database

Aby bylo možné zobrazit statistický objekt, musí uživatel vlastnit tabulku nebo uživatel musí být členem pevné role serveru sysadmin, role pevné databáze db_owner nebo role pevné databáze db_ddladmin.

SQL Server 2012 SP1 upravuje omezení oprávnění a umožňuje uživatelům s povolením SELECT tento příkaz používat. Všimněte si, že existují následující požadavky, aby oprávnění SELECT byla dostatečná pro spuštění příkazu:

Chcete-li tento problém ověřit, stačí spustit profiler na propojené instanci na straně serveru a zapnout některé události v části „Chyby a varování“, jak je ukázáno níže.

enter image description here

Doufám, že tato zkušenost může komunitě nějak pomoci.

1
jyao