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 na SQL Serveru 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ě

Tempdb + transakční logy
Obsahové databáze
Search databáze
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

Tempdb + transakční logy
Transakční logy obsahových databází
Search databáze
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, což jsou témata, o kterých jsme již psali.