Optimalizace nastavení SQL Serveru pro SharePoint

Při nasazení SharePoint Server 2010 nebo 2013 je jedním ze základních stavebních kamenů celé farmy i SQL Server, který nabízí nepřeberné množství konfiguračních položek.

Při nasazení SharePoint Server 2010 nebo 2013 je jedním ze základních stavebních kamenů celé farmy i SQL Server, který nabízí nepřeberné množství konfiguračních položek. Pro optimální výkon celého prostředí je vhodné nastavit některé konfigurační volby tak, aby vyhovovaly právě SharePoint serveru. Mnohdy jsou tyto volby odlišné od těch, které bychom chtěli mít pro jiné produkční systémy, proto je také doporučeno pro nasazení SharePoint serveru mít dedikovaný SQL Server.

Auto Create and Update Statistics

Každá databáze vytvořená na SQL Serveru má několik „auto“ vlastností, které mají vliv na výkon dané aplikace. U všech SharePoint databází (konfigurační, servisní, obsahové) je vhodné nastavit tuto volbu na false, alespoň taková informace je k dispozici na stránce technet.microsoft.com. SharePoint server si řeší údržbu databáze pomocí Healt Analyzer pravidla, které je spouštěno každý den a stará se právě o statistiky na jednotlivých databázích. Toto pravidlo ale pouze volá uloženou proceduru, která není v každé SharePoint databázi a u takových je vhodné nechat tyto volby nastavené na true.

Max Degree of Parallelism

Nastavení MAXDOP na úrovni instance by mělo mít hodnotu 1, která nepovoluje paralelní zpracování dotazů. Výchozí hodnota MAXDOP je nastavena na 0, která neomezuje paralelní zpracování vůbec a na systému s více procesory jsou jednotlivé dotazy (pokud je to vhodné) zpracovány naráz více procesory. To samozřejmě platí například i pro práci s indexy, na které má nastavení MAXDOP stejný vliv. Paralelní práce s indexy je však dostupná pouze u Enterprise edice, u které toto nastavení má vliv na výkon. Některé interní volání SQL kódu obsahují tzv. hinty, které jsou schopné MAXDOP dynamicky pro daný dotaz měnit, takže ve vhodných případech si SharePoint sám mění MAXDOP na vyšší hodnotu, pokud je to výkonově výhodné.

Optimalizace databázových souborů

Základním a minimálním pravidlem je oddělení datových souborů a souborů s transakčními logy na oddělená úložiště, ideálně ještě s oddělenou databází tempdb. Chceme-li ještě dále oddělovat jednotlivé databáze – obsahové, search, servisní – tak velmi záleží na povaze workloadu naší implementace. Je-li SharePoint využíván hlavně pro čtení, pak je vhodné oddělit data v následujícím pořadí na nejrychlejší úložiště

  1. Tempdb + transakční logy
  2. Obsahové databáze
  3. Search databáze
  4. Transakční logy obsahových databází

Je-li naopak prostředí mnohem více používáno pro úpravy dat, sdílení, Office web applications atd pak se nám ideální pořadí mírně mění ve prospěch transakčních logů a to

  1. Tempdb + transakční logy
  2. Transakční logy obsahových databází
  3. Search databáze
  4. Obsahové databáze

U obsahových databází je nutné předem počítat se strategií pro růst samotných databází vzhledem k obsahu jednotlivých kolekcí. V případě menšího množství kolekcí webů je častým řešením použít individuální databáze pro jednotlivé kolekce, nebo alespoň výčet kolekcí, u kterých toto nastavení má smysl vzhledem k předpokládanému růstu. Maximální velikost obsahové databáze je 4TB, a pro archivaci dokumentů může tuto velikost i přesáhnout. Mnohem více než samotná podporovaná velikost obsahové databáze je však strategie pro „Disaster Recovery“. Jsme schopni obnovit takto velkou databázi v krátké době tak, abychom odstranili výpadek tj. nedostupnost několika desítek, či stovek kolekcí? Pro rychlost zálohy a obnovy můžeme použít komprimovaný backup (dostupný již u Standard edice), který nejen sníží velikost samotné zálohy, ale zkrátí i čas pro zálohu a obnovu samotné databáze.

Databáze TempDB

Co se samotné tempdb databáze týká, vhodné úložiště pro temp je RAID10 a také správně zvolené množství souborů pro temp databázi (všechny se stejnou velikostí). U tempdb je také vhodné nastavit přímo velikost jednotlivých souborů, tak by nemusely po každém restartu instance znovu růst. Kolik by vlastně těchto souborů mělo být vytvořeno? U této otázky velmi záleží na samotném systému, povaze zátěže a mnoha dalších faktorech, ale mohli bychom vycházet např. z těchto nastavení

  • Máme-li systém s 8 jádry a méně použijeme tolik souborů, kolik máme k dispozici jader
  • Máme-li jader více, použijeme 8 souborů a případně můžeme přidávat po 4 dále, pokud nám takové nastavení výkonově nedostačuje.

Tato nastavení se týkají pouze datových souborů, log nám postačí jeden.

Více datových souborů můžeme použít i u obsahových databází, ale zde je potřeba dbát na to, že mnohé nástroje pro backup/restore neumí s takto nastavenou databází správně pracovat a je tedy vhodné řešit backup přímo na úrovni SQL serveru.

Závěrem

Tímto výčtem samozřejmě naše možnosti nekončí, v ladění výkonu se dá pokračovat několika dalšími směry. Samozřejmostí by mělo být i řešení pro vysokou dostupnost, ať už AlwaysOn, nebo failover cluster či mirroring. O možnostech pro vysokou dostupnost SQL Serveru vyšel před krátkou dobou seriál, ve kterém jsou jednotlivé možnosti popsány podrobněji.

Marek Chmel, MVP

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.

Témata článku: Microsoft, Jimi, Ono, Sharepoint, Logo, Search, Tempo

Určitě si přečtěte

Špičkoví hackeři útočili na prohlížeče. Chrome odolal, ale Edge je tragédie

Špičkoví hackeři útočili na prohlížeče. Chrome odolal, ale Edge je tragédie

** Do Vancouveru se sjeli hackeři ** Soutěžili v útocích na prohlížeče ** Chrome odolal, ale Edge to projel na celé čáře

22.  3.  2017 | Jakub Čížek | 79

Pojďme programovat elektroniku: Meteostanice, která bude díky Sigfoxu posílat stav počasí třeba z vrcholu Sněžky

Pojďme programovat elektroniku: Meteostanice, která bude díky Sigfoxu posílat stav počasí třeba z vrcholu Sněžky

** Příští roky budou ve znamení internetu věcí ** Podívali jsme se podrobně na síť Sigfox ** Takhle s ní komunikují krabičky z celé Evropy

19.  3.  2017 | Jakub Čížek | 18

Kde nejlevněji uložit 1 TB dat: Srovnali jsme aktuální ceny cloudových úložišť

Kde nejlevněji uložit 1 TB dat: Srovnali jsme aktuální ceny cloudových úložišť

** Srovnali jsme známá cloudová úložiště podle toho, kolik měsíčně zaplatíte za 1TB ** Ceny se pohybují od dvou stovek až po tisíc korun ** Google umožní uložit až 30 TB dat

18.  3.  2017 | Stanislav Janů | 115

Obří Mechroboti jsou realitou, měří čtyři metry a mají hmotnost přes 1,5 tuny

Obří Mechroboti jsou realitou, měří čtyři metry a mají hmotnost přes 1,5 tuny

** Jihokorejská společnost Hankook Mirae Technology vyrábí obří Mechroboty ** Jsou určené pro ovládání člověkem uvnitř ** V prodeji se objeví koncem tohoto roku za 200 milionů korun

20.  3.  2017 | Karel Javůrek | 18

Google představil nový Android O. Na co se můžeme těšit?

Google představil nový Android O. Na co se můžeme těšit?

** Google vypustil vývojářskou verzi nového Androidu ** Přinese lepší notifikace nebo prodlouženou výdrž ** K uživatelům se dostane na podzim

22.  3.  2017 | Stanislav Janů | 60


Aktuální číslo časopisu Computer

Supertéma o počítačové bezpečnosti

AMD Ryzen přichází

Velké testy kinoprojektorů a levných sluchátek

Příslušenství do USB-C