Jaký je maximální stupeň paralelismu? Maximální stupeň paralelismu – výběr optimální hodnoty. Konfigurace parametru Maximální stupeň rovnoběžnosti

Tento příspěvek bude hovořit pouze o MS. SQL Server. Pokud plánujete „zkusit své štěstí“ v používání 1C s Oracle, DB2, Postrgre, měli byste tato informace bude k ničemu. Musíte však pochopit, že v 1C jsou především specialisté na server MS SQL. Díky úsilí IBM se objevují i ​​specialisté na DB2. Můžete se dlouho hádat o tom, zda je tento DBMS dobrý nebo špatný, jedna věc je důležitá, 1C funguje nejvíce „hladce“ se serverem MS SQL. Soudě podle posledních zpráv z „předu“ se práce s DB2 stala víceméně slušnou. I když jsem měl osobně zkušenosti s nastavením 1C pro práci s DB2 již ve verzi 8.1, vše nějak nebylo moc dobré. Volba jiného DBMS musí být každopádně jasně zdůvodněna – buď schopnostmi, které v MS SQL nejsou (cluster s vyrovnáváním zátěže, Grid atd.), nebo financemi (Oracle je již zakoupen), případně platforma (vše je na Linuxu).

Takže, v pořádku, co je třeba udělat s MS SQL Server:

1) Nastavte minimální a maximální velikost paměti. Minimum je polovina systémové paměti. Maximum - systémová paměť bez 2GB. To se provádí pomocí Management Studio - ve vlastnostech serveru:

2) Pokud priorita není nastavena na záložce "Procesory", musíte ji nastavit

3) Nastavte maximální stupeň rovnoběžnosti na 1.

4) Zapněte SQL Server Agent, nakonfigurujte Database Mail - není tam nic složitého, nebudu to podrobně popisovat.

5) Nastavení servisních plánů:
Jsou běžné:
a) Aktualizace statistik - každé 2 hodiny
b) DBCC FREEPROCCACHE - každé 2 hodiny
Pro každou základnu:
kompletní záloha
b) Rozdílová záloha
c) Defragmentace indexů - každý den
d) Přestavba indexů - v noci o víkendech
e) Kontrola integrity databáze – jednou měsíčně v noci o víkendech

6) Doporučuji u každé databáze (ve vlastnostech) nastavit model obnovy jako Jednoduchý. Pokud nemáte systém 24/7 a méně než 1 000 uživatelů na základnu, neexistuje žádný cluster s podporou převzetí služeb při selhání a nepodepsali jste smlouvu SLA, ve které se zavazujete obnovit data s přesností až na sekundu (a ne od čas posledního) v případě poruchy některého zařízení. záložní kopie) by toto doporučení bylo rozumné. Jinak budete velmi brzy dlouho a horečně přemýšlet, co s přerostlým Tranzaction Logem dělat

7) Odeberte databázi tempdb z běžných databází na jiný disk – i když ji budete muset překonfigurovat pole RAID a snížit jeho výkon. V opačném případě bude 1 uživatel schopen paralyzovat práci všech ostatních. Pokud místo toho máte Hardware Accelereator pevný disk pak to samozřejmě nemůžete oddělit a dát na to tempdb, ale to je pouze v případě, že existuje

8) nainstalujte si nějaký monitorovací nástroj - například se mi líbí spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Otestujte se s best practice analyzátorem od Microsoftu - http://www.microsoft.com/download/en/details.aspx?id=15289 - skvělý nástroj, který pomáhá nejen s nastavením, ale také s řešením mnoha problémů .

Nyní krátce, proč jsme to všechno udělali:

1) Paměť. Minimální hodnota vás jednoduše ochrání před „závadami“, kdy SQL server z nějakého důvodu, který zná pouze on, nevyužívá veškerou paměť, kterou má k dispozici. Musí se to všechno sníst! Maximální hodnota vás ochrání před swapem, pokud stejný optimalizátor využití paměti serveru SQL rozhodne, že nemohl dělat nic jiného....

3) Velmi důležitý bod - IHMO musí být nastaven na 1 ve všech transakčních systémech. Za prvé to zabraňuje určitému blokování mezi různými procesy, které se snaží splnit 1 požadavek, a chrání nás to před některými „podivnými“ chybami. Za druhé... 1 „zabijácký“ požadavek může převzít všechny prostředky serveru, což je ve vztahu k ostatním uživatelům systému poněkud nespravedlivé. Parametr sám určuje, kolik procesorových jader dokáže zpracovat 1 požadavek.

5) Statistiky a vymazání procedurální mezipaměti jsou známé, ale často zapomínáme na reindexaci. Mezitím je tento postup poměrně důležitý, zejména s rostoucím objemem databáze roste její důležitost. Někdy dochází ke ztrátě až 60 % výkonu kvůli fragmentaci indexu.

7) Pokud máte Hardware Accelerator nebo jen 2 disky s při různých rychlostech přístup, dále bych doporučil zamyslet se nad alokací skupin souborů v databázích a rozdělením jednotlivých tabulek do různých diskových polí, s různou dobou přístupu. Koneckonců musíte souhlasit s tím, že RN „zboží ve skladech“ a adresář „Sklad dodatečné informace"Existují 2 objekty, jejichž nároky na úložiště jsou zásadně odlišné. Není nutné ukládat všechny soubory a obrázky v databázi na rychlé pole - můžete je rozdělit na samostatné, ne tak rychle, ale tam, kde je hodně místa (a nebojte se nahrát hromadu souborů do databáze později, mimochodem).

  • Tutorial

Tento návod je určen pro začátečníky, kteří hledají jednoduchý návod v ruštině pro instalaci anglické verze SQL Server 2012, která bude následně použita pro SharePoint 2013.
Tento článek není pro profesionály.

Všechny práce jsou rozděleny do 3 etap:

  • Instalace SQL Server 2012
  • Nastavení parametru konfigurace serveru maximální stupeň paralelismu
  • Nastavení práv účet pro instalaci SharePointu 2013
Článek také popisuje postup Instalace Microsoftu.NET Framework 3.5 v prostředí MS Windows Server 2012 R2 Standard.

Pozor: pod řezem je spousta obrázků!

Instalace SQL Server 2012

1. Před instalací se prosím ujistěte, že máte dostatek pevného disku volný prostor(v mém případě to trvalo 2,7 GB).
Po spuštění distribuce vyberte " Instalace" v levé nabídce a poté klikněte na " Nový samostatný SQL Server nebo přidání funkcí do stávající instalace":

2. Spustí se průvodce instalací. Provede kontrolu. Můžete kliknout na tlačítko „Zobrazit podrobnosti“ a zobrazit podrobnou zprávu:

3. Podrobná zpráva. Klikněte na tlačítko „OK“:

4. Zadejte kód Product Key a klikněte na tlačítko „Další“:

5. Souhlasíme s podmínkami licenční smlouvy.
Chcete-li to provést, zaškrtněte políčko " Souhlasím s licenčními podmínkami

6. V kroku „Nastavení role“ vyberte první položku „ Instalace funkce SQL Server". Klikněte na tlačítko "Další":

7. V kroku „Výběr funkce“ označte „ Služby databázového stroje", "Nástroje pro správu – základní" A " Nástroje pro správu – kompletní“. Poté klikněte na tlačítko „Další“:

8. Instalační program poté provede další kontrolu. Můžete kliknout na tlačítko „Zobrazit podrobnosti“ a zobrazit podrobnou zprávu:

9. Podrobná zpráva. (Na v tomto stádiu Zobrazila se mi chyba v pravidle "Microsoft .NET Framework 3.5 je nainstalován...". Více o tom níže). Klikněte na tlačítko „Další“:

10. V kroku “Konfigurace instance” musíte nakonfigurovat instanci služby SQL Server.
Opakuji, že tento článek je určen začátečníkům. Budeme tedy předpokládat, že SQL Server nebyl na vašem serveru dříve nainstalován, což znamená, že ponecháme všechna výchozí nastavení. Klikněte na tlačítko „Další“:

11. V tomto kroku průvodce instalací zobrazí požadavky na místo na disku. Klikněte na tlačítko „Další“:

12. V kroku "Konfigurace serveru" musíte zadat doménový účet pro službu " SQL Server Database Engine". Po vyplnění polí „Název účtu“ a „Heslo“ klikněte na tlačítko „Další“:

13. V kroku “Konfigurace databázového stroje” stačí přidat aktuálního uživatele mezi administrátory SQL serveru. Chcete-li to provést, klikněte na tlačítko „Přidat aktuálního uživatele“ a poté na tlačítko „Další“:

14. V dalším kroku klikněte na tlačítko „Další“:

15. Dále průvodce instalací znovu provede test a zobrazí jeho výsledky. Klikněte na tlačítko „Další“:

16. V kroku „Připraveno k instalaci“ průvodce zobrazí souhrnné informace. Zde musíte kliknout na tlačítko „Instalovat“:

17. Po dokončení instalace se zobrazí informace o provedených operacích:

18. V této fázi vřele doporučuji restartovat počítač. V některých případech (například při instalaci Microsoft .NET Framework 3.5) průvodce instalací sám zobrazí okno s výzvou k restartování počítače. Neodmítat.

Nastavení parametru konfigurace serveru maximální stupeň paralelismu

Výchozí hodnota parametru Maximální stupeň rovnoběžnosti je 0.
SharePoint 2013 vyžaduje, aby toto nastavení bylo 1.
Je snadné to opravit!

1. Spusťte Microsoft SQL Server Management Studio(Start - Všechny programy - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Na obrazovce připojení k serveru klikněte na tlačítko „Připojit“.

3. Klikněte pravým tlačítkem na váš server v " Průzkumník objektů"a vyberte" Vlastnosti":

4. V okně vlastností serveru, které se otevře, v levé nabídce vyberte stránku " Pokročilý" a posuňte seznam vlastností až na konec obrazovky. Nastavte hodnotu parametru " Maximální stupeň paralelnosti"V 1 a klikněte na OK:

5. Nezavírejte SQL Server Management Studio, budeme ho potřebovat později.

Nakonfigurujte práva účtu, který je určen k instalaci SharePointu 2013

Účet, pod kterým bude SharePoint 2013 nainstalován, musí mít zvýšená práva na SQL serveru.
Doporučujeme, aby tomuto účtu byly přiděleny následující role:
  • dbcreator
  • bezpečnostní admin
  • veřejnost
1. V SQL Server Management Studio v " Průzkumník objektů"rozbalit položku" Bezpečnostní". Poté klikněte pravým tlačítkem na položku " Přihlášení"a vyberte" Nové přihlášení":

2. Do pole „Přihlašovací jméno“ zadejte Doménové jménoúčet, pod kterým plánujete nainstalovat a nakonfigurovat SharePoint 2013.

3. V levém menu vyberte stránku " Role serveru“ a zkontrolujte role „dbcreator“ a „securityadmin“ a také se ujistěte, že role „public“ je již zaškrtnuta. Poté klikněte na tlačítko „OK“:

Nyní je SQL server připraven k instalaci SharePointu 2013.

Instalace Microsoft .NET Framework 3.5 v MS Windows Server 2012 R2 Standart

V kroku číslo 9 bodu " Instalace SQL Server 2012"Zobrazila se chyba: .NET Framework 3.5 nebyl nainstalován.
Chcete-li tento problém vyřešit, musíte provést následující kroky:

1. Musíte otevřít konzolu" Správce serveru".

2. V levém menu vyberte položku „Dashboard“.

3. Ve středu okna klikněte na položku „Přidat role a funkce“.

4. V průvodci, který se otevře, přeskočte krok „Než začnete“.

5. V kroku „Typ instalace“ vyberte položku „ Instalace na základě rolí nebo funkcí Klikněte na tlačítko „Další“.

6. V dalším kroku ponechte vše jako výchozí a klikněte na tlačítko „Další“.

7. Přeskočte krok „Role serveru“ kliknutím na tlačítko „Další“.

8. V kroku „Features“ zaškrtněte políčko „.NET Framework 3.5 Features“. Klikněte na tlačítko „Další“.

9. Po dokončení procesu instalace můžete zavřít Průvodce přidáním rolí a funkcí.

10. Hotovo!

Hodně štěstí všem a klidné nebe nad vašimi hlavami!

P.S. Šťastný nadcházející den kosmonautiky!

Maximální stupeň paralelismu (DOP) je další možnost konfigurace serveru SQL Server, která byla předmětem mnoha otázek a publikací. V tomto příspěvku na blogu autor doufá, že poskytne určitou jasnost v tom, co tato možnost dělá a jak by měla být použita.
Za prvé, autor by rád objasnil všechny pochybnosti, že uvedená možnost nastavuje, kolik procesorů může SQL Server používat při obsluhování více připojení (nebo uživatelů) - to ne! Pokud má SQL Server přístup ke čtyřem nečinným procesorům a je nakonfigurován tak, aby používal všechny čtyři procesory, bude používat všechny čtyři procesory bez ohledu na maximální stupeň paralelismu.
Co tedy tato možnost dělá? Tato možnost nastavuje maximální počet procesorů, které může SQL Server použít pro jeden dotaz. Pokud by se měl vrátit dotaz na SQL Server velký objem data (mnoho záznamů), někdy má smysl je paralelizovat a rozdělit na několik malých dotazů, z nichž každý vrátí svou vlastní podmnožinu řádků. SQL Server tedy může používat více procesorů, a proto na víceprocesorových systémech může být potenciálně vráceno velké množství záznamů celého dotazu rychleji než na jednoprocesorovém systému.
Existuje mnoho kritérií, která je třeba vzít v úvahu, než SQL Server vyvolá „paralelismus uvnitř dotazu“ (rozdělení dotazu do více vláken), a nemá smysl je zde uvádět. Najdete je v BOL vyhledáním "Stupeň paralelismu". Říká, že rozhodnutí o paralelizaci je založeno na dostupnosti paměti pro procesor a zejména na dostupnosti samotných procesorů.
Proč bychom tedy měli uvažovat o použití této možnosti – protože její ponechání na výchozí hodnotě (SQL Server dělá svá vlastní rozhodnutí o paralelizaci) může mít někdy nežádoucí účinky. Tyto efekty vypadají asi takto:

    Paralelní dotazy běží pomaleji.

    Časy provádění dotazů se mohou stát nedeterministickými, což může uživatele obtěžovat. Doba provedení se může změnit, protože:

      Dotaz se může někdy paralelizovat a někdy ne.

      Požadavek lze zablokovat paralelním požadavkem, pokud byly procesory dříve přetíženy prací.

Než budeme pokračovat, autor by rád poukázal na to, že není třeba se ponořit do vnitřní organizace paralelismu. Pokud vás to zajímá, můžete si přečíst článek „Paralelní zpracování dotazů“ v Books on Line, který tyto informace popisuje podrobněji. Autor se domnívá, že je třeba vědět pouze dvě důležité věci vnitřní organizace rovnoběžnost:

    Paralelní dotazy mohou vytvářet více vláken, než je uvedeno ve volbě "Maximální stupeň paralelismu". DOP 4 může vytvářet více než dvanáct vláken, čtyři pro dotazování a další vlákna používaná pro řazení, proudy, agregace a sestavy atd.

    Paralelní požadavky mohou způsobit, že různé SPID budou čekat s typem čekání CXPACKET nebo 0X0200. To lze použít k nalezení těch SPIDs, které jsou ve stavu čekání během paralelních operací a mají waittype v sysprocesses: CXPACKET. Pro usnadnění tohoto úkolu autor navrhuje použít uloženou proceduru dostupnou na jeho blogu: track_waitstats.

A tak „Dotaz může být při paralelizaci pomalejší“ proč?

    Pokud je systém velmi slabý propustnost diskových subsystémů, pak při analýze požadavku může jeho rozklad trvat déle než bez paralelismu.

    Může docházet k zkreslení dat nebo blokování datových rozsahů pro procesor způsobené jiným paralelně používaným procesem a spuštěným později atd.

    Pokud na predikátu není žádný index, výsledkem je prohledávání tabulky. Paralelní operace v rámci dotazu může zakrýt skutečnost, že dotaz by byl dokončen mnohem rychleji s plánem sekvenčního provádění a správným indexem.

Z toho všeho vyplývá doporučení zkontrolovat provedení požadavku bez paralelismu (DOP=1), pomůže to identifikovat možné problémy.
Výše uvedené účinky paralelismu by vás přirozeně měly vést k přesvědčení, že vnitřní mechanika paralelizace dotazů není vhodná pro použití v aplikacích OLTP. Jedná se o aplikace, pro které může být změna doby provádění dotazu pro uživatele obtěžující a pro které je nepravděpodobné, že by server obsluhující mnoho souběžných uživatelů zvolil plán paralelního provádění kvůli profilu zátěže procesoru, který je vlastní těmto aplikacím.
Pokud tedy budete paralelismus používat, pak jej s největší pravděpodobností budete potřebovat pro úlohy získávání dat (datový sklad), podporu rozhodování nebo reportingové systémy, kde není mnoho dotazů, ale jsou poměrně těžké a jsou prováděny na výkonném server s velkým množstvím paměti RAM.
Pokud se rozhodnete použít paralelismus, jakou hodnotu byste měli nastavit pro DOP? Dobrá praxe pro tento mechanismus je, že pokud máte 8 procesorů, nastavte DOP = 4 a toto bude s největší pravděpodobností optimální nastavení. Není však zaručeno, že to takto bude fungovat. Jediný způsob, jak mít jistotu, je testovat různé významy pro DOP. Kromě toho chtěl autor nabídnout svou empirickou radu, aby toto číslo nikdy nenastavovalo více než polovinu počtu dostupných procesorů. Pokud by autor měl méně než šest procesorů, nastavil by DOP na 1, což jednoduše zakáže paralelizaci. Mohl by udělat výjimku, pokud by měl databázi, která podporuje pouze jeden uživatelský proces (některé technologie získávání dat nebo reportovací úlohy), v takovém případě by bylo možné jako výjimku nastavit DOP na 0 (výchozí hodnota), což umožňuje samotnému SQL Serveru rozhodnout, zda dotaz paralelizovat.
Před dokončením článku vás autor chtěl upozornit, že vytváření paralelního indexu závisí na čísle, které nastavíte pro DOP. To znamená, že jej můžete chtít změnit během vytváření nebo opětovného vytváření indexů, abyste zlepšili výkon této operace, a samozřejmě můžete v dotazu použít nápovědu MAXDOP, která vám umožní přepsat hodnotu nastavenou v konfiguraci a může používat mimo špičku.
A konečně, váš dotaz se může při paralelizaci zpomalit kvůli chybám, takže se ujistěte, že váš server má nainstalovanou nejnovější aktualizaci service pack.

CREATE proc track_waitstats (@num_samples int = 10 ,@delaynum int = 1 ,@delaytype nvarchar ( 10 )="minuty" ) AS -- T. Davidson -- Tato uložená procedura je poskytována =JAK JE= bez záruk,-- a neuděluje žádná práva. -- Použití přiložených ukázek skriptů podléhá podmínkám -- specifikováno na http://www.microsoft.com/info/cpyright.htm -- @num_samples je počet, kolikrát se mají zachytit statistiky čekání, -- výchozí hodnota je 10krát. výchozí interval zpoždění je 1 minuta -- delaynum je interval zpoždění. delaytype určuje, zda -- interval zpoždění jsou minuty nebo sekundy -- pokud ano, vytvořte tabulku waitstats ne existovat, jinak zkrátit set nocount on if not existuje (vyberte 1 ze sysobjects kde name = "waitstats" ) vytvořte tabulku waitstats ( varchar ( 80 ), požadavky numerické ( 20 ,1 ), číselné ( 20 ,1 ), číselné ( 20 ,1 ), nyní datum a čas výchozí getdate ()) else zkrátit tabulku waitstats dbcc sqlperf (waitstats,clear) -- vymazat waitstats deklarovat @i int ,@delay varchar ( 8 ),@dt varchar ( 3 ),@nyní datum a čas ,@celkem počkej číselně ( 20 ,1 ) ,@endtime datetime ,@begintime datetime ,@hr int ,@min int ,@sec int vybrat @i = 1 vyberte @dt = malá a malá písmena (@delaytype), když „minuty“ pak „m“, když „minuta“, potom „m“, když „min“, potom „m“, když „mm“, potom „m“, když „mi“ pak „m“ když „m“ pak „m“, když „sekundy“, pak „s“, když „sekunda“, pak „s“, když „sek“, pak „s“, když „ss“, pak „s“, když „s“, pak „s“ jinak @ delaytype end if @dt not in ("s" ","m" ) begin print "zadejte prosím typ zpoždění, např. sekundy nebo minuty" return end if @dt = "s" begin select @sec = @delaynum % 60 vyberte @min = obsazení ((@delaynum / 60 ) jako int ) vyberte @hr = cast ((@min / 60 ) jako int ) vyberte @min = @min % 60 end if @dt = "m" begin vyberte @sec = 0 vyberte @min = @delaynum % 60 vyberte @hr = obsazení ((@delaynum / 60 ) as int ) end select @delay = right ("0" + convert (varchar ( 2 ),@hr), 2 2 ),@min), 2 ) + ":" + + vpravo ("0" +převést (varchar ( 2 ),@sec), 2 ), pokud @hr > 23 nebo @min > 59 nebo @sec > 59 začít vybírat "hh:mm:ss zpoždění nelze > 23:59:59" vyberte "interval zpoždění a zadejte: " + převést (varchar ( 10 ) ,@delaynum) + "," + @delaytype + " převede na " + @delay return end while (@i<= @num_samples) begin insert into waitstats (, requests, ,) exec ("dbcc sqlperf(waitstats)" ) select @i = @i + 1 waitfor delay @delay End --- vytvoření zprávy waitstats spusťte get_waitstats --//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/ CREATE proc get_waitstats AS -- Tato uložená procedura je poskytována =JAK JE= bez záruk a-- Netýká se žádných práv. -- Použití zahrnutých ukázek skriptů podléhá specifikovaným podmínkám -- na http://www.microsoft.com/info/cpyright.htm -- -- tento proces vytvoří sestavu waitstats se seznamem typů čekání podle-- procento -- lze spustit při provádění track_waitstats set nocount on deklarovat @now datetime ,@totalwait numeric ( 20 ,1 ) ,@endtime datetime ,@begintime datetime ,@hr int ,@min int ,@sec int vyberte @now=max (nyní),@begintime=min (nyní),@endtime=max (nyní) z waitstats kde = " Celkový" --- odečíst waitfor, spánek a resource_queue od Total vyberte @totalwait = sum() + 1 z waitstats kde není v ("WAITFOR" , "SLEEP" , "RESOURCE_QUEUE" , "Total" , "***total***" ) a nyní = @nyní -- vložit upravené součty, seřadit podle procenta sestupně delete waitstats where = "***total***" a now = @now insert into waitstats vybrat "***total***" , 0 ,@totalwait ,@totalwait ,@nyní vyberte , ,procento = obsazení ( 100 */@totalwait jako číselné ( 20 ,1 )) z waitstats, kde není v ("WAITFOR" , "SLEEP" , "RESOURCE_QUEUE" , "Total" ) a nyní = @nyní seřadit podle procenta desc

ROZSAH TOHOTO ČLÁNKU: SQL Server (od roku 2008)Azure SQL DatabaseAzure SQL Data WarehouseParalelní datový sklad

Tato část popisuje, jak nakonfigurovat konfigurační parametr serveru maximální stupeň paralelismu (MAXDOP) v SQL Server 2016 pomocí SQL Server Management Studio nebo Transact-SQL. Když instance SQL Server běží na víceprocesorovém počítači, určuje optimální stupeň paralelismu, tj. počet procesorů použitých k provedení jednoho příkazu, pro každý z plánů paralelního provádění. K omezení počtu procesorů v plánu paralelního provádění lze použít parametr maximální stupeň paralelismu. SQL Server bere v úvahu plány paralelního provádění pro dotazy, operace DDL na indexech, paralelní vkládání, úpravy sloupců online, sběr paralelních statistik a populaci statických kurzorů a kurzorů řízených sadou klíčů.

Omezení

  • Pokud je parametr masky spřažení nastaven na jinou než výchozí hodnotu, může omezit počet procesorů dostupných pro SQL Server v systémech symetrických víceprocesorů (SMP).

    Toto nastavení je volitelné a měli by jej měnit pouze zkušení správci databází nebo certifikovaní technici SQL Server.

    Chcete-li serveru umožnit určit maximální stupeň paralelismu, nastavte tento parametr na 0, což je výchozí hodnota. Nastavení maximálního stupně paralelismu na 0 umožňuje serveru SQL používat všechny dostupné procesory (až 64 procesorů). Chcete-li zakázat vytváření paralelních plánů, nastavte parametr maximální stupeň paralelismu hodnota 1. Nastavte parametr na hodnotu mezi 1 a 32 767, abyste určili maximální počet procesorových jader, která lze použít ke spuštění jednoho dotazu. Pokud je zadána hodnota větší než počet dostupných procesorů, použije se skutečný počet dostupných procesorů. Pokud má počítač pouze jeden procesor, pak hodnota parametru maximální stupeň paralelismu nebudou brány v úvahu.

    Hodnotu parametru maximálního stupně paralelismu lze přepsat zadáním dotazu MAXDOP v příkazu. Další informace viz .

    Operace vytváření a opětovného sestavení indexů, stejně jako odstranění seskupeného indexu, mohou být poměrně náročné na zdroje. Hodnotu parametru maximálního stupně paralelismu pro operace indexu lze přepsat zadáním parametru indexu MAXDOP v příkazu. Hodnota MAXDOP je aplikována na příkaz za běhu a není uložena v metadatech indexu. Více informací naleznete v článku.

    Kromě operací dotazů a indexů tento parametr také řídí stupeň paralelismu při provádění příkazů DBCC CHECKTABLE, DBCC CHECKDB a DBCC CHECKFILEGROUP. Plány souběžnosti pro tyto instrukce lze zakázat pomocí příznaku trasování 2528. Další informace naleznete v tématu .

Bezpečnost

Oprávnění

Oprávnění ke spuštění uložené procedury sp_configure bez parametrů nebo pouze s prvním parametrem jsou standardně poskytovány všem uživatelům. Chcete-li provést postup sp_configure s oběma možnostmi musíte mít oprávnění ALTER SETTINGS na úrovni serveru, abyste mohli změnit nastavení konfigurace nebo spustit příkaz RECONFIGURE. Oprávnění ALTER SETTINGS je implicitně uděleno pevným rolím serveru správce systému A správce serveru .

    V Průzkumník objektů klikněte pravým tlačítkem na server a vyberte Vlastnosti.

    Klepněte na uzel dodatečně .

    V terénu Maximální stupeň rovnoběžnosti Zadejte maximální počet procesorů, které lze použít v plánu paralelního provádění.

Konfigurace parametru Maximální stupeň rovnoběžnosti

    Vytvořte připojení k Database Engine.

    Na panelu Standardní klikněte na Vytvořte žádost.

    Zkopírujte následující příklad do okna dotazu a klikněte na tlačítko Vykonat. Tento příklad popisuje, jak pomocí procedury nastavit hodnotu parametru maximálního stupně rovnoběžnosti na 8.

POUŽÍVEJTE AdventureWorks2012 ; GO EXEC sp_configure "zobrazit pokročilé možnosti" , 1 ; PŘEJDĚTE PŘEKONFIGUROVAT S PŘEPISEM; GO EXEC sp_configure "maximální stupeň paralelismu" , 8 ; PŘEJDĚTE PŘEKONFIGUROVAT S PŘEPISEM; JÍT

Více informací naleznete v článku

Není žádným tajemstvím, že při zvažování problémů s konfigurací SQL serveru souvisejících se zvýšením produktivity se většina IT specialistů rozhodne pro zvýšení hardwaru. Ale je to vždy oprávněné? Byly již použity všechny metody konfigurace serveru? Je známo, že práce s konfiguračními parametry a změna jejich výchozích hodnot může zlepšit výkon a další vlastnosti daného systému. Mezi těmito možnostmi konfigurace SQL je jedna možnost, která má mnoho otázek, tato možnost je Maximální stupeň paralelismu (DOP) - takže o ní budeme mluvit.

Možnost Maximum Degree of Parallelism (DOP) určuje počet vláken, na které může SQL Server paralelizovat dotaz, a označuje počet použitých serverových procesorů. Tento parametr má výchozí hodnotu 0 – maximální stupeň rovnoběžnosti. Máte-li například 24 jader, bude hodnota „maximálního stupně paralelismu“ rovna 24 a optimalizátor, pokud to považuje za nutné, může použít všechny procesory k provedení jedné instrukce, to znamená, že požadavek bude paralelizované do 24 vláken. To je dobré pro většinu případů, ale ne pro všechny. Také není vždy dobré používat výchozí hodnotu tohoto parametru. Konfigurace tohoto parametru může být nezbytná například v následující situaci: řekněme, že máme aplikaci, do které všichni zaměstnanci zadávají informace o denních transakcích, a v určitém časovém období každý z uživatelů spustí dotaz, který vytvoří hlásit všechny transakce uživatele za určité časové období. Pokud je časové období dlouhé, bude tento požadavek přirozeně trvat dlouho a se standardně nainstalovaným DOP zabere všechny dostupné procesory, což přirozeně ovlivní práci ostatních uživatelů. Změnou hodnoty DOP tedy můžeme prodloužit dobu odezvy SQL serveru pro ostatní uživatele, aniž bychom měnili samotný dotaz.
MS doporučuje nastavit hodnotu následovně:

Nastavení parametru na TSQL zcela pro server:

EXEC sp_configure "maximální stupeň paralelismu", 4; přenastavit

Tuto hodnotu můžete také nastavit pro konkrétní dotaz TSQL:

POUŽÍVEJTE AdventureWorks2008R2 ; GO SELECT ProductID, OrderQty, SUM(LineTotal) AS TotalFROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO

V tomto příkladu změní nápověda maxdop výchozí hodnotu parametru maximálního stupně paralelismu na 2. Aktuální nastavení můžete zobrazit takto:

EXEC sp_configure "Zobrazit pokročilé",1; PŘENASTAVIT; EXEC sp_configure "maximální stupeň paralelismu"

Nyní se podívejme, jak tato hodnota ovlivňuje rychlost provádění dotazu. Aby se výše napsaný testovací dotaz prováděl delší dobu, přidáme k němu další select. Žádost bude mít následující formu:

< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty

Na mém testovacím počítači je hodnota 'maximální stupeň paralelismu' nastavena na 0. MSSQL běží na počítači se 4jádrovým procesorem. Provedl jsem sérii experimentů s různými hodnotami MAXDOP: rovna 1 – bez paralelizace dotazů; rovná se 2 - použití pouze 2 jader; rovná se 4 – použití všech a žádné nápovědy k určení možnosti, která používá výchozí pokračování. Chcete-li získat statistiky provádění, musíte do dotazu zahrnout možnost NASTAVIT ČAS STATISTIKY ZAPNUTO a také povolit tlačítko zobrazení plánu dotazů v Management studiu. Abych zprůměroval výsledky, spustil jsem každý dotaz ve smyčce 3krát. Výsledky můžete vidět níže:

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 1); SQL Server Execution Times: CPU time = 45942 ms, elapsed time = 46118 ms. SQL Server Execution Times: CPU time = 45926 ms, elapsed time = 46006 ms. SQL Server Execution Times: CPU time = 45506 ms, elapsed time = 45653 ms.

Plán dotazů ukazuje, že při instalaci nápovědy (MAXDOP 1) byl dotaz proveden bez paralelizace. Průměrná doba provádění dotazu 45925,66 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 2); SQL Server Execution Times: CPU time = 51684 ms, elapsed time = 28983 ms. SQL Server Execution Times: CPU time = 51060 ms, elapsed time = 26165 ms. SQL Server Execution Times: CPU time = 50903 ms, elapsed time = 26015 ms.

Při instalaci nápovědy (MAXDOP 2) byl požadavek spuštěn paralelně na 2 cpu, je to vidět v počtu spuštění v plánu provádění dotazu. Průměrná doba provádění dotazu 27054,33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 4); SQL Server Execution Times: CPU time = 82275 ms, elapsed time = 23133 ms. SQL Server Execution Times: CPU time = 83788 ms, elapsed time = 23846 ms. SQL Server Execution Times: CPU time = 53571 ms, elapsed time = 27227 ms.

Při instalaci nápovědy (MAXDOP 4) byl požadavek spuštěn paralelně na 4 cpu. Průměrná doba provádění dotazu 24735,33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty SQL Server Execution Times: CPU time = 85816 ms, elapsed time = 23190 ms. SQL Server Execution Times: CPU time = 85800 ms, elapsed time = 23307 ms. SQL Server Execution Times: CPU time = 58515 ms, elapsed time = 26575 ms.

požadavek byl proveden paralelně, také 4 cpu. Průměrná doba provádění dotazu 24357,33 ms

odkazy: http://support.microsoft.com/kb/2023536