Aspekty návrhu SQL Serveru

System Center Operations Manager vyžaduje přístup k instanci serveru se spuštěnou službou Microsoft SQL Server kvůli podpoře provozní databáze, databáze auditu datového skladu a služby ACS. Provozní databáze a databáze datového skladu jsou povinné a vytvoří se, když do skupiny pro správu nasadíte první server pro správu. Databáze ACS se vytvoří při nasazení kolekce služby ACS ve skupině pro správu.

V testovacím prostředí nebo nasazení Operations Manageru menšího rozsahu může být SQL Server společně umístěný na prvním serveru pro správu ve skupině pro správu.

U distribuovaného nasazení střední až podnikové úrovně by měla být instance SQL Serveru umístěná na vyhrazeném samostatném serveru nebo ve vysoce dostupné konfiguraci SQL Serveru. V obou případech musí SQL Server existovat a být přístupný ještě před spuštěním instalace prvního serveru pro správu nebo kolekce služby ACS.

Nedoporučujeme používat databáze Operations Manageru z instance SQL, která má jiné databáze aplikací. Tím se zabrání potenciálním problémům se vstupně-výstupními operacemi a dalšími omezeními hardwarových prostředků.

Důležité

Operations Manager nepodporuje instance SQL typu Platforma jako služba (PaaS), včetně produktů, jako je Azure SQL Managed Instance nebo Amazon Relational Database Service (AWS RDS). Použijte instanci SQL Server nainstalovanou na počítači s Windows. Jedinou výjimkou je spravovaná instance Azure MonitorU SCOM, která využívá Azure SQL MI a nedá se překonfigurovat.

Požadavky na systém SQL Server

Následující verze SQL Server Enterprise & Standard Edition jsou podporovány pro stávající instalaci verze nástroje System Center Operations Manager pro hostování serveru sestav, provozního serveru, Data Warehouse a databáze služby ACS:

• SQL Server 2022

• SQL Server 2019 s kumulativní aktualizací 8 (CU8) nebo novější, jak je podrobně popsáno tady

  Poznámka

  • Operations Manager 2022 podporuje SQL 2019 s CU8 nebo novější. nepodporuje ale SQL 2019 RTM.
  • Použijte rozhraní ODBC 17.3 nebo novější a MSOLEDBSQL 18.2 nebo novější.

• SQL Server 2017 a kumulativní Aktualizace, jak je podrobně popsáno tady

Před upgradem SQL Server si projděte informace o upgradu pro verzi 2017 a informace o upgradu pro SQL 2019.

Poznámka

• Každá z následujících SQL Server komponent podporujících infrastrukturu SCOM musí být ve stejné SQL Server hlavní verzi:
  • SQL Server instancí databázového stroje, které hostují některou z databází SCOM (to znamená databáze ReportServer operationsManager, OperationManagerDW a SSRS & ReportServerTempDB).
  • instance SQL Server Reporting Services (SSRS).
• Nastavení SQL Server kolace musí být jedním z podporovaných typů, jak je popsáno v části nastavení kolace SQL Server níže.
• SQL Server fulltextové vyhledávání je vyžadováno pro všechny instance databázového stroje SQL Server, které hostují některou z databází SCOM.
• Možnosti instalace Windows Server 2016 (Jádro serveru, Server s desktopovým prostředím a Nano Server) podporované databázovými komponentami Operations Manageru vycházejí z toho, jaké možnosti instalace Windows Serveru SQL Server podporují.

Poznámka

Generování sestav nástroje System Center Operations Manager nelze nainstalovat souběžně s předchozí verzí role generování sestav a musí být nainstalováno pouze v nativním režimu (integrovaný režim SharePointu se nepodporuje).

Při plánování návrhu je potřeba vzít v úvahu další požadavky na hardware a software:

• Doporučujeme spustit SQL Server na počítačích s formátem souborů NTFS.
• Musí být k dispozici alespoň 1 024 MB volného místa na disku pro provozní databázi a databázi datového skladu. Vynucuje se při vytváření databáze a po nastavení se pravděpodobně výrazně zvýší.
• Vyžaduje se rozhraní .NET Framework 4.
• Rozhraní .NET Framework 4.8 je podporováno v nástroji Operations Manager 2022.
• Server pro sestavy se v jádru Windows Serveru nepodporuje.

Další informace najdete v tématu Požadavky na hardware a software pro instalaci SQL Server.

Poznámka

I když Operations Manager během instalace používá pouze ověřování windows, nastavení ověřování sql ve smíšeném režimu bude fungovat i v případě, že žádný místní účet nemá db_owner roli. O místních účtech s rolí db_owner je známo, že způsobují problémy s nástrojem System Center Operations Manager. Před instalací produktu odeberte roli db_owner ze všech místních účtů a po instalaci nepřidávejte roli db_owner do žádného z místních účtů.

Nastavení kolace SQL Serveru

System Center Operations Manager podporuje následující kolace SQL Server a Windows.

Poznámka

Abyste se vyhnuli problémům s kompatibilitou při porovnávání nebo kopírování operací, doporučujeme použít stejnou kolaci pro databázi SQL a Operations Manager.

Kolace SQL Serveru

• SQL_Latin1_General_CP1_CI_AS

Kolace systému Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Pokud vaše instance SQL Server není nakonfigurovaná s jednou z podporovaných kolací uvedených výše, provedení nového nastavení nástroje Operations Manager se nezdaří. Místní upgrade se ale provede úspěšně.

Konfigurace brány firewall

Operations Manager je závislý na SQL Serveru, který hostí jeho databáze a platformu sestav za účelem analýzy a prezentace historických provozních dat. Role serveru pro správu, operations a webové konzoly musí být schopné úspěšně komunikovat s SQL Server a je důležité porozumět komunikační cestě a portům, aby bylo možné správně nakonfigurovat vaše prostředí.

Pokud navrhujete distribuované nasazení, které bude vyžadovat, aby skupiny dostupnosti SQL AlwaysOn poskytovaly funkce převzetí služeb při selhání pro databáze Operations Manageru, je potřeba do strategie zabezpečení brány firewall zahrnout další nastavení konfigurace brány firewall.

Následující tabulka vám pomůže určit porty brány firewall vyžadované SQL Serverem, které je potřeba minimálně povolit, aby mohly role serveru ve skupině pro správu Operations Manageru úspěšně komunikovat.

Scenario	Port	Směr	Role Operations Manageru
SQL Server hostující databáze Operations Manageru	TCP 1433 *	Příchozí	server pro správu a webová konzola (pro Application Advisor a Application Diagnostics)
Služba SQL Server Browser	UDP 1434	Příchozí	management server
Vyhrazené připojení správce SQL Serveru	TCP 1434	Příchozí	management server
Další porty používané SQL Server – Vzdálená volání procedur Microsoftu (MS RPC) – Rozhraní WMI (Windows Management Instrumentation) – Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Příchozí	management server
Naslouchací proces skupiny dostupnosti AlwaysOn SQL Serveru	Port konfigurovaný správcem	Příchozí	management server
SQL Server Reporting Services hostující server pro sestavy Operations Manageru	TCP 80 (výchozí)/443 (SSL)	Příchozí	server pro správu a konzola Operations Console

* Zatímco tcp 1433 je standardní port pro výchozí instanci databázového stroje, když vytvoříte pojmenovanou instanci na samostatném SQL Server nebo nasadíte skupinu dostupnosti SQL AlwaysOn, bude definován vlastní port a měl by být zdokumentován pro referenci, abyste správně nakonfigurovali brány firewall a zadali tyto informace během instalace.

Podrobnější přehled požadavků na bránu firewall pro SQL Server najdete v tématu Konfigurace brány Windows Firewall tak, aby umožňovala přístup SQL Server.

Důležité informace o kapacitě a úložišti

Databáze nástroje Operations Manager

Databáze Operations Manageru je databáze SQL Serveru obsahující veškerá data potřebná pro každodenní monitorování Operations Managerem. Velikost a konfigurace databázového serveru jsou pro celkový výkon skupiny pro správu kriticky důležité. Nejdůležitějším prostředkem používaným databází Operations Manageru je subsystém úložiště. Důležitý je ale i procesor a paměť RAM.

Mezi faktory ovlivňující zatížení databáze Operations Manageru patří:

• Frekvence shromažďování provozních dat Provozní data tvoří veškerá data událostí, výstrah, změn stavu a výkonu shromážděná agenty. Většina prostředků používaných databází Operations Manageru se používá k zápisu těchto dat na disk po jejich vstupu do systému. Frekvence shromažďovaných provozních dat se obvykle zvyšuje s rostoucím počtem dalších importovaných sad Management Pack a dalších přidaných agentů. Při zjišťování celkové frekvence kolekce provozních dat je důležitým faktorem i typ počítače monitorovaného agentem. Například je pravděpodobné, že agent monitorující důležitý podnikový stolní počítač shromáždí méně dat než agent monitorující server, na kterém běží instance SQL Serveru s velkým počtem databází.
• Frekvence změn prostoru instancí Aktualizace těchto dat v databázi Operations Manageru je vzhledem k zápisu nových provozních dat nákladná. Když se navíc změní data prostoru instancí, odešlou servery pro správu databází Operations Manageru další dotazy, aby se vypočítaly změny konfigurace a skupiny. Frekvence změn prostoru instancí se zvyšuje při importu dalších sad Management Pack do skupiny pro správu. Přidáním nových agentů do skupiny pro správu se také dočasně zvýší frekvence změn prostoru instancí.
• Počet konzol Operations Console a dalších současně běžících připojení SDK Každá konzola Operations Console čte data z databáze Operations Manageru. Dotazování na tato data spotřebovává potenciálně velké objemy vstupně-výstupních prostředků úložiště, čas procesoru a paměť RAM. Konzoly Operations Console, které v zobrazení událostí, zobrazení stavu, zobrazení výstrah a zobrazení dat výkonu zobrazují velké objemy provozních dat, způsobují často největší zatížení databáze.

Databáze Operations Manageru je jediným zdrojem selhání skupiny pro správu, proto ji můžete nastavit na vysokou dostupnost pomocí podporovaných konfigurací převzetí služeb při selhání, jako jsou třeba skupiny dostupnosti AlwaysOn SQL Serveru nebo instance clusteru s podporou převzetí služeb při selhání.

Databáze Operations Manageru můžete nastavit a upgradovat s existujícím nastavením sql Always-On bez nutnosti jakýchkoli změn po konfiguraci.

Povolení služby SQL Broker v databázi Operations Manageru

System Center Operations Manager při implementaci všech operací úloh závisí na SQL Server Service Brokeru. Pokud je SQL Server Service Broker zakázaný, ovlivní to všechny operace úloh. Výsledné chování se může lišit v závislosti na úkolu, který je zahájen. Proto je důležité zkontrolovat stav služby SQL Server Service Broker vždy, když se kolem úlohy v nástroji System Center Operations Manager zaznamená neočekávané chování.

Chcete-li povolit SQL Server Service Broker, postupujte takto:

1. Spusťte následující dotaz SQL:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Tento krok přeskočte, pokud je hodnota zobrazená v is_broker_enabled poli 1 (jedna). Jinak spusťte následující dotazy SQL:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Databáze datového skladu nástroje Operations Manager

System Center – Operations Manager vkládá data do datového skladu vykazovaných sestav téměř v reálném čase. Je důležité mít na tomto serveru dostatečnou kapacitu, která podporuje zápis všech shromažďovaných dat do datového skladu vykazovaných sestav. Stejně jako u databáze Operations Manageru je i u datového skladu vykazovaných sestav nejdůležitějším prostředkem vstupně-výstupní subsystém úložiště. Ve většině systémů se zatížení datového skladu pro sestavy podobá databázi Operations Manageru, ale můžou se lišit. Zatížení datového skladu vykazovaných sestav vzniklé vykazováním sestav se navíc liší od zatížení databáze Operations Manageru způsobeného využitím konzoly Operations Console.

Mezi faktory, které ovlivňují zatížení datového skladu vykazovaných sestav, patří:

• Frekvence shromažďování provozních dat Datový sklad vykazovaných sestav vypočítává a ukládá kromě omezeného objemu nezpracovaných dat i agregovaná data, aby tak umožnil efektivnější vykazování sestav. Tato práce navíc znamená, že shromažďování provozních dat do datového skladu vykazovaných sestav může být trochu nákladnější než použití databáze Operations Manageru. Tyto dodatečné náklady obvykle vyrovnají snížené náklady na zpracování dat zjišťování datového skladu vykazování sestav ve srovnání s databází Operations Manageru.
• Počet souběžných uživatelů vytváření sestav nebo naplánovaných generování sestav Vzhledem k tomu, že sestavy často shrnují velké objemy dat, může každý uživatel vytváření sestav systém významně zatížit. Počet současně spuštěných sestav a typ spuštěných sestav ovlivňují celkové nároky na kapacitu. Obecně platí, že sestavy, které se dotazují na velké rozsahy dat nebo velký počet objektů, vyžadují další systémové prostředky.

Na základě těchto faktorů existuje několik doporučených postupů, které je potřeba zvážit při nastavování velikosti datového skladu vykazovaných sestav:

• Vyberte vhodný subsystém úložiště. Vzhledem k tomu, že datový sklad vykazovaných sestav je nedílnou součástí celkového toku dat ve skupině pro správu, je výběr vhodného subsystému úložiště pro datový sklad vykazovaných sestav důležitý. Stejně jako u databáze Operations Manageru je často nejlepší volbou RAID 0 + 1. Obecně platí, že subsystém úložiště pro datový sklad vykazovaných sestav by měl být podobný subsystému úložiště pro databázi Operations Manageru a že pokyny pro databázi Operations Manageru jsou platné i pro datový sklad vykazovaných sestav.
• Zvažte vhodné umístění protokolu dat a transakčního protokolu. Pokud jde o databázi Operations Manageru, oddělení dat SQL a transakčních protokolů je často vhodnou volbou při vertikálním navýšení počtu agentů. Pokud jsou databáze Operations Manageru a datový sklad vykazovaných sestav umístěné na stejném serveru, a vy chcete oddělit protokoly dat od protokolů transakcí, musíte protokoly transakcí pro databázi Operations Manageru umístit na fyzický svazek a jednotky disku oddělené od datového skladu vykazovaných sestav, aby to mělo nějaký vliv. Datové soubory pro databázi Operations Manageru a datový sklad vykazovaných sestav můžou sdílet stejný fyzický svazek, pokud svazek poskytuje odpovídající kapacitu a výkon vstupně-výstupních operací disku nemá negativní vliv na funkce monitorování a vytváření sestav.
• Zvažte umístění datového skladu vykazovaných sestav na samostatný server oddělený od databáze Operations Manageru. I když menší nasazení můžou často konsolidovat databázi Operations Manageru a datový sklad sestav na stejném serveru, je výhodné je oddělit při vertikálním navýšení počtu agentů a objemu příchozích provozních dat. Pokud jsou datový sklad pro sestavy a server pro sestavy na jiném serveru než databáze Operations Manageru, dosáhnete lepšího výkonu generování sestav.

Databáze datového skladu Operations Manageru je jediným zdrojem selhání skupiny pro správu, proto ji můžete nastavit na vysokou dostupnost pomocí podporovaných konfigurací převzetí služeb při selhání, jako jsou třeba skupiny dostupnosti AlwaysOn SQL Serveru nebo instance clusteru s podporou převzetí služeb při selhání.

AlwaysOn SQL Serveru

Skupiny dostupnosti AlwaysOn SQL Serveru podporují prostředí převzetí služeb při selhání pro samostatnou sadu uživatelských databází (databází dostupnosti). Každá sada databází dostupnosti je hostovaná na replice dostupnosti.

V nástroji System Center 2016 a novějším – Operations Manageru se kvůli zajištění vysoké dostupnosti pro databáze upřednostňuje sql server AlwaysOn před clusteringem s podporou převzetí služeb při selhání. Veškeré databáze, kromě instalace služby Reporting Services v nativním režimu používající k oddělení úložiště trvalých dat od dočasného úložiště dvě databáze, se dají hostovat ve skupině dostupnosti AlwaysOn.

Pomocí nástroje Operations Manager 2022 můžete nastavit a upgradovat databáze Operations Manageru s existujícím nastavením sql Always-On, aniž byste museli provádět změny po konfiguraci.

Pokud chcete nastavit skupinu dostupnosti, budete muset nasadit cluster Clustering s podporou převzetí služeb při selhání Windows Serveru (WSFC) pro hostování repliky dostupnosti a povolit na uzlech clusteru funkci AlwaysOn. Potom můžete databázi nástroje SQL Server Operations Manager přidat jako databázi dostupnosti.

• Přečtěte si další informace o požadavcích na alwaysOn.
• Přečtěte si další informace o nastavení služby WSFC pro skupiny dostupnosti AlwaysOn.
• Přečtěte si další informace o nastavení skupiny dostupnosti.

Poznámka

Po nasazení Nástroje Operations Manager na uzlech SQL Serveru, které se účastní sql serveru AlwaysOn, povolte striktní zabezpečení CLRspuštěním skriptu SQL pro každou databázi Operations Manageru.

Řetězec s více podsítěmi

Operations Manager nepodporuje připojovací řetězec klíčových slov (MultiSubnetFailover=True). Vzhledem k tomu, že skupina dostupnosti má název naslouchacího procesu (označovaný jako název sítě nebo klientský přístupový bod ve Správci clusteru služby WSFC) v závislosti na několika IP adresách z různých podsítí, například při nasazení v konfiguraci převzetí služeb při selhání mezi lokalitami, požadavky na připojení klienta ze serverů pro správu do naslouchacího procesu skupiny dostupnosti naslouchacímu procesu naslouchacímu procesu skupiny dostupnosti narazí na časový limit připojení.

Pokud jste nasadili uzly serveru ve skupině dostupnosti v prostředí s více podsítěmi, doporučujeme toto omezení obejít takto:

1. Nastavte síťový název naslouchacího procesu skupiny dostupnosti tak, aby v DNS registrovali jenom jednu aktivní IP adresu.
2. Nakonfigurujte cluster tak, aby pro zaregistrovaný záznam DNS používal nízkou hodnotu TTL.

Tato nastavení umožňují při převzetí služeb při selhání na uzel v jiné podsíti rychlejší obnovení a překlad názvu clusteru s novou IP adresou.

Na libovolném uzlu SQL spusťte následující příkazy PowerShellu a upravte jeho nastavení:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Pokud používáte AlwaysOn s názvem naslouchacího procesu, měli byste tyto změny konfigurace provést také v naslouchacím procesu. Další informace o konfiguraci naslouchacího procesu skupiny dostupnosti najdete v této dokumentaci: Konfigurace naslouchacího procesu skupiny dostupnosti – SQL Server AlwaysOn

Na uzlu SQL, který je aktuálně hostitelem naslouchacího procesu, spusťte následující příkazy PowerShellu a upravte jeho nastavení:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Pokud se clusterová instance SQL nebo instance SQL alwaysOn používá k zajištění vysoké dostupnosti, měli byste na serverech pro správu povolit funkci automatického obnovení, abyste zabránili restartování služby Přístup k datům nástroje Operations Manager pokaždé, když dojde k převzetí služeb při selhání mezi uzly. Informace o tom, jak to nakonfigurovat, najdete v následujícím článku znalostní báze System Center Management přestane reagovat, jakmile instance SQL Server přejde do režimu offline.

Optimalizace SQL Serveru

Obecně platí, že předchozí zkušenosti se zákazníky s nasazením ukazují, že problémy s výkonem obvykle nejsou způsobené vysokým využitím prostředků (tj. procesoru nebo paměti) s vlastním SQL Server, ale přímo souvisí s konfigurací subsystému úložiště. Kritickým bodům výkonu se obvykle přičítá nedodržování doporučených pokynů ke konfiguraci úložiště zřízeného pro instanci SQL Server databáze. Mezi příklady patří:

• Nedostatečné přidělení jednotek pro logické jednotky (LUN), které by zajistily podporu vstupně-výstupních požadavků Operations Manageru.
• Hostování protokolů transakcí a databázových souborů na stejném svazku. Tyto dvě úlohy mají různé charakteristiky vstupně-výstupních operací a latence.
• Konfigurace databáze TempDB je nesprávná s ohledem na umístění, velikost atd.
• Chybné zarovnání svazků na diskových oddílech, které hostují protokoly transakcí databáze, databázové soubory a databázi TempDB.
• Přehlédnutí základní konfigurace SQL Server, jako je použití funkce AUTOGROW pro soubory databázového a transakčního protokolu, nastavení MAXDOP pro paralelismus dotazů, vytvoření více datových souborů TempDB na jádro procesoru atd.

Konfigurace úložiště je jednou z nejdůležitějších součástí nasazení SQL Serveru pro Operations Manager. Databázové servery bývají s ohledem na precizní aktivity čtení a zápisu databáze a zpracování transakčního protokolu často silně vázané na vstupně-výstupní operace. V/V chování Operations Manageru je obvykle 80 % zápisů a 20 % čtení. V důsledku toho může nesprávná konfigurace subsystémů vstupně-výstupních operací vést k nízkému výkonu a provozu SQL Server systémů a v Operations Manageru se stává nápadnou.

Před nasazením SQL Server je důležité otestovat návrh SQL Server provedením testování propustnosti vstupně-výstupního subsystému. Ujistěte se, že tyto testy dokážou dosáhnout vašich požadavků na vstupně-výstupní operace s přijatelnou latencí. Pomocí nástroje Diskspd vyhodnoťte vstupně-výstupní kapacitu subsystému úložiště podporujícího SQL Server. Následující blogový článek, který vytvořil člen týmu souborového serveru v produktové skupině, obsahuje podrobné pokyny a doporučení k provádění zátěžového testování pomocí tohoto nástroje s kódem PowerShellu a zachycení výsledků pomocí nástroje PerfMon. Počáteční pokyny najdete také v tématu Pomocná rutina pro určení velikosti nástroje Operations Manager .

Velikost alokační jednotky NTFS

Zarovnání svazku, obvykle označované jako zarovnání sektorů, by se na systému souborů (NTFS) mělo provádět při každém vytvoření svazku na zařízení RAID. Pokud to neuděláte, může to vést k výraznému snížení výkonu a je to nejčastěji výsledkem chybného zarovnání oddílů s hranicemi proužek jednotek. Může také vést k chybnému zarovnání mezipaměti hardwaru, což vede k neefektivnímu využití mezipaměti pole. Při formátování oddílu, který se použije pro SQL Server datových souborů, se doporučuje pro data, protokoly a databázi tempdb použít velikost alokační jednotky 64 kB (tj. 65 536 bajtů). Mějte ale na paměti, že použití velikosti alokačních jednotek větších než 4 kB vede k nemožnosti použít kompresi NTFS na svazku. I když SQL Server na komprimovaných svazcích podporuje data jen pro čtení, nedoporučuje se.

Vyhrazení paměti

Poznámka

Většina informací v této části pochází od Jonathana Kehayias v jeho blogovém příspěvku How much memory does my SQL Server actually need? (sqlskills.com)

Není vždy snadné určit správné množství fyzické paměti a procesorů, které je potřeba přidělit pro SQL Server v rámci podpory nástroje System Center Operations Manager (nebo pro jiné úlohy mimo tento produkt). Kalkulačka velikosti poskytovaná produktovou skupinou poskytuje pokyny na základě škálování úloh, ale její doporučení jsou založená na testování provedeném v testovacím prostředí, které může nebo nemusí odpovídat vašemu skutečnému zatížení a konfiguraci.

SQL Server umožňuje nakonfigurovat minimální a maximální velikost paměti, která bude rezervována a používána jejím procesem. SQL Server může ve výchozím nastavení dynamicky měnit své požadavky na paměť v závislosti na dostupných systémových prostředcích. Výchozí nastavení minimální paměti serveru je 0 a výchozí nastavení maximální paměti serveru je 2 147 483 647 MB.

Pokud nenastavíte odpovídající hodnotu pro maximální paměť serveru, může dojít k problémům souvisejícím s výkonem a pamětí. Množství paměti, které je potřeba přidělit SQL Server, ovlivňuje mnoho faktorů, aby se zajistilo, že operační systém může podporovat jiné procesy spuštěné v tomto systému, jako je karta HBA, agenti pro správu a antivirová kontrola v reálném čase. Pokud není nastavený dostatek paměti, operační systém a SQL budou stránkovat na disk. To může způsobit zvýšení vstupně-výstupních operací disku, další snížení výkonu a vytvoření efektu zvlnění tam, kde je to patrné v Nástroji Operations Manager.

Pro minimální paměť serveru doporučujeme zadat alespoň 4 GB paměti RAM. To by se mělo provést pro každý uzel SQL, který hostuje některou z databází Operations Manageru (provozní databáze, datový sklad, ACS).

Pro maximální paměť serveru doporučujeme nejprve rezervovat:

• 1 GB paměti RAM pro operační systém
• 1 GB paměti RAM na každý 4 GB nainstalované paměti RAM (až 16 GB paměti RAM)
• 1 GB paměti RAM na každých 8 GB nainstalované paměti RAM (nad 16 GB paměti RAM)

Po nastavení těchto hodnot monitorujte čítač Paměť\Dostupné mby ve Windows a zjistěte, jestli můžete zvětšit paměť dostupnou pro SQL Server. Systém Windows signalizuje, že při 96 MB dochází k nedostatku dostupné fyzické paměti, takže v ideálním případě by čítač neměl běžet nižší než přibližně 200–300 MB, aby se zajistilo, že máte vyrovnávací paměť. U serverů s 256 GB paměti RAM nebo vyšší budete pravděpodobně chtít zajistit, aby nespadly do 1 GB.

Mějte na paměti, že tyto výpočty předpokládají, že chcete, aby SQL Server mohli využívat veškerou dostupnou paměť, pokud je nezměníte tak, aby byly v úvahu pro jiné aplikace. Zvažte specifické požadavky na paměť pro váš operační systém, jiné aplikace, zásobník vláken SQL Server a další vícestránkové alokátory. Typický vzorec je ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), kde paměť pro zásobník vláken = ((max worker threads) (stack size)). Velikost zásobníku je 512 kB pro systémy x86, 2 MB pro systémy x64 a 4 MB pro systémy IA64. Hodnotu pro maximální počet pracovních vláken najdete ve sloupci max_worker_count sys.dm_os_sys_info.

Tyto aspekty platí také pro požadavky na paměť pro SQL Server ke spuštění ve virtuálním počítači. Vzhledem k tomu, že SQL Server je určená k ukládání dat do mezipaměti ve fondu vyrovnávacích pamětí a obvykle využívá co nejvíce paměti, může být obtížné určit ideální potřebnou velikost paměti RAM. Když snížíte velikost paměti přidělené instanci SQL Server, dostanete se nakonec do bodu, kdy se vymění přidělení menší paměti za vyšší vstupně-výstupní přístup k disku.

Pokud chcete nakonfigurovat SQL Server paměť v prostředí, které bylo nadměrně zřízeno, začněte monitorováním prostředí a aktuálních metrik výkonu, včetně očekávané délky životnosti stránky správce vyrovnávací paměti SQL Server a čtení stránek za sekundu a čtení z disku fyzického disku za sekundu. Pokud má prostředí nadbytečnou paměť, očekávaná délka životnosti stránky se zvýší o hodnotu každou sekundu bez jakéhokoli snížení zatížení, a to kvůli ukládání do mezipaměti; hodnota čtení stránky správce vyrovnávací paměti SQL Server za sekundu bude po zužování mezipaměti nízká a počet čtení z fyzického disku za sekundu zůstane také nízký.

Jakmile porozumíte standardním hodnotám prostředí, můžete snížit maximální velikost paměti serveru o 1 GB a pak zjistit, jak to ovlivní čítače výkonu (jakmile se počáteční vyprazdňování mezipaměti sníží). Pokud jsou metriky stále přijatelné, snižte ho o další 1 GB a znovu monitorujte a opakujte podle potřeby, dokud neurtíte ideální konfiguraci.

Další informace najdete v tématu Možnosti konfigurace paměti serveru.

Optimalizace databáze TempDB

Velikost a fyzické umístění databáze tempdb může mít vliv na výkon Operations Manageru. Pokud je například velikost definovaná pro databázi tempdb příliš malá, může se při každém restartování instance SQL Serveru část zatížení systémového zpracování zahrnout do automatického zvětšování databáze tempdb na velikost požadovanou pro podporu zatížení. Pokud chcete dosáhnout optimálního výkonu databáze tempdb, doporučujeme pro databázi tempdb v provozním prostředí použít následující konfiguraci:

• Model obnovení databáze tempdb nastavte na JEDNODUCHÝ. Tento model automaticky uvolní místo protokolu, aby zachoval požadavky na místo na nízké úrovni.
• Předem přidělte místo pro všechny soubory databáze tempdb tak, že nastavíte velikost souboru na hodnotu dostatečně vysokou, aby obsáhla typické zatížení prostředí. Zabrání tomu, aby se databáze tempdb příliš často rozšiřovala, což může ovlivnit výkon. Databázi tempdb můžete nastavit na automatické zvětšování, toto nastavení by se ale mělo používat ke zvětšení místa na disku pro neplánované výjimky.
• Vytvořte tolik souborů, kolik jich potřebujete k maximalizaci šířky pásma disku. Použití více souborů snižuje kolize v úložišti tempdb a poskytuje lepší škálovatelnost. Nevytvovávejte ale příliš mnoho souborů, protože to může snížit výkon a zvýšit režijní náklady na správu. Obecně je vhodné vytvořit jeden datový soubor pro každý logický procesor na serveru (účtující pro jakékoli nastavení masky spřažení) a pak podle potřeby snížit nebo zvýšit počet souborů. Obecně dále platí, že pokud je počet logických procesorů menší nebo rovný 8, měl by se použít stejný počet datových souborů a logických procesorů. Pokud je počet logických procesorů větší než 8, použijte osm datových souborů a v případě kolizí pak zvyšte počet datových souborů o násobky 4 (až do počtu logických procesorů), dokud se kolize nesníží na přijatelné úrovně nebo provedete změny úlohy nebo kódu. Pokud se kolize nesníží, možná budete muset zvýšit počet datových souborů.
• Vytvořte pro každý datový soubor stejnou velikost, abyste umožnili optimální výkon při proporčním vyplnění. Stejná velikost datových souborů je velmi důležitá, protože algoritmus proporčního vyplnění je založený na velikosti souborů. Pokud vytvoříte soubory, které nejsou stejně velké, pokusí se algoritmus proporčního vyplnění použít největší soubor pro přidělení GAM, místo aby rozložil přidělení mezi všechny soubory. Vytváření více datových souborů pak ztratí smysl.
• Pro zajištění optimálního výkonu umístěte databázi tempdb na rychlý vstupně-výstupní subsystém pomocí jednotek SSD. Pokud máte větší množství připojených disků, použijte prokládání disků.
• Databázi tempdb umístěte na disky, které se liší od disků používaných uživatelskými databázemi.

Pokud chcete databázi tempdb nakonfigurovat, můžete spustit následující dotaz nebo upravit její vlastnosti v aplikaci Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Spuštěním dotazu SELECT * from sys.sysprocesses T-SQL detekujte kolize přidělení stránek pro databázi tempdb. Ve výstupu systémové tabulky se prostředek čekání může zobrazit jako 2:1:1 (stránka PFS) nebo 2:1:3 (stránka mapy sdíleného globálního přidělení). V závislosti na velikosti sporu může dojít k tomu, že se SQL Server bude po krátkou dobu jevit jako nereagující. Další možností je prozkoumání dynamických zobrazení správy [sys.dm_exec_request nebo sys.dm_os_waiting_tasks]. Výsledky ukážou, že tyto požadavky nebo úlohy čekají na prostředky databáze tempdb a mají podobné hodnoty jako dříve zvýrazněné při spuštění dotazu sys.sysprocesses .

Pokud předchozí doporučení výrazně nesnižují kolize přidělení a kolize jsou na stránkách SGAM, implementujte do spouštěcích parametrů pro SQL Server příznak trasování -T1118, aby příznak trasování zůstal v platnosti i po recyklaci SQL Server. SQL Server přidělí v rámci tohoto příznaku trasování každému objektu databáze celý rozsah a eliminuje tak spory na stránkách SGAM.

Poznámka

Tento příznak trasování ovlivňuje každou databázi v instanci SQL Server.

Maximální míra paralelismu

Výchozí konfigurace SQL Serveru pro menší až střední velikosti nasazení Operations Manageru odpovídá většině potřeb. Pokud se však zatížení skupiny pro správu škáluje směrem nahoru směrem ke scénáři podnikové třídy (obvykle se jedná o více než 2 000 systémů spravovaných agentem a pokročilou konfiguraci monitorování, která zahrnuje monitorování na úrovni služeb s pokročilými syntetickými transakcemi, monitorování síťových zařízení, více platforem atd.), je nutné optimalizovat konfiguraci SQL Server popsané v této části dokumentu. Jednou z možností konfigurace, která nebyla popsána v předchozích doprovodných materiálech, je MAXDOP.

Možnost konfigurace maximální míra paralelismu Microsoft SQL Serveru (MAXDOP) řídí počet procesorů, které se používají pro spuštění dotazu v paralelním plánu. Tato možnost určuje výpočetní prostředky a prostředky vlákna, které se používají pro operátory plánu dotazu provádějící paralelní práci. V závislosti na tom, jestli je SQL Server nastavený na počítači se symetrickým multiprocesingem (SMP), počítači NUMA (Non-Uniform Memory Access) nebo procesorech s podporou hyperthreadingu, musíte správně nakonfigurovat možnost maximálního stupně paralelismu.

Pokud SQL Server běží na počítači s více než jedním mikroprocesorem nebo procesorem, zjistí nejvhodnější míru paralelismu, tj. počet procesorů zapojených do spuštění jednoho příkazu pro každé spuštění paralelního plánu. Ve výchozím nastavení je hodnota této možnosti 0, což umožňuje SQL Serveru určit maximální míru paralelismu.

Uložené procedury a dotazy předdefinované v Operations Manageru, protože souvisí s provozní databází, databází datového skladu a dokonce i databáze auditu, nezahrnují možnost MAXDOP, protože během instalace neexistuje způsob, jak dynamicky dotazovat, kolik procesorů je operačnímu systému prezentováno, ani se nepokouší pevně zakódovat hodnotu pro toto nastavení, což by mohlo mít při spuštění dotazu negativní důsledky.

Poznámka

Možnost konfigurace maximálního stupně paralelismu neomezuje počet procesorů, které SQL Server používá. Pokud chcete nakonfigurovat počet procesorů, které SQL Server používá, použijte možnost konfigurace masky spřažení.

• Pro servery používající více než osm procesorů použijte následující konfiguraci: MAXDOP=8.
• Pro servery, které používají osm nebo méně procesorů, použijte následující konfiguraci: MAXDOP=0 až N

  Poznámka

  V této konfiguraci N představuje počet procesorů.