Maximálny stupeň paralelizmu (DOP) je pokročilá možnosť konfigurácie servera SQL Server, ktorá bola predmetom mnohých otázok a bola predmetom mnohých publikácií. V tomto blogovom príspevku autor dúfa, že objasní, čo táto možnosť robí a ako by sa mala používať.

Po prvé, autor by chcel rozptýliť akékoľvek pochybnosti, že vyššie uvedená možnosť nastavuje, koľko procesorov môže SQL Server použiť pri obsluhe viacerých pripojení (alebo používateľov) – nie! Ak má SQL Server prístup k štyrom nečinným procesorom a je nakonfigurovaný na používanie všetkých štyroch procesorov, bude používať všetky štyri procesory bez ohľadu na maximálny stupeň paralelizmu.

Čo teda táto možnosť robí? Táto možnosť nastavuje maximálny počet procesorov, ktoré môže SQL Server použiť na jeden dotaz. Ak by sa mal vrátiť dotaz na server SQL Server veľký objem dáta (veľa záznamov), niekedy má zmysel ich paralelizovať tak, že ich rozdelíte na niekoľko malých dopytov, z ktorých každý vráti svoju vlastnú podmnožinu riadkov. Takže SQL Server môže používať viacero procesorov, a teda aj viacprocesorové systémy veľké množstvo záznamy celého dotazu by sa potenciálne mohli vrátiť rýchlejšie ako na jednoprocesorovom systéme.

Existuje mnoho kritérií, ktoré je potrebné zvážiť pred tým, ako SQL Server vyvolá „paralelizmus vnútri dotazov“ (rozloženie dotazu do viacerých vlákien), a nemá zmysel ich tu podrobne popisovať. Nájdete ich v BOL vyhľadaním "Stupeň paralelizmu". Hovorí, že rozhodnutie o paralelizácii je založené na dostupnosti pamäte pre procesor a najmä na dostupnosti samotných procesorov.

Preto by sme mali zvážiť použitie tejto možnosti, pretože jej ponechanie na predvolenej hodnote (SQL Server rozhoduje o paralelizácii sám) môže mať niekedy nežiaduce účinky. Tieto efekty vyzerajú takto:

• Paralelizované dopyty bežia pomalšie.
• Časy vykonávania dotazov sa môžu stať nedeterministickými, čo môže obťažovať používateľov. Čas vykonania sa môže zmeniť, pretože:
  • Dopyt sa môže niekedy paralelizovať a niekedy nie.
  • Požiadavka môže byť zablokovaná paralelnou požiadavkou, ak boli procesory predtým preťažené prácou.

Predtým, ako budeme pokračovať, autor by rád poznamenal, že nie je potrebné venovať sa vnútornej organizácii paralelizmu. Ak vás to zaujíma, môžete si prečítať článok „Paralelné spracovanie dopytov“ v Books on Line, kde sú tieto informácie uvedené podrobnejšie. Autor sa domnieva, že o vnútornej organizácii paralelizmu treba vedieť len dve dôležité veci:

1. Paralelné požiadavky môžu vyvolať viac vlákien, ako je uvedené vo voľbe „Maximálny stupeň paralelizmu“. DOP 4 môže vytvoriť viac ako dvanásť vlákien, štyri pre dopyt a ďalšie vlákna používané na triedenie, vlákna, agregáty a zostavy atď.
2. Paralelnosť dotazov môže spôsobiť rôzne čakania SPID s typom čakania CXPACKET alebo 0X0200. Toto sa dá použiť na nájdenie tých SPID, ktoré čakajú na paralelné operácie a majú waittype: CXPACKET v sysprocesses. Na uľahčenie tejto úlohy autor navrhuje použiť uloženú procedúru dostupnú v jeho blogu: track_waitstats.

Prečo teda „Dotaz môže pri paralelizácii bežať pomalšie“?

• Ak je systém veľmi slabý priepustnosť diskové podsystémy, potom pri parsovaní dotazu môže jeho rozklad trvať dlhšie ako bez paralelizmu.
• Možné zámky zošikmenia údajov alebo rozsahu údajov pre procesor, generované iným paralelne používaným procesom a spúšťaným neskôr atď.
• Ak pre predikát neexistuje žiadny index, výsledkom je prehľadávanie tabuľky. Paralelná operácia v rámci dotazu môže zakryť skutočnosť, že dotaz by bežal oveľa rýchlejšie s plánom postupného vykonávania a so správnym indexom.

Účinky paralelizmu spomenuté vyššie by vás mali samé osebe viesť k myšlienke, že interná mechanika paralelizácie dotazov nie je vhodná na použitie v aplikáciách OLTP. Ide o aplikácie, pre ktoré môže zmena času vykonávania dotazu obťažovať používateľov a pre ktoré je nepravdepodobné, že by si server obsluhujúci viacero používateľov súčasne zvolil plán paralelného vykonávania kvôli vlastným charakteristikám profilu pracovného zaťaženia procesora v týchto aplikáciách.

Preto, ak sa chystáte použiť paralelizmus, s najväčšou pravdepodobnosťou to bude potrebné pre úlohy extrakcie údajov (údajový sklad), podporu rozhodovania alebo systémy výkazníctva, kde nie je veľa dotazov, ale sú dosť ťažké a vykonávajú sa na výkonnom server s veľkým množstvom operačnej pamäte.

Ak sa rozhodnete použiť paralelizmus, akú hodnotu by ste mali nastaviť pre DOP?. Pre tento mechanizmus je dobrou praxou, že ak máte 8 procesorov, nastavte DOP = 4 a toto je veľmi pravdepodobne optimálne nastavenie. Nie je však zaručené, že to bude takto fungovať. Jediný spôsob, ako si to byť istý, je testovať rôzne hodnoty DOP. Okrem toho chcel autor ponúknuť svoju empirickú radu, nikdy nenastavujte toto číslo na viac ako polovicu počtu dostupných procesorov. Ak by mal autor menej ako šesť procesorov, nastavil by DOP na 1, čo jednoducho zakáže paralelizáciu. Môže urobiť výnimku, ak by mala databázu, ktorá podporuje iba jeden používateľský proces (niektoré technológie získavania údajov alebo úlohy vykazovania), v takom prípade by bolo možné ako výnimku nastaviť DOP na 0 (predvolené), čo umožňuje SQL Server samostatne rozhodnúť, či paralelizovať dotaz.

Pred ukončením článku vás autor chcel upozorniť, že paralelné vytváranie indexov závisí od čísla, ktoré nastavíte pre DOP. To znamená, že ho možno budete chcieť zmeniť v čase vytvárania alebo opätovného vytvárania indexov, aby ste zlepšili výkon tejto operácie a samozrejme môžete použiť MAXDOP hint v dotaze, ktorý vám umožní ignorovať hodnotu nastavenú v konfigurácii a možno použiť v čase mimo špičky.

Nakoniec sa vaša požiadavka môže spomaliť pri paralelizácii kvôli chybám, takže sa uistite, že máte na serveri nainštalovaný najnovší balík service pack.

REATE proc track_waitstats
@num_samples int = 10
,@delaynum int = 1
,@delaytype nvarchar ( 10 )="minúty"
AS
-- T. Davidson
-- Táto uložená procedúra sa poskytuje =TAK, AKO JE= bez záruk,
-- a konferencie žiadne práva.
-- Použitie zahrnutých ukážok skriptov podlieha podmienkam
-- uvedené na http://www.microsoft.com/info/cpyright.htm
-- @num_samples je počet zaznamenaných čakacích štatistík,
-- predvolená hodnota je 10-krát. predvolený interval oneskorenia je 1 minúta
-- delaynum je interval oneskorenia. delaytype určuje, či
-- interval oneskorenia je minúty alebo sekundy
-- vytvorte tabuľku waitstats, ak neexistuje, inak ju skrátite

nerátať s tým
ak neexistuje (vyberte 1 zo sysobjects, kde name = "waitstats" )
vytvoriť tabuľku waitstats(varchar( 80 ),
požiadavky numerické ( 20 ,1 ),
číselné ( 20 ,1 ),
číselné ( 20 ,1 ),
teraz dátum a čas predvolené getdate())
else skrátenie tabuľky waitstats

dbcc sqlperf (waitstats,clear) -- vymazať waitstats

vyhlásiť @i int
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@teraz dátum a čas
,@totalwait číselné ( 20 ,1 )
,@čas ukončenia dátum a čas
,@začiatok dátum a čas
,@hr int
,@min int
,@sek int

vyberte @i = 1
vyberte @dt = malé a veľké písmená (@delaytype)
keď "minúty" potom "m"
keď "minúta" potom "m"
keď "min", potom "m"
keď "mm" tak "m"
keď "mi" tak "m"
keď "m" tak "m"
keď "sekundy" potom "s"
keď "druhý" potom "s"
keď "sek" potom "s"
keď "ss" potom "s"
keď "s" tak "s"
inak @delaytype
koniec

ak @dt nie je v ("s" ","m" )
začať
vytlačiť "zadajte typ oneskorenia, napr. sekundy alebo minúty"
vrátiť
koniec

ak @dt = "s"
začať
vyberte @sec = @delaynum % 60
vyberte @min = cast((@delaynum / 60 ) ako int )
vyberte @hr = cast((@min / 60 ) ako int )
vyberte @min = @min % 60
koniec

ak @dt = "m"
začať
vyberte @sec= 0
vyberte @min = @delaynum % 60
select @hr = cast((@delaynum / 60 ) ako int )
koniec

select @delay = right("0" + convert(varchar( 2 ),@hr), 2 ) + ":" +
2 ),@min), 2 ) + ":" +
+ right("0" +convert(varchar( 2 ),@sec), 2 )

ak @hr > 23 alebo @min > 59 alebo @sec > 59
začať
vyberte "Hh:mm:ss oneskorenie nemôže > 23:59:59"
vyberte "interval oneskorenia a zadajte: " + konvertovať (varchar ( 10 )
,@delaynum) + "," + @delaytype + " prevedie na "
+ @oneskorenie
vrátiť
koniec

kým<= @num_samples)
začať
vložiť do waitstats(, requesty,
,)
exec("dbcc sqlperf(waitstats)" )
vyberte @i = @i + 1
čakaj na meškanie @delay
Koniec

Vytvorte správu o stave čakania
spustiť get_waitstats

--//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/

CREATE proc get_waitstats
AS
-- Táto uložená procedúra sa poskytuje =TAK, AKO JE= bez záruk a
-- konferencie žiadne práva.
-- Použitie zahrnutých ukážok skriptov podlieha špecifikovaným podmienkam
-- na http://www.microsoft.com/info/cpyright.htm
--
-- tento proces vytvorí zostavu waitstats so zoznamom typov čakania podľa
-- percentá
-- možno spustiť pri spustení track_waitstats

nerátať s tým

vyhlásiť @teraz dátum a čas
,@totalwait číselné ( 20 ,1 )
,@čas ukončenia dátum a čas
,@začiatok dátum a čas
,@hr int
,@min int
,@sek int

vyberte @teraz=max (teraz),@začiatok=min (teraz),@koniec=max (teraz)
z waitstats kde = "Celkom"

Odpočítajte čakanie, spánok a frontu zdrojov od súčtu

vyberte @totalwait = sum() + 1 z waitstats
kde nie je v ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE"
, "Celkom" , "***celkom***" ) a teraz = @teraz

Vložte upravené súčty, zoraďte ich podľa percenta zostupne

delete waitstats where = "***total***" and now = @ now

vložiť do waitstats vyberte "***total***"
,0
,@totalwait
,@totalwait
,@teraz

vyberte
,
,percento = obsadenie ( 100 */@totalwait ako číselné ( 20 ,1 ))
z waitstats
kde nie v ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" ,,Celkom" )
a teraz = @teraz
poradie podľa percenta zostup

V tejto krátkej poznámke by som rád povedal niečo o zložitosti nastavení súbežnosti v Microsoft SQL Server. Mnohí z vás už dávno poznajú možnosť Max Degree od Parallelism, ktorá je v SQL Serveri prítomná už veľmi dlho. Štandardne je nastavená na 0, čo znamená, že SQL Server si sám zvolí optimálny stupeň paralelizmu, teda počet procesorov / vlákien zapojených do vykonávania jednej inštrukcie. Teraz sa nezastavím a budem diskutovať o tom, na akú hodnotu je lepšie nastaviť túto možnosť - toto je téma na samostatnú poznámku. Budem uvažovať iba o tom, ako hodnota tejto možnosti ovplyvňuje vykonávanie dopytov. Napríklad na obrázku nižšie je táto možnosť nastavená na 1, čo znamená, že paralelné plány pre všetky dotazy sú predvolene zakázané.

Túto možnosť je možné zobraziť aj pomocou nasledujúceho príkazu T-SQL:

Akýkoľvek predvolený plán dotazov bude sekvenčný. Napríklad:

Vývojár a každý používateľ má však stále možnosť to ovplyvniť pomocou hintov. Ak to chcete urobiť, stačí zadať požadovaný stupeň paralelizmu a vygeneruje sa požadovaný plán dotazov, napríklad:

A ak tento dotaz pozorujeme cez pohľad sys.dm_exec_query_profiles, uvidíme, že je skutočne vykonaný v 10 vláknach.

V systéme teda zostáva tajná diera, ktorú môžu vývojári a používatelia použiť na „zrýchlenie“ (tu to konkrétne uvádzam do úvodzoviek, pretože nie vždy vysoký stupeň paralelizmu vedie k skráteniu času vykonávania dotazu) svojich dopytov. zvýšením miery paralelizmu . Ale týmto spôsobom môžu jednoducho „zabiť“ server spustením mnohých nekontrolovaných paralelných požiadaviek súčasne. Čo s tým môžeme urobiť? Tu prichádza na pomoc Resource Governor, veľmi výkonný a úplne podceňovaný systém, ktorý umožňuje veľmi flexibilne distribuovať zdroje medzi rôzne skupiny používateľov. Opäť sa nebudem venovať tomu, ako funguje a aké má schopnosti. Len rozvediem, ako to ovplyvňuje nastavenie limitu súbežnosti. Najprv sa pozrime na predvolené nastavenia:

Opäť vidíme, že možnosť je predvolene nastavená na 0 a rozhodnutie o výbere maximálneho stupňa je na milosť a nemilosť servera SQL Server. Teraz sa pozrime, čo sa stane, ak túto hodnotu zmením na 5. Dokonca som nedefinoval klasifikačnú funkciu pre Resource Governor a mením predvolenú skupinu. Ale na test a pochopenie toho, ako všetko funguje práve teraz v mojom príklade, to stačí. Tým pádom obmedzujem maximálnu mieru paralelizmu pre každého na 5 vlákien. Pripomeňme, že možnosť Maximálny stupeň paralelnosti, na ktorý sme sa pozreli skôr, je stále nastavený na 1. Ak sa teraz pozrieme na plán vykonávania nášho pôvodného dotazu, potom bude štandardne sekvenčný a s možnosťou maxdop 10 paralelný. Ale ak spustíme paralelný plán, uvidíme niečo zaujímavé.

Teraz je naša požiadavka vykonaná iba v 5 vláknach, napriek tomu, že možnosť maxdop má hodnotu 10. A ak pre dotaz zadáte možnosť maxdop 4, vykoná sa v 4 vláknach (možnosť v Resource Governor je nastavená na 5). V tomto prípade nápoveda maxdop menej ako nastavenie Resource Governor, takže nie je uložené žiadne ďalšie obmedzenie. Už neuvádzam príklad tohto.

Resource Governor je teda výkonnejší nástroj, ktorý už skutočne obmedzuje maximálnu mieru paralelizmu pre dotazy a tento stupeň je možné nastaviť rôzne pre rôzne skupiny používateľov. Zároveň možnosť Maximálny stupeň paralelnosti stále funguje a robí svoju časť (alebo mierne mätie správcov, vývojárov a používateľov, keď je spárovaný s Resource Governor). Ďalej sú možnosti nastavenia hodnôt týchto 2 parametrov obmedzené iba vašou predstavivosťou, ale je dôležité si zapamätať iba dve veci: Maximálny stupeň paralelnosti a naznačiť maxdop pre požiadavku ovplyvní, ktorý plán sa vygeneruje, koľko maximálneho počtu vlákien bude možné pre túto požiadavku, a Resource Governor ďalej obmedzuje požiadavku zhora už za behu.

Cieľ:študovať vplyv paralelizmu SQL na prácu s dopytmi 1C

Literatúra:

Testovacie prostredie:

Windows Server 2008 R2 Enterprise

MS SQL Server 2008 R2

1C Enterprise 8.2.19.90

Obrázok 1. Vlastnosti SQL „Všeobecné“

Obrázok 2. Vlastnosti SQL "Rozšírené"

Nástroje:

SQL server profiler

Konzola dotazov 1C

Žiadosť o test:

VYBERTE SI

AK.Name AS Názov

OD

Register informácií Klasifikátor adresy AS AK

VNÚTORNÉ SPOJENIE Register informácií Klasifikátor adresy AS AK1

SW AK.Code = AK1.Code

Príprava:

Spustíme SQL server Profiler, vytvoríme spojenie, označíme udalosti a stĺpce, ako je znázornené na obrázku 3.

Obrázok 3. Vlastnosti stopy

Nastavenie výberu pre našu základňu

Obrázok 4. Filter podľa databázy

skratky:

Maximálny stupeň paralelizmu - MDOP

Hranica nákladov pre paralelizmus - náklady

Testovanie plánu sekvenčných dotazov (MDOP = 1)

Obrázok 5. Konzola dotazu – čas vykonania 20 sekúnd

Parameter servera SQL „Maximálny stupeň paralelizmu“ je nastavený na 1 (žiadny paralelizmus). Výsledok si pozrieme v profilovači (obr. 6)

Obrázok 6. Plán sekvenčných dotazov

SQL server vygeneroval sekvenčný plán dotazov, pričom: celkové zaťaženie procesora = 6,750 (s) a čas vykonania dotazu = 7,097 (s)

Testovanie plánu paralelných dotazov (MDOP = 0, cena = 5)

Uviedli sme SQL server do režimu paralelizmu (v SQL Query):

USE master;

EXEC sp_configure "zobraziť rozšírenú možnosť" , 1;

ZNOVU NAKONFIGURUJTE POMOCOU PREPISU

USE master;

exec sp_configure "maximálny stupeň paralelizmu" , 0;

ZNOVU NAKONFIGURUJTE POMOCOU PREPISU

Vykonanie rovnakého dotazu (obrázok 7)

Obrázok 7. Konzola dotazu – čas vykonania 16 sekúnd

Kontrola výsledku v profilovači (obrázok 8)

Obrázok 8. Plán paralelných dotazov

SQL server tentoraz vytvoril plán paralelných dotazov s celkovým zaťažením procesora = 7,905 sekundy a trvaním dotazu = 3,458 sekundy

Testovanie plánu sekvenčných dotazov (MDOP = 0, cena = 150)

Skúsme sa zbaviť paralelného plánu pomocou parametra "Cost prah pre paralelizmus". Štandardne je parameter nastavený na 5. V našom prípade sa nám podarilo zbaviť sa vytvárania paralelného plánu s hodnotou 150 (v SQL Query):

USE master;

exec sp_configure "prah nákladov pre paralelizmus", 150 ;

Vybavenie požiadavky kontrolujeme v týchto podmienkach (obr. 9)

Obrázok 9. Konzola dotazu – čas vykonania 20 sekúnd

Výsledok skontrolujeme v profileri (obr. 10)

Obrázok 10. Plán sekvenčných dotazov.

SQL Server vygeneroval sekvenčný plán dotazov. Celkové využitie procesora = 7,171 s, čas vykonania dotazu = 7,864 s.

Závery:

Vykonanie testovacieho dotazu v prostredí 1C Enterprise pomocou plánu paralelných dotazov SQL servera poskytuje výrazné zvýšenie výkonu v porovnaní so sekvenčným plánom (16 sekúnd vs. 20 sekúnd – zisk 4 sekundy)

Spustenie testovacieho dotazu samotným SQL Serverom pri použití paralelného plánu dotazov je dvakrát rýchlejšie ako pri použití sériového plánu dotazov (3,5 sekundy oproti 7,1 sekundám)

Paralelizmus SQL servera je možné upraviť nielen pomocou parametra MDOP, ale aj parametra „Сost threshold for parallelism“

• tutoriál

Táto príručka je určená pre začiatočníkov, ktorí hľadajú jednoduchú príručku v ruštine na inštaláciu anglickej verzie SQL Server 2012, ktorá sa bude používať pre SharePoint 2013.
Tento článok nie je pre profesionálov.

Všetky práce sú rozdelené do 3 etáp:

• Inštalácia SQL Server 2012
• Nastavenie možnosti konfigurácie servera maximálneho stupňa paralelizmu
• Konfigurácia práv účtu určeného na inštaláciu SharePointu 2013

Článok tiež popisuje proces inštalácie Microsoft .NET Framework 3.5 na MS Windows Server 2012 R2 Standard.

Pozor: pod rezom je veľa obrázkov!

Inštalácia SQL Server 2012

1. Pred inštaláciou by ste sa mali uistiť, že na pevnom disku je dostatok voľného miesta (v mojom prípade to trvalo 2,7 GB).
Po spustení distribučnej súpravy vyberte položku " Inštalácia" v ľavom menu a potom "kliknite" na položku " Nový samostatný SQL Server alebo pridanie funkcií do existujúcej inštalácie":

2. Spustí sa sprievodca inštaláciou. Ten skontroluje. Môžete kliknúť na tlačidlo „Zobraziť podrobnosti“ a zobraziť podrobnú správu:

3. Podrobná správa. Stlačte tlačidlo "OK":

4. Zadajte kód Product Key a kliknite na tlačidlo „Ďalej“:

5. Súhlasíme s podmienkami licenčnej zmluvy.
Ak to chcete urobiť, začiarknite políčko Súhlasím s licenčnými podmienkami

6. V kroku "Nastaviť rolu" vyberte prvú položku " Inštalácia funkcie SQL Server". Stlačte tlačidlo "Ďalej":

7. V kroku „Výber funkcie“ začiarknite políčko „ Služby databázového stroja", "Nástroje na správu-Základné"A" Nástroje na správu – kompletné". Potom kliknite na tlačidlo "Ďalej":

8. Inštalátor potom vykoná ďalšiu kontrolu. Môžete kliknúť na tlačidlo „Zobraziť podrobnosti“ a zobraziť podrobnú správu:

9. Podrobná správa. (V tejto fáze som dostal chybu v pravidle "Microsoft .NET Framework 3.5 je nainštalovaný ...". Viac o tom nižšie). Stlačte tlačidlo "Ďalej":

10. V kroku "Konfigurácia inštancie" musíte nakonfigurovať inštanciu služby SQL Server.
Tento článok je opäť pre začiatočníkov. Preto budeme predpokladať, že SQL Server ešte nebol na vašom serveri nainštalovaný, čo znamená, že ponecháme všetky predvolené nastavenia. Stlačte tlačidlo "Ďalej":

11. V tomto kroku sprievodca inštaláciou zobrazí požiadavky na miesto na disku. Stlačte tlačidlo "Ďalej":

12. V kroku „Konfigurácia servera“ musíte zadať doménový účet pre službu „ Databázový stroj SQL Server". Po vyplnení polí "Názov účtu" a "Heslo" kliknite na tlačidlo "Ďalej":

13. V kroku "Konfigurácia databázového stroja" stačí pridať aktuálneho užívateľa medzi administrátorov SQL servera. Ak to chcete urobiť, kliknite na tlačidlo „Pridať aktuálneho používateľa“ a potom kliknite na tlačidlo „Ďalej“:

14. V ďalšom kroku kliknite na tlačidlo „Ďalej“:

15. Ďalej sprievodca inštaláciou znova vykoná test a zobrazí jeho výsledky. Stlačte tlačidlo "Ďalej":

16. V kroku „Pripravené na inštaláciu“ sprievodca zobrazí súhrnné informácie. Tu musíte kliknúť na tlačidlo "Inštalovať":

17. Po dokončení inštalácie sa zobrazia informácie o vykonaných operáciách:

18. Dôrazne odporúčam, aby ste v tejto fáze reštartovali počítač. V niektorých prípadoch (napríklad pri inštalácii Microsoft .NET Framework 3.5) samotný sprievodca inštaláciou zobrazí okno s výzvou na reštartovanie počítača. Nevzdávajte sa.

Nastavenie možnosti konfigurácie servera maximálneho stupňa paralelizmu

Predvolená hodnota pre parameter "Maximálny stupeň paralelnosti" je 0.
SharePoint 2013 vyžaduje, aby toto nastavenie bolo 1.
Dá sa to ľahko opraviť!

1. Behajte Microsoft SQL Server Management Studio(Štart - Všetky programy - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Na obrazovke pripojenia k serveru kliknite na tlačidlo Pripojiť.

3. Kliknite pravým tlačidlom myši na váš server v " Prieskumník objektov"a vyberte" Vlastnosti":

4. V okne vlastností servera, ktoré sa otvorí, v ľavom menu vyberte stránku " Pokročilé" a posuňte zoznam vlastností úplne dole na obrazovke. Nastavte hodnotu parametra " Maximálny stupeň paralelnosti"V 1 a kliknite na tlačidlo "OK":

5. Nezatvárajte SQL Server Management Studio, budeme ho stále potrebovať.

Konfigurácia práv účtu určeného na inštaláciu SharePointu 2013

Účet, pod ktorým bude SharePoint 2013 nainštalovaný, musí byť v SQL Serveri zvýšený.
Odporúča sa, aby tento účet mal nasledujúce úlohy:

• dbcreator
• securityadmin
• verejnosti

1. V SQL Server Management Studio, v " Prieskumník objektov"rozbaliť položku" bezpečnosť". Potom kliknite pravým tlačidlom myši na " Prihlásenia"a vyberte" Nové prihlásenie":

2. Do poľa „Prihlasovacie meno“ zadajte názov domény účtu, pod ktorým plánujete nainštalovať a nakonfigurovať SharePoint 2013.

3. V ľavom menu vyberte stránku " Roly servera“ a skontrolujte roly „dbcreator“ a „securityadmin“ a uistite sa, že rola „verejná“ je už začiarknutá. Potom kliknite na tlačidlo „OK“:

SQL Server je teraz pripravený na inštaláciu SharePointu 2013.

Inštalácia Microsoft .NET Framework 3.5 na MS Windows Server 2012 R2 Standard

V kroku číslo 9 odseku " Inštalácia SQL Server 2012" Zobrazila sa mi chyba: .NET Framework 3.5 nebol nainštalovaný.
Ak chcete vyriešiť tento problém, postupujte takto:

1. Musíte otvoriť konzolu " správca servera".

2. V ľavom menu vyberte položku „Dashboard“.

3. V strede okna kliknite na položku „Pridať roly a funkcie“.

4. V sprievodcovi, ktorý sa otvorí, preskočte krok „Skôr než začnete“.

5. V kroku „Typ inštalácie“ vyberte „ Inštalácia na základe rolí alebo funkcií". Stlačte tlačidlo "Ďalej".

6. V ďalšom kroku ponechajte všetko ako predvolené a kliknite na tlačidlo „Ďalej“.

7. Preskočte krok "Roly servera" kliknutím na tlačidlo "Ďalej".

8. V kroku "Features" zaškrtnite políčko ".NET Framework 3.5 Features". Stlačíme tlačidlo "Ďalej".

9. Po dokončení procesu inštalácie môžete zatvoriť Sprievodcu pridaním rolí a funkcií.

10. Hotovo!

Všetko dobré a pokojné nebo nad hlavou!

P.S. Šťastný deň kozmonautiky!

Tento príspevok sa zameria iba na MS SQL Server. Ak sa chystáte „skúsiť šťastie“ v používaní 1C s Oracle, DB2, Postrgre, tieto informácie vám budú na nič. Musíte však pochopiť, že v 1C sú predovšetkým špecialisti na MS SQL Server. Vďaka úsiliu IBM existujú aj špecialisti na DB2. O dobrom alebo zlom DBMS sa dá hovoriť dlho, jedna vec je dôležitá, „najhladšie“ 1C pracuje so serverom MS SQL. Súdiac podľa najnovších správ „spredu“, práca s DB2 sa stala viac-menej slušnou. Aj keď som mal osobne skúsenosti s nastavením 1C na prácu s DB2 už vo verzii 8.1, všetko tam akosi nebolo veľmi dobré. Každopádne výber iného DBMS treba jednoznačne vyargumentovať - ​​buď možnosťami, ktoré v MS SQL nie sú (klaster s vyvažovaním záťaže, Grid a pod.), alebo financiami (Oracle je už kúpený), resp. platforma (všetko je na linuxe).

Takže, v poradí, čo je potrebné urobiť s MS SQL Server:

1) Nastavte minimálnu a maximálnu pamäť. Minimum je polovica systémovej pamäte. Maximum - systémová pamäť bez 2 GB. Robí sa to cez Management Studio - vo vlastnostiach servera:

2) Ak priorita nie je nastavená na karte "Procesory", musíte ju nastaviť

3) Nastavte maximálny stupeň rovnobežnosti na 1.

4) Zapnite SQL Server Agent, nastavte Database Mail - nie je tam nič ťažké, nebudem to podrobne popisovať.

5) Nastavte plány služieb:
Sú bežné:
a) Aktualizácia štatistík - každé 2 hodiny
b) DBCC FREEPROCCACHE - každé 2 hodiny
Pre každú základňu:
a) Úplná záloha
b) Diferenčné zálohovanie
c) Defragmentácia indexu – každý deň
d) Prestavba indexu – víkendové noci
e) Kontrola integrity databázy – raz za mesiac v noci cez víkendy

6) Odporúčam nastaviť model obnovy ako Jednoduchý pre každú databázu (vo vlastnostiach). Ak nemáte systém 24 hodín denne, 7 dní v týždni a máte menej ako 1 000 používateľov na databázu, neexistuje žiadny klaster prepnutia pri zlyhaní a nepodpísali ste zmluvu SLA, v ktorej sa zaväzujete obnoviť údaje s presnosťou na sekundu v prípade zlyhania akéhokoľvek zariadenia (a nie od času poslednej zálohy), toto odporúčanie by bolo rozumné. V opačnom prípade budete veľmi skoro dlho a horúčkovito premýšľať, kam umiestniť prerastený denník Transakcie

7) Odstráňte databázu tempdb z bežných databáz na iný disk – aj keď to znamená prekonfigurovanie poľa RAID a zníženie jeho výkonu. V opačnom prípade bude môcť 1 používateľ paralyzovať prácu všetkých ostatných. Ak máte namiesto pevného disku hardvérový akcelerátor, potom ho samozrejme nemôžete oddeliť a dať naň tempdb, ale to je len vtedy, ak existuje

8) nainštalujte si nejaký monitorovací nástroj - páči sa mi napríklad spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Otestujte sa pomocou nástroja Microsoft best practice analizer – http://www.microsoft.com/download/en/details.aspx?id=15289 – skvelého nástroja, ktorý vám pomôže nielen s nastaveniami, ale aj s riešením mnohých problémov.

Teraz v skratke, na čo sme to všetko robili:

1) Pamäť. Minimálna hodnota vás jednoducho zachráni pred „závadami“, keď SQL server z nejakého dôvodu, o ktorom vie len on, nevyužíva všetku pamäť, ktorú má k dispozícii. Treba to všetko zjesť! Maximálna hodnota vás ušetrí od swapovania, ak ten istý optimalizátor využitia pamäte servera SQL rozhodne, že by to nebolelo ....

3) Veľmi dôležitý bod - IHMO musí byť nastavený na 1 vo všetkých transakčných systémoch. Po prvé, bráni niektorým zámkom medzi rôznymi procesmi, ktoré sa pokúšajú vykonať 1 požiadavku, a preto nás chráni pred niektorými "čudnými" chybami. Po druhé... 1 "zabíjacia" požiadavka bude môcť prevziať všetky zdroje servera, čo je vo vzťahu k ostatným užívateľom systému trochu nefér.Parameter sám o sebe určuje, koľko procesorových jadier dokáže spracovať 1 požiadavku.

5) O štatistikách a vymazaní procedurálnej vyrovnávacej pamäte - to je "podľa ucha", ale často zabúdame na reindexovanie. Medzitým je tento postup dosť dôležitý, najmä s rastom objemu databázy sa zvyšuje jej dôležitosť. Niekedy sa stratí až 60 % výkonu pri fragmentácii indexu.

7) Ak máte Hardvérový akcelerátor alebo len 2 disky s rôznou rýchlosťou prístupu, odporučil by som porozmýšľať aj nad vyčlenením skupín súborov v databázach a rozdelením jednotlivých tabuliek do rôznych diskových polí s rôznou dobou prístupu. Veď dáte nám za pravdu, že PH „tovar na skladoch“ a referenčná kniha „Uskladnenie doplňujúcich informácií“ sú 2 objekty, ktorých nároky na skladovanie sú zásadne odlišné. Nie je potrebné ukladať všetky súbory a obrázky do databázy na rýchlom poli - môžete ho rozdeliť do samostatného, ​​nie tak rýchlo, ale tam, kde je veľa miesta (a nebojte sa nahrať veľa súbory do databázy neskôr, mimochodom).