Sdílet prostřednictvím

Aspekty návrhu SQL Serveru

  • Článek

System Center Operations Manager spoléhá na Microsoft SQL Server na podporu svých provozních databází, datových skladů a databází auditu služby ACS. Tyto databáze jsou nezbytné a vytvářejí se během nasazení prvního serveru pro správu nebo kolekce služby ACS ve vaší skupině pro správu.

V testovacím prostředí nebo v nasazení Operations Manageru v malém měřítku lze SQL Server společně přidělit na prvním serveru pro správu ve skupině pro správu.

V distribuovaném nasazení na podnikové úrovni by se instance SQL Serveru měla nacházet na vyhrazeném samostatném serveru nebo v konfiguraci s vysokou dostupností SQL Serveru. V obou případech musí SQL Server již existovat a je přístupný před zahájení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é aplikační databáze, aby nedocházelo k možným problémům s 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 Serveru nainstalovanou na počítači s Windows. Jedinou výjimkou je spravovaná instance SCOM služby Azure Monitor, která využívá Azure SQL MI a není možné ji překonfigurovat.

Požadavky SQL Serveru

Pro existující instalaci verze system Center Operations Manageru pro hostování serveru pro sestavy, provozního, datového skladu a databáze služby ACS se podporují následující verze SQL Serveru Enterprise &edice Standard:

  • SQL Server 2019 s minimální kumulativní aktualizací 8 (CU8) nebo novější, jak je k dispozici zde
  • SQL Server 2016 a nejnovější aktualizace dostupné tady
  • SQL Server 2022 s minimální kumulativní aktualizací 11 (CU11) nebo novější, jak je k dispozici zde
  • SQL Server 2019 s minimální kumulativní aktualizací 8 (CU8) nebo novější, jak je k dispozici zde
  • SQL Server 2017 s nejnovější dostupnou aktualizací, jak je k dispozici tady
  • Sql Server 2017 a kumulativní aktualizace, jak je podrobně popsáno zde
  • SQL Server 2016 a aktualizace Service Pack, jak je podrobně popsáno zde

Pro novou nebo existující instalaci nástroje System Center 2016 – Operations Manager se podporují následující verze SQL Serveru Enterprise &edice Standard pro hostování serveru pro sestavy, provozního, datového skladu a databáze služby ACS:

  • SQL Server 2016 a nejnovější aktualizace dostupné tady
  • SQL Server 2014 a nejnovější aktualizace dostupné tady
  • SQL Server 2012 a nejnovější aktualizace dostupné tady

Ovladače SQL Serveru

Ovladače OLE DB a ODBC SQL Serveru musí být nainstalovány na všech serverech pro správu a na serveru webové konzoly, protože tyto komponenty přímo rozhraní s databázemi a tyto ovladače umožňují přístup na úrovni rozhraní API k SQL.

Doporučuje se využít šifrované připojení SQL Serveru; když to uděláte, musíte nainstalovat nejnovější verze ovladačů SQL:

Další informace o konfiguraci šifrování připojení SQL najdete tady: Konfigurace databázového stroje SQL Serveru pro šifrování připojení

Pokud nepoužíváte šifrovaná připojení SQL, použijte předchozí verze ovladačů SQL, které nevynucují šifrování:

  • Ovladač Microsoft ODBC verze 17.10.6.
  • Ovladač Microsoft OLE DB verze 18.7.4.

Aktualizace SQL Serveru

Každá z následujících komponent SQL Serveru podporujících infrastrukturu Operations Manageru musí být ve stejné hlavní verzi SQL Serveru:

  • Instance databázového stroje SQL Serveru hostující některou z databází Operations Manageru, včetně:
    • OperationManager
    • OperationManagerDW
    • Databáze SSRS ReportServer a ReportServerTempDB
  • Instance služby SQL Server Reporting Services (SSRS).

Režim ověřování SQL Serveru

Sql ve výchozím nastavení funguje v konfiguraci ověřování ve smíšeném režimu. Operations Manager ale ke komunikaci s SQL Serverem využívá pouze ověřování systému Windows. Pokud je ve výchozím nastavení ponecháno, nastavení ověřování ve smíšeném režimu SQL bude fungovat i v případě, že k db_owner této roli nemá žádný místní účet. Místní účty s db_owner rolí můžou způsobovat problémy s Operations Managerem.

Před instalací produktu důrazně doporučujeme odebrat db_owner roli ze všech místních účtů a po instalaci role ji nepřidávejte db_owner do žádných místních účtů.

Ostatní úvahy

Při plánování návrhu platí další aspekty hardwaru a softwaru:

  • It it je doporučeno mít disky SQL ve formátu souborů NTFS.
  • Pro provozní databázi a databázi datového skladu musíte mít alespoň 1 GB volného místa na disku. To se vynucuje při vytváření databáze. Mějte na paměti, že využití disků databází se po nastavení výrazně zvýší, abyste měli nad tímto základním požadavkem dostatek volného místa na disku.
  • Vyžaduje se rozhraní .NET Framework 4.
  • Rozhraní .NET Framework 4.8 je podporováno z operations manageru 2022.
  • Server pro sestavy není podporován v jádru Windows Serveru.
  • Nastavení kolace SQL Serveru musí být jedním z podporovaných typů, jak je popsáno v části: Nastavení kolace SQL Serveru.
  • Pro všechny instance databázového stroje SQL Serveru, které hostují jakoukoli databázi Operations Manageru, se vyžaduje fulltextové vyhledávání SQL Serveru.
  • Možnosti instalace Windows Serveru (Jádro serveru, Server s desktopovým prostředím a Nano Server) podporované součástmi databáze Operations Manageru jsou založené na tom, jaké možnosti instalace SQL Server podporuje.

Další informace najdete v části Požadavky na hardware a software v části Instalace a plánování SYSTÉMU SQL Server zde: Plánování instalace SYSTÉMU SQL Server

Nastavení kolace SQL Serveru

V nástroji System Center Operations Manager jsou podporovány následující kolace SYSTÉMU SQL Server a Windows.

Poznámka:

Pokud se chcete vyhnout 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 Manageru.

Kolace SQL Serveru

  • SQL_Latin1_General_CP1_CI_AS

Kolace 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 Serveru není nakonfigurovaná s některou z podporovaných kolací uvedených dříve, provedení nové instalace operations manageru selže. Místní upgrade se ale úspěšně dokončí.

Konfigurace brány firewall

Operations Manager závisí na SQL Serveru, aby hostil své databáze a platformu pro vytváření sestav za účelem analýzy a prezentace historických provozních dat. Role serveru pro správu, operací a webové konzoly musí být schopné úspěšně komunikovat s SQL Serverem a je důležité pochopit komunikační cestu a porty, aby bylo možné správně nakonfigurovat vaše prostředí.

Pokud navrhujete distribuované nasazení, které používá skupiny dostupnosti SQL AlwaysOn, je potřeba do strategie zabezpečení brány firewall zahrnout další nastavení konfigurace brány firewall.

Následující tabulka uvádí porty brány firewall vyžadované SQL Serverem, aby servery pro správu mohly komunikovat s databázemi:

Scénář Port Směr Operations Manager Role
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í server pro správu
Vyhrazené připojení správce SQL Serveru TCP 1434 Příchozí server pro správu
Další porty používané SQL Serverem
– Vzdálená volání procedur Microsoftu (MS RPC)
– WMI (Windows Management Instrumentation)
– Microsoft Distributed Transaction Coordinator (MS DTC)		 TCP 135 Příchozí server pro správu
Naslouchací proces skupiny dostupnosti AlwaysOn SQL Serveru Nakonfigurovaný port správce Příchozí server pro správu
SQL Server Reporting Services hostující server pro sestavy nástroje Operations Manager TCP 80 (výchozí)/443 (SSL) Příchozí Server pro správu a konzola Operations Console

Poznámka:

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

Podrobnější přehled požadavků brány firewall pro SQL Server najdete v tématu Konfigurace brány Windows Firewall pro povolení přístupu k SQL Serveru.

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, která obsahuje všechna data potřebná operations managerem pro každodenní monitorování. Nastavení velikosti a konfigurace databázového serveru je důležité pro celkový výkon skupiny pro správu. Nejdůležitějším prostředkem používaným databází Operations Manageru je subsystém úložiště, ale procesor a paměť RAM jsou také významné.

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

  • Rychlost shromažďování provozních dat
    • Míra shromažďování provozních dat je ovlivněna faktory, jako je počet importovaných sad Management Pack, počet přidaných agentů a typ monitorovaného počítače. Například agent, který monitoruje stolní počítač s důležitými obchodními informacemi, shromažďuje méně dat v porovnání s agentem, který monitoruje server s SQL Serverem s více databázemi.
  • Frekvence změn prostoru instancí
    • Aktualizace existujících dat v databázi Operations Manageru je ve srovnání s zápisem nových provozních dat náročná na prostředky. Kromě toho, pokud dojde ke změnám dat prostoru instancí, servery pro správu musí provádět další dotazy na databázi pro výpočet konfigurace a seskupování změn. Četnost změn prostoru instancí se zvyšuje při importu nových sad Management Pack nebo přidávání nových agentů do skupiny pro správu.
  • Počet spuštěných konzol Operations Console a dalších připojení sady SDK současně ovlivňuje také zatížení databáze.
    • 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é zobrazují velké objemy provozních dat v zobrazení událostí, zobrazení stavu, zobrazení výstrah a zobrazení dat o výkonu, mají tendenci způsobit největší zatížení databáze.

Databáze Operations Manageru je jedním zdrojem selhání skupiny pro správu, takže je možné ji zpřístupnit s využitím podporovaných konfigurací převzetí služeb při selhání, jako jsou 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 po provedení změn konfigurace.

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

System Center Operations Manager závisí na službě SQL Server Service Broker, aby implementovaly všechny operace úloh. Pokud je služba SQL Server Service Broker zakázaná, budou ovlivněny všechny operace úloh. Výsledné chování se může lišit v závislosti na zahájené úloze. Proto je důležité zkontrolovat stav služby SQL Server Service Broker při každém neočekávaném chování v nástroji System Center Operations Manager.

Pokud chcete povolit SLUŽBU SQL Server Service Broker, postupujte takto:

  1. Spuštěním následujícího dotazu SQL zkontrolujte, jestli je zprostředkovatel již povolený, označený výsledkem 1 (jedna) v is_broker_enabled poli:

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

  2. Pokud je hodnota zobrazená v is_broker_enabled poli 0 (nula), spuštěním následujícího příkazu SQL povolte zprostředkovatele:

    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

Poznámka:

Datový sklad nástroje Operations Manager se také označuje jako databáze "Datový sklad sestav" nebo jen "Datový sklad" v některé dokumentaci.

System Center – Operations Manager vloží data do datového skladu téměř v reálném čase. Na tomto serveru je důležité mít dostatečnou kapacitu, která podporuje zápis všech shromážděných dat do datového skladu. Stejně jako u databáze Operations Manageru je nejdůležitějším prostředkem datového skladu subsystém V/V úložiště. Ve většině systémů se zatížení datového skladu podobá databázi Operations Manageru, ale můžou se lišit. Úloha vložená do datového skladu pomocí generování sestav se navíc liší od zatížení databáze Operations Manageru podle využití konzoly Operations Console.

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

  • Rychlost shromažďování provozních dat
    • Datový sklad provádí výpočty a ukládá agregovaná data spolu s omezeným množstvím nezpracovaných dat, aby bylo možné efektivnější vytváření sestav. Výsledkem je, že náklady na shromažďování provozních dat do datového skladu jsou v porovnání s databází Operations Manageru mírně vyšší. Tyto náklady jsou však posunovány snížením nákladů na zpracování dat zjišťování v datovém skladu v porovnání s databází nástroje Operations Manager.
  • Počet souběžných uživatelů generování sestav nebo plánované generování sestav.
    • Každý uživatel generování sestav může do systému přidat značné zatížení, protože sestavy často shrnují velké objemy dat. Celkové potřeby kapacity jsou ovlivněny počtem spuštěných sestav současně a typem spuštěných sestav. Sestavy, které se dotazují na velké rozsahy kalendářních dat nebo velký počet objektů, vyžadují dodatečné systémové prostředky.

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

  • Zvolte odpovídající subsystém úložiště.
    • Vzhledem k tomu, že datový sklad je nedílnou součástí celkového toku dat prostřednictvím skupiny pro správu, je důležité zvolit odpovídající subsystém úložiště pro datový sklad. Stejně jako u databáze Operations Manageru je často nejlepší volbou raid 0 + 1. Obecně platí, že subsystém úložiště datového skladu by se měl podobat subsystému úložiště pro databázi Operations Manageru a pokyny, které platí pro databázi Operations Manageru, platí také pro datový sklad.
  • Zvažte vhodné umístění datových protokolů vs. transakčních protokolů.
    • 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í kapacity počtu agentů. Pokud se databáze Operations Manageru i datový sklad nacházejí na stejném serveru a chcete oddělit data a transakční protokoly, musíte protokoly transakcí pro databázi Operations Manageru umístit na samostatný fyzický svazek a diskové diskové disky od datového skladu, abyste získali jakoukoli výhodu. Datové soubory pro databázi a datový sklad Operations Manageru můžou sdílet stejný fyzický svazek, pokud svazek poskytuje dostatečnou kapacitu a výkon vstupně-výstupních operací disku nemá negativní vliv na funkce monitorování a generování sestav.
  • Zvažte umístění datového skladu na samostatný server od databáze Operations Manageru.
    • I když menší nasazení můžou často konsolidovat databázi Operations Manageru a datový sklad na stejném serveru, je výhodné je oddělit při vertikálním navýšení kapacity počtu agentů a objemu příchozích provozních dat. Pokud je datový sklad a server pro sestavy na samostatném serveru od databáze nástroje Operations Manager, dosáhnete lepšího výkonu generování sestav.

Databáze datového skladu nástroje Operations Manager je jedním zdrojem selhání pro skupinu pro správu, takže je možné ji zpřístupnit s využitím podporovaných konfigurací převzetí služeb při selhání, jako jsou skupiny dostupnosti AlwaysOn SQL Serveru nebo instance clusteru s podporou převzetí služeb při selhání.

Sql Server AlwaysOn

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áze dostupnosti). Každá skupina databází dostupnosti je hostovaná v replice dostupnosti.

S nástrojem System Center 2016 a novějším – Operations Managerem se upřednostňují funkce SQL AlwaysOn před clusteringem s podporou převzetí služeb při selhání, aby poskytovala vysokou dostupnost pro databáze. Všechny databáze s výjimkou instalace služby Reporting Services v nativním režimu, která používá dvě databáze k oddělení trvalého úložiště od dočasných požadavků na úložiště, je možné hostovat ve skupině dostupnosti AlwaysOn.

Pokud chcete nastavit skupinu dostupnosti, nasadíte cluster Windows Server Clustering s podporou převzetí služeb při selhání (WSFC) pro hostování repliky dostupnosti a povolíte funkci AlwaysOn na uzlech clusteru. Databázi SQL Serveru operations Manageru pak můžete přidat jako databázi dostupnosti.

Tip

Od Operations Manageru 2022 můžete nastavit a upgradovat databáze Operations Manageru s existujícím nastavením SQL Always-On bez nutnosti po provedení změn konfigurace.

Pokud chcete nastavit skupinu dostupnosti, nasadíte cluster Windows Server Clustering s podporou převzetí služeb při selhání (WSFC) pro hostování repliky dostupnosti a povolíte funkci AlwaysOn na uzlech clusteru. Databázi SQL Serveru operations Manageru pak můžete přidat jako databázi dostupnosti.

Poznámka:

Po nasazení Operations Manageru na uzlech SQL Serveru, které se účastní sql AlwaysOn, povolte striktní zabezpečení CLR spuštěním skriptu SQL v každé databázi Operations Manageru.

Řetězec více podsítě

Operations Manager nepodporuje připojovací řetězec klíčová slova (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 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í ze serverů pro správu do naslouchacího procesu skupiny dostupnosti způsobí vypršení časového limitu připojení.

Doporučený postup, jak toto omezení obejít s nasazenými uzly serveru skupiny dostupnosti v prostředí s více podsítěmi, je:

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

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

Spuštěním následujících příkazů PowerShellu na libovolném z uzlů SQL upravte tato 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 funkci AlwaysOn s názvem naslouchacího procesu, měli byste také provést tyto změny konfigurace na 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 hostitelem naslouchacího procesu, je možné spustit následující příkazy PowerShellu a upravit 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 clusterovaná nebo instance SQL AlwaysOn používá pro zajištění vysoké dostupnosti, měli byste na serverech pro správu povolit funkci automatického obnovení, abyste se vyhnuli restartování služby Operations Manager Data Access kdykoli dojde k převzetí služeb při selhání mezi uzly. Informace o konfiguraci najdete v následujícím článku znalostní báze System Center Management, který přestane reagovat, jakmile instance SYSTÉMU SQL Server přejde do režimu offline.

Optimalizace SQL Serveru

Zkušenosti podpory ukázaly, že problémy s výkonem nejsou obvykle způsobeny vysokým využitím prostředků (to znamená procesorem nebo pamětí) u samotného SQL Serveru; problém souvisí přímo s konfigurací subsystému úložiště. Kritické body výkonu se běžně přiřazují tak, že nedosáží doporučených pokynů ke konfiguraci se zřízeným úložištěm pro instanci databáze SQL Serveru. Mezi tyto příklady patří:

  • Nedostatečné přidělení jednotek pro logické jednotky pro podporu požadavků na vstupně-výstupní operace operations manageru.
  • Hostování transakčních protokolů 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 není správná s ohledem na umístění, změnu velikosti atd.
  • Chybné zarovnání diskového oddílu svazků, které hostují protokoly transakcí databáze, soubory databáze a databázi TempDB.
  • Přehlédnutí základní konfigurace SQL Serveru, 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 důležitých komponent pro nasazení SQL Serveru pro Operations Manager. Databázové servery mají tendenci být vázané na vstupně-výstupní operace kvůli důkladné aktivitě čtení a zápisu databáze a zpracování transakčních protokolů. Vzor chování vstupně-výstupních operací operations manageru je obvykle 80 % zápisů a 20 % čtení. V důsledku toho může nesprávná konfigurace vstupně-výstupních subsystémů vést k nízkému výkonu a provozu systémů SQL Serveru a stává se znatelným v Operations Manageru.

Před nasazením SQL Serveru je důležité otestovat návrh SQL Serveru provedením testování propustnosti subsystému vstupně-výstupních operací. 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 ve skupině produktů, poskytuje podrobné pokyny a doporučení k provádění zátěžového testování pomocí tohoto nástroje – DiskSpd, PowerShell a výkon úložiště: měření vstupně-výstupních operací za sekundu, propustnosti a latence pro místní disky i sdílené složky SMB.

Velikost alokační jednotky NTFS

Zarovnání svazku, běžně označované jako zarovnání sektorů, by se mělo provádět v systému souborů (NTFS) při každém vytvoření svazku na zařízení RAID. Pokud to neuděláte, může to vést k významnému snížení výkonu a nejčastěji se jedná o výsledek chybného zarovnání oddílu s hranicemi prokládání jednotek. Může také vést k nesprávnému zarovnání mezipaměti hardwaru, což vede k neefektivnímu využití mezipaměti pole.

Při formátování oddílu používaného pro datové soubory SQL Serveru doporučujeme pro data, protokoly a databázi TempDB použít velikost alokační jednotky o velikosti 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 podporuje data jen pro čtení na komprimovaných svazcích, nedoporučuje se.

Rezervovat paměť

Poznámka:

Většina informací v této části pochází z Jonathan Kehayias v jeho blogovém příspěvku Kolik paměti můj SQL Server skutečně potřebuje? (sqlskills.com).

Není vždy snadné identifikovat správné množství fyzické paměti a procesorů, které se mají 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 jeho doporučení jsou založená na testování prováděném v testovacím prostředí, které může nebo nemusí odpovídat vaší skutečné úloze a konfiguraci.

SQL Server umožňuje nakonfigurovat minimální a maximální množství paměti , které bude rezervováno a používáno jeho procesem. SQL Server může ve výchozím nastavení dynamicky měnit požadavky na paměť na základě dostupných systémových prostředků. Výchozí nastavení pro minimální paměť 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í. Mnoho faktorů ovlivňuje, kolik paměti potřebujete přidělit SQL Serveru, 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 kontrola antivirového programu v reálném čase. Pokud není nastavena dostatečná paměť, operační systém a SQL se budou na disk stránkuovat. To může způsobit zvýšení vstupně-výstupních operací disku, další snížení výkonu a vytvoření efektu zvlnění, kde se v Operations Manageru projeví.

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ý je hostitelem jedné z databází Operations Manageru (provozní, datový sklad, ACS).

Pro maximální paměť serveru doporučujeme nejprve rezervovat celkový počet:

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

Po nastavení těchto hodnot monitorujte čítač Memory\Available MBytes ve Windows a zjistěte, jestli můžete zvýšit paměť dostupnou pro SQL Server. Systém Windows signalizuje, že dostupná fyzická paměť je nízká na 96 MB, takže v ideálním případě by neměl čítač běžet nižší než přibližně 200–300 MB, abyste měli jistotu, že máte vyrovnávací paměť. U serverů s 256GB pamětí RAM nebo novějším se ujistěte, že neběží méně než 1 GB.

Mějte na paměti, že tyto výpočty předpokládají, že chcete, aby SQL Server mohl použí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 Serveru a další alokátory s více stránkami. Typický vzorec by byl ((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 a hodnotu maximálního počtu 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, aby běžel na virtuálním počítači. Vzhledem k tomu, že SQL Server je navržený tak, aby ukládal data do mezipaměti ve fondu vyrovnávací paměti a využívá co nejvíce paměti, může být obtížné určit ideální množství paměti RAM potřebné. Při snížení paměti přidělené instanci SQL Serveru můžete dosáhnout bodu, kdy se pro vstupně-výstupní přístup k disku obchoduje s nižším přidělením paměti.

Pokud chcete nakonfigurovat paměť SYSTÉMU SQL Server v prostředí, které bylo nadřízený, začněte monitorováním prostředí a aktuálními metrikami výkonu, včetně očekávané délky životnosti stránky Správce vyrovnávací paměti SQL Serveru a čtení stránek za sekundu a čtení fyzických disků za sekundu . Pokud má prostředí nadbytečnou paměť, očekávaná délka životnosti stránky se zvýší o hodnotu každou sekundu, aniž by došlo ke snížení zatížení, protože se ukládá do mezipaměti. Stránka Správce vyrovnávací paměti SQL Serveru bude po zvětšování mezipaměti nízká a čtení za sekundu na disku fyzického disku zůstane také nízké.

Jakmile pochopíte směrný plán prostředí, můžete maximální paměť serveru snížit o 1 GB a pak zjistit, jak to ovlivňuje čítače výkonu (po ukončení počátečního vyprazdňování mezipaměti). Pokud metriky zůstanou přijatelné, snižte o další 1 GB a pak znovu monitorujte podle potřeby, dokud nezjistíte ideální konfiguraci.

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

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

Optimalizace databáze TempDB

Velikost a fyzické umístění databáze TempDB může ovlivnit výkon nástroje Operations Manager. Pokud je například velikost definovaná pro databázi TempDB příliš malá, může být součástí zatížení zpracování systému automaticky zvětšovací databáze TempDB na velikost potřebnou k podpoře úlohy při každém restartování instance SQL Serveru. Pokud chcete dosáhnout optimálního výkonu databáze TempDB, doporučujeme použít následující konfiguraci databáze TempDB v produkčním prostředí:

  • Nastavte model obnovení databáze TempDB na SIMPLE.
    • Tento model automaticky uvolní místo v protokolu, aby byly požadavky na místo malé.
  • Předem přidělte místo pro všechny soubory TempDB nastavením velikosti souboru na hodnotu dostatečně velkou, aby vyhovovala typické úloze v prostředí. Zabraňuje příliš častému rozšíření databáze TempDB, což může ovlivnit výkon. Databázi TempDB je možné nastavit na automatické zvětšování, ale měla by se použít ke zvýšení místa na disku pro neplánované výjimky.
  • Vytvořte tolik souborů, kolik potřebujete k maximalizaci šířky pásma disku.
    • Použití více souborů snižuje kolize úložiště TempDB a přináší lepší škálovatelnost. Nevytvávejte ale příliš mnoho souborů, protože může snížit výkon a zvýšit režijní náklady na správu.
    • Obecně platí, že pro každý logický procesor na serveru vytvořte jeden datový soubor (započítávání všech nastavení masky spřažení) a podle potřeby upravte počet souborů nahoru nebo dolů.
    • Obecně platí, že pokud je počet logických procesorů menší nebo roven 8, použijte stejný počet datových souborů jako logické procesory.
      • Pokud je počet logických procesorů větší než 8, použijte osm datových souborů a pokud kolize potrvá, zvyšte počet datových souborů o násobky 4 (až do počtu logických procesorů), dokud nedojde ke snížení kolizí na přijatelné úrovně nebo provedení změn úlohy nebo kódu.
      • Pokud se kolize nezmenší, možná budete muset zvýšit počet datových souborů více.
  • U každého datového souboru udělejte stejnou velikost, což umožňuje optimální výkon proporcionálního vyplnění.
    • Stejná velikost datových souborů je důležitá, protože algoritmus proporcionální výplně je založený na velikosti souborů. Pokud jsou datové soubory vytvořeny s nerovnými velikostmi, algoritmus proporcionální vyplnění se pokusí použít největší soubor více pro přidělení GAM místo rozložení přidělení mezi všechny soubory, čímž porazí účel vytváření více datových souborů.
  • Databázi TempDB umístěte do rychlého vstupně-výstupního subsystému pomocí jednotek SSD pro optimální výkon.
    • Pokud existuje mnoho přímo připojených disků, použijte prokládání disků.
  • Umístěte databázi tempDB na disky, které se liší od těch, které používají uživatelské databáze.

Ke konfiguraci databáze TempDB můžete spustit následující dotaz nebo upravit jeho vlastnosti v sadě 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ánky 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 sdíleného globálního přidělení). V závislosti na stupni kolizí by toto nastavení mohlo vést k tomu, že SQL Server na krátkou dobu nereaguje. Dalším přístupem je prozkoumání zobrazení dynamické správy [sys.dm_exec_request nebo sys.dm_os_waiting_tasks]. Výsledky ukazují, že tyto požadavky nebo úlohy čekají na prostředky databáze TempDB a mají podobné hodnoty jako zvýrazněné dříve při spuštění sys.sysprocesses dotazu.

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

Poznámka:

Tento příznak trasování má vliv na každou databázi v instanci SQL Serveru.

Maximální stupeň paralelismu

Tip

Nejnovější osvědčené postupy a doporučení od týmu SQL Serveru najdete v této dokumentaci: Nastavení maximálního stupně paralelismu pro optimální výkon

Výchozí konfigurace SQL Serveru pro nasazení Operations Manageru s malou až střední velikostí je vhodná pro většinu potřeb. Pokud se ale zatížení skupiny pro správu škáluje směrem nahoru ke scénáři podnikové třídy (obvykle 2 000 systémů spravovaných agentem a pokročilá konfigurace monitorování, která zahrnuje monitorování na úrovni služeb s pokročilými syntetickými transakcemi, monitorováním síťových zařízení, multiplatformní platformou atd.), je potřeba optimalizovat konfiguraci SQL Serveru popsaného v této části dokumentu. Jedna možnost konfigurace, která není popsána v předchozích doprovodných materiálech, je MAXDOP.

Možnost konfigurace maximálního stupně paralelismu (MAXDOP) Microsoft SQL Serveru řídí počet procesorů, které se používají k provádě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 dotazů, které provádějí práci paralelně. V závislosti na tom, jestli je SQL Server nastavený na počítači s symetrickým multiprocesingem (SMP), počítači s neuniformním přístupem k paměti (NUMA) nebo procesory s podporou hyperthreadingu, musíte odpovídajícím způsobem nakonfigurovat maximální stupeň paralelismu.

Když SQL Server běží na počítači s více než jedním mikroprocesorem nebo procesorem, zjistí nejlepší stupeň paralelismu, tj. počet procesorů použitých ke spuštění jednoho příkazu pro každé paralelní spuštění plánu. Ve výchozím nastavení je jeho hodnota pro tuto možnost 0, což umožňuje SQL Serveru určit maximální stupeň paralelismu.

Uložené procedury a dotazy předdefinované v Operations Manageru, které souvisejí s provozním, datovým skladem a dokonce i auditovací databází, nezahrnují možnost MAXDOP, protože během instalace neexistuje žádný způsob, jak dynamicky dotazovat, kolik procesorů se v operačním systému prezentuje, ani se nepokoušel pevně zakódovat hodnotu tohoto nastavení, což by mohlo mít negativní důsledky při spuštění dotazu.

Poznámka:

Maximální stupeň konfigurace paralelismu neomezuje počet procesorů, které SQL Server používá. Ke konfiguraci počtu procesorů, které SQL Server používá, použijte možnost konfigurace masky spřažení.

  • Pro servery, které používají 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.

    Tip

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

  • U serverů, které mají nakonfigurovanou technologii NUMA, by hodnota MAXDOP neměla překročit počet procesorů přiřazených jednotlivým uzlům NUMA.

  • U serverů s povoleným hyperthreadingem by hodnota MAXDOP neměla překročit počet fyzických procesorů.

  • U serverů s povolenou technologií NUMA a povoleným hyperthreadingem by hodnota MAXDOP neměla překročit počet fyzických procesorů na uzel NUMA.

Počet paralelních pracovních procesů můžete monitorovat dotazováním select * from sys.dm_os_tasks.

V tomto příkladu byla hardwarová konfigurace serveru HP Blade G6 s 24jádrovými procesory a 196 GB paměti RAM. Instance hostující databázi Operations Manageru měla nastavení MAXMEM 64 GB. Po provedení navrhovaných optimalizací v této části se zlepšil výkon. Kritický bod paralelismu dotazu však stále přetrvává. Po testování různých hodnot se zjistil optimální výkon nastavením MAXDOP=4.

Počáteční velikost databáze

Pokus o odhad budoucího růstu databází Operations Manageru, konkrétně databází provozního a datového skladu, během prvních několika měsíců po nasazení není jednoduché cvičení. I když pomocná rutina pro změnu velikosti operations manageru je rozumná při odhadu potenciálního růstu na základě vzorce odvozeného ze skupiny produktů z jejich testování v laboratoři, nebere v úvahu několik faktorů, které můžou ovlivnit růst v blízké době a v dlouhodobém horizontu.

Počáteční velikost databáze navržená pomocným nástrojem pro změnu velikosti by měla být přidělena předpovězené velikosti, aby se snížila fragmentace a odpovídající režijní náklady, které je možné určit v době nastavení pro databáze provozního a datového skladu. Pokud během instalace není k dispozici dostatek místa v úložišti, je možné databáze později rozšířit pomocí aplikace SQL Management Studio a potom znovu indexovat a odpovídajícím způsobem defragmentovat a optimalizovat. Toto doporučení platí také pro databázi služby ACS.

Proaktivní monitorování růstu provozní databáze a databáze datového skladu by se mělo provádět v denním nebo týdenním cyklu. To je nezbytné k identifikaci neočekávaných a významných nárůstů a zahájení řešení potíží s cílem určit kauzalitu, ať už jde o chybu v pracovním postupu sady Management Pack (tj. pravidlo zjišťování, pravidlo zjišťování, pravidlo shromažďování událostí nebo pravidlo monitorování nebo upozornění) nebo jiné příznaky s sadou Management Pack, která nebyla identifikována během testování a fáze kontroly kvality procesu správy verzí.

Automatické zvětšování databáze

Když se zaplní velikost souboru rezervovaných databází, SQL Server může velikost automaticky zvětšit o procento nebo pevnou částku. Navíc je možné nakonfigurovat maximální velikost databáze, aby se zabránilo zaplnění veškerého místa dostupného na disku. Ve výchozím nastavení není databáze Operations Manageru nakonfigurovaná s povoleným automatickým zvětšováním; Pouze databáze datového skladu a služby ACS jsou.

V případě neočekávaného růstu se spoléháme pouze na automatické zvětšování. Autogrow představuje snížení výkonu, které je třeba zvážit při práci s vysoce transakční databází. Mezi sankce za výkon patří:

  • Pokud nezadáte odpovídající přírůstek růstu, může dojít k fragmentaci souboru protokolu nebo databáze.
  • Pokud spustíte transakci, která vyžaduje více místa protokolu, než je k dispozici, a pro transakční protokol této databáze je povolen automatický zvětšování, čas potřebný k dokončení transakce bude obsahovat dobu, po kterou se transakční protokol zvýší o nakonfigurovanou částku.
  • Pokud spustíte velkou transakci, která vyžaduje zvětšení protokolu, další transakce, které vyžadují zápis do transakčního protokolu, budou také muset počkat, až se operace zvětšování dokončí.

Pokud jsou možnosti automatického zvětšování a automatického zkombinování, může to způsobit zbytečnou režii. Ujistěte se, že prahové hodnoty, které aktivují operace zvětšení a zmenšení, nezpůsobí časté změny velikosti nahoru a dolů. Můžete například spustit transakci, která způsobí nárůst transakčního protokolu o 100 MB v době, kdy se potvrdí; poté, co se autoshrink spustí a zmenší transakční protokol o 100 MB. Pak spustíte stejnou transakci a způsobí, že se transakční protokol znovu zvětšuje o 100 MB. V tomto příkladu vytváříte zbytečnou režii a potenciálně vytváříte fragmentaci souboru protokolu, z nichž která může negativně ovlivnit výkon.

Pečlivě nakonfigurujte tato dvě nastavení. Konkrétní konfigurace ve skutečnosti závisí na vašem prostředí. Obecně se doporučuje zvětšit velikost databáze o pevnou částku, aby se snížila fragmentace disku. Podívejte se například na následující obrázek, kde je databáze nakonfigurovaná tak, aby se při každém vyžadování automatického zvětšování zvětšila o 1 024 MB.

Zásady převzetí služeb při selhání clusteru

Clustering s podporou převzetí služeb při selhání Windows Serveru je platforma s vysokou dostupností, která neustále monitoruje síťová připojení a stav uzlů v clusteru. Pokud uzel není dostupný přes síť, provede se akce obnovení, která obnoví a přenese aplikace a služby do režimu online na jiném uzlu v clusteru. Výchozí nastavení jsou optimalizovaná pro chyby, kdy dojde k úplné ztrátě serveru, což se považuje za "pevné" selhání. Jedná se o neopravitelné scénáře selhání, jako je selhání neredundant hardwaru nebo napájení. V těchto situacích dojde ke ztrátě serveru a cílem je clustering s podporou převzetí služeb při selhání rychle zjistit ztrátu serveru a rychle obnovit na jiném serveru v clusteru. Aby bylo možné dosáhnout tohoto rychlého obnovení z pevných selhání, výchozí nastavení pro monitorování stavu clusteru jsou poměrně agresivní. Jsou ale plně konfigurovatelné, aby umožňovaly flexibilitu pro různé scénáře.

Tato výchozí nastavení poskytují nejlepší chování pro většinu zákazníků; Vzhledem k tomu, že jsou clustery roztaženy z palců na kilometry od sebe, může se cluster stát vystaven většímu a potenciálně nespolehlivému síťovému komponentě mezi uzly. Dalším faktorem je, že kvalita komoditních serverů se neustále zvyšuje, v kombinaci s rozšířenou odolností prostřednictvím redundantních komponent (jako jsou duální zdroje napájení, seskupování síťových adaptérů a vstupně-výstupní operace s více cestami), může být počet nerušených selhání hardwaru poměrně vzácný. Vzhledem k tomu, že pevné chyby můžou být méně časté, někteří zákazníci můžou chtít cluster vyladit na přechodné chyby, kdy je cluster odolnější vůči krátkým selháním sítě mezi uzly. Zvýšením výchozích prahových hodnot selhání můžete snížit citlivost na krátké problémy se sítí, které trvají krátkou dobu.

Je důležité si uvědomit, že tady není žádná správná odpověď a optimalizované nastavení se může lišit podle konkrétních obchodních požadavků a smluv o úrovni služeb.

Virtualizace SQL Serveru

Z důvodů výkonu se ve virtuálních prostředích doporučuje ukládat provozní databázi a databázi datového skladu do přímo připojeného úložiště, nikoli na virtuální disk. K odhadu požadovaných vstupně-výstupních operací za sekundu a zátěžovém testování datových disků můžete použít pomocný nástroj pro změnu velikosti operations manageru vydané pro Operations Manager 2012 a ověřit tak požadované vstupně-výstupní operace za sekundu. Výkon úložiště je možné testovat pomocí nástroje DiskSpd. Další pokyny k virtualizovanému prostředí Operations Manageru najdete také v podpoře virtualizace Operations Manageru.

Model AlwaysOn a obnovení

I když ne výhradně optimalizace, důležitým aspektem týkajícím se skupiny dostupnosti AlwaysOn je skutečnost, že tato funkce vyžaduje, aby databáze byly nastaveny v modelu úplné obnovení. To znamená, že transakční protokoly se nikdy nezahodí, dokud se neprovede úplná záloha nebo pouze transakční protokol. Z tohoto důvodu není strategie zálohování volitelná, ale požadovaná část návrhu AlwaysOn pro databáze Operations Manageru. Jinak se s časem zaplní disky obsahující transakční protokoly.

Strategie zálohování musí brát v úvahu podrobnosti o vašem prostředí. Typický plán zálohování je uveden v následující tabulce.

Typ zálohování Plán
Pouze transakční protokol Každou hodinu
Úplný Týdně, neděle v 3:00

Optimalizace služby SQL Server Reporting Services

Instance služby Reporting Services funguje jako proxy pro přístup k datům v databázi datového skladu. Generuje a zobrazuje sestavy založené na šablonách uložených v sadách Management Pack.

Roli generování sestav operations manageru nejde nainstalovat souběžně s předchozí verzí role generování sestav a musí být nainstalovaná jenom v nativním režimu (integrovaný režim SharePointu není podporovaný).

Na pozadí služby Reporting Services existuje instance služby SQL Server Database, která hostuje databáze ReportServer a ReportServerTempDB. Platí obecná doporučení týkající se ladění výkonu této instance.

Poznámka:

Ve službě SQL Server Reporting Services (SSRS) 2017 verze 14.0.600.1274 a novějších nastavení zabezpečení nepovolují nahrávání rozšíření prostředků. To vede k výjimkám ResourceFileFormatNotAllowedException v Operations Manageru během nasazování komponent generování sestav.

Tento problém vyřešíte takto:

  1. Otevřete SQL Management Studio.
  2. Připojte se k instanci služby Reporting Services.
  3. V okně Průzkumník objektů klikněte pravým tlačítkem na instanci serveru.
  4. Vyberte Vlastnosti.
  5. Na levém bočním panelu vyberte Upřesnit .
  6. Přidejte *.* do seznamu pro AllowedResourceExtensionsForUpload.

Případně můžete přidat úplný seznam rozšíření generování sestav nástroje Operations Manager do seznamu povolených v SSRS. Seznam je popsaný v části Řešení 2: Sestavy Operations Manageru se nepodaří nasadit.

Další kroky

Informace o tom, jak nakonfigurovat hostování datového skladu (generování sestav) za bránou firewall, najdete v tématu Připojení datového skladu (generování sestav) přes bránu firewall.