Ontwerpoverwegingen voor SQL Server

System Center Operations Manager vereist toegang tot een exemplaar van een server waarop Microsoft SQL Server wordt uitgevoerd ter ondersteuning van de operationele, datawarehouse- en ACS-auditdatabase. De operationele database en datawarehouse-database zijn vereist en worden gemaakt wanneer u de eerste beheerserver in uw beheergroep implementeert. De ACS-database wordt echter gemaakt wanneer u een ACS-collector in uw beheergroep implementeert.

In een testomgeving of kleinschalige implementatie van Operations Manager kan SQL Server ook op de eerste beheerserver in de beheergroep worden geplaatst.

In een middelgrote tot grote gedistribueerde implementatie moet het SQL Server-exemplaar op een specifieke zelfstandige server of in een SQL Server-configuratie voor maximale beschikbaarheid worden geplaatst. In beide gevallen moet SQL Server al aanwezig en toegankelijk zijn voordat u aan de installatie van de eerste beheerserver of de ACS-collector begint.

Het is niet raadzaam om Operations Manager-databases te gebruiken vanuit een SQL-exemplaar met andere toepassingsdatabases. Dit is om mogelijke problemen met I/O en andere hardwareresourcebeperkingen te voorkomen.

Belangrijk

Operations Manager biedt geen ondersteuning voor PaaS-exemplaren (Platform as a Service) van SQL, inclusief producten zoals Azure SQL Managed Instance of Amazon Relational Database Service (AWS RDS). Gebruik een exemplaar van SQL Server geïnstalleerd op een Windows-computer. De enige uitzondering hierop is in Azure Monitor SCOM Managed Instance, dat gebruikmaakt van Azure SQL MI en niet opnieuw kan worden geconfigureerd.

Vereisten voor SQL Server

De volgende versies van SQL Server Enterprise & Standard Edition worden ondersteund voor een bestaande installatie van System Center Operations Manager-versie voor het hosten van de Reporting Server-, Operational-, Data Warehouse- en ACS-database:

• SQL Server 2022

• SQL Server 2019 met cumulatieve update 8 (CU8) of hoger zoals hier wordt beschreven

  Notitie

  • Operations Manager 2022 ondersteunt SQL 2019 met CU8 of hoger; SQL 2019 RTM wordt echter niet ondersteund.
  • Gebruik ODBC 17.3 of hoger en MSOLEDBSQL 18.2 of hoger.

• SQL Server 2017 en cumulatieve Updates zoals hier wordt beschreven

Zie Upgrade-informatie voor 2017 en upgrade-informatie voor SQL 2019 voordat u een upgrade uitvoert voor SQL Server.

Notitie

• Elk van de volgende SQL Server onderdelen die een SCOM-infrastructuur ondersteunen, moet dezelfde SQL Server primaire versie hebben:
  • SQL Server database-engine-exemplaren die als host fungeren voor een van de SCOM-databases (operationManager,OperationManagerDW en SSRS-databases ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services -exemplaar (SSRS).
• De instelling SQL Server sortering moet een van de ondersteunde typen zijn, zoals beschreven in de sectie SQL Server sorteringsinstelling hieronder.
• SQL Server zoeken in volledige tekst is vereist voor alle exemplaren van SQL Server database-engine die als host fungeren voor een van de SCOM-databases.
• De Windows Server 2016 installatieopties (Server Core, Server met bureaubladervaring en Nano Server) die worden ondersteund door Operations Manager-databaseonderdelen, zijn gebaseerd op de installatieopties van Windows Server die worden ondersteund door SQL Server.

Notitie

System Center Operations Manager-rapportage kan niet naast een eerdere versie van de rapportagerol worden geïnstalleerd en moet alleen in de systeemeigen modus worden geïnstalleerd (de geïntegreerde SharePoint-modus wordt niet ondersteund).

Houd bij het plannen van uw ontwerp rekening met deze aanvullende overwegingen voor hardware en software:

• U wordt aangeraden SQL Server uit te voeren op computers met de NTFS-bestandsindeling.
• Er moet ten minste 1024 MB vrije schijfruimte zijn voor de operationele database en datawarehouse-database. Dit wordt afgedwongen op het moment dat de database wordt gemaakt en zal na de installatie waarschijnlijk aanzienlijk toenemen.
• .NET Framework 4 is vereist.
• .NET Framework 4.8 wordt ondersteund vanuit Operations Manager 2022.
• Reporting Server wordt niet ondersteund in Windows Server Core.

Zie Hardware- en softwarevereisten voor het installeren van SQL Server voor meer informatie.

Notitie

Hoewel Operations Manager tijdens de installatie alleen Gebruikmaakt van Windows-verificatie, werkt de instelling SQL Mixed Mode Authentication nog steeds als geen lokaal account de rol db_owner heeft. Het is bekend dat lokale accounts met de rol db_owner problemen veroorzaken met System Center Operations Manager. Verwijder de rol db_owner uit alle lokale accounts voordat u het product installeert en voeg de db_owner-rol na de installatie niet toe aan een van de lokale accounts.

Instelling voor SQL Server-sortering

De volgende SQL Server- en Windows-sorteringen worden ondersteund door System Center Operations Manager.

Notitie

Om compatibiliteitsproblemen bij het vergelijken of kopiëren van bewerkingen te voorkomen, raden we u aan dezelfde sortering te gebruiken voor de SQL- en Operations Manager-database.

SQL Server-sortering

• SQL_Latin1_General_CP1_CI_AS

Windows-sortering

• 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

Als uw SQL Server-exemplaar niet is geconfigureerd met een van de ondersteunde sorteringen die eerder zijn vermeld, mislukt het uitvoeren van een nieuwe installatie van Operations Manager-installatie. Een in-place upgrade wordt echter wel voltooid.

Firewallconfiguratie

Operations Manager is afhankelijk van SQL Server voor het hosten van databases en van een rapportageplatform voor het analyseren en weergeven van historische operationele gegevens. De beheerserver- en operations- en webconsolerollen moeten kunnen communiceren met SQL Server en het is belangrijk dat u het communicatiepad en de poorten begrijpt om uw omgeving correct te configureren.

Als u een gedistribueerde implementatie ontwerpt waarvoor SQL AlwaysOn-beschikbaarheidsgroepen nodig zijn om failoverfunctionaliteit te bieden voor de Operations Manager-databases, zijn er aanvullende firewallconfiguratie-instellingen die moeten worden opgenomen in uw firewallbeveiligingsstrategie.

Met de volgende tabel kunt u de firewallpoorten identificeren die voor SQL Server vereist zijn en minimaal moeten worden toegestaan om serverrollen in uw Operations Manager-beheergroep te laten communiceren.

Scenario	Poort	Richting	Operations Manager-rol
SQL Server-hosting van Operations Manager-databases	TCP 1433 *	Inkomend	Beheerserver en Webconsole (voor Application Advisor en Application Diagnostics)
SQL Server Browser-service	UDP 1434	Inkomend	managementserver
SQL Server Dedicated Admin Connection (exclusieve beheerdersverbinding)	TCP 1434	Inkomend	managementserver
Extra poorten die door SQL Server worden gebruikt - Microsoft remote procedure calls (MS RPC) - Windows Management Instrumentation (WMI) - Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Inkomend	managementserver
SQL Server Always On-listener voor beschikbaarheidsgroep	Door beheerder geconfigureerde poort	Inkomend	managementserver
SQL Server Reporting Services die als host fungeert voor Operations Manager-rapportserver	TCP 80 (standaard)/443 (SSL)	Inkomend	beheerserver en Operations-console

* Tcp 1433 is de standaardpoort voor het standaardexemplaren van de database-engine en wanneer u een benoemd exemplaar maakt in een zelfstandige SQL Server of een SQL AlwaysOn-beschikbaarheidsgroep hebt geïmplementeerd, wordt er een aangepaste poort gedefinieerd en moet deze worden gedocumenteerd ter referentie, zodat u uw firewalls correct configureert en deze informatie tijdens de installatie invoert.

Zie Windows Firewall configureren om toegang SQL Server toe te staan voor een gedetailleerder overzicht van de firewallvereisten voor SQL Server.

Overwegingen voor capaciteit en opslag

Operations Manager-database

De Operations Manager-database is een SQL Server-database die alle gegevens bevat die Operations Manager nodig heeft voor dagelijkse bewakingsactiviteiten. De grootte en configuratie van de databaseserver zijn essentieel voor de algehele prestaties van de beheergroep. De meest kritieke resource die door de Operations Manager-database wordt gebruikt, is het opslagsubsysteem, maar ook de CPU en het RAM-geheugen zijn van belang.

Factoren die de belasting op de Operations Manager-database beïnvloeden, zijn:

• De frequentie waarmee operationele gegevens worden verzameld. Operationele gegevens bestaan uit alle gebeurtenissen, waarschuwingen, statuswijzigingen en prestatiegegevens die door agents worden verzameld. De meeste resources die door de Operations Manager-database worden gebruikt, worden ingezet om deze gegevens naar de schijf te schrijven zoals ze in het systeem worden aangeleverd. De frequentie waarmee operationele gegevens worden verzameld, wordt doorgaans hoger naarmate er meer management packs worden geïmporteerd en extra agents worden toegevoegd. Het type computer dat door een agent wordt bewaakt, speelt ook een belangrijke rol bij het bepalen van de algemene frequentie waarmee operationele gegevens worden verzameld. Van een agent die bijvoorbeeld een bedrijfskritieke desktopcomputer bewaakt, wordt verwacht dat deze minder gegevens verzamelt dan een agent die een server bewaakt waarop een exemplaar van SQL Server met een groot aantal databases wordt uitgevoerd.
• De snelheid waarmee de exemplaarruimte verandert. Het bijwerken van deze gegevens in de Operations Manager-database is duur in vergelijking met het schrijven van nieuwe operationele gegevens. Wanneer gegevens in de exemplaarruimte worden gewijzigd, moeten de beheerservers bovendien extra query's naar de Operations Manager-database sturen om configuratie- en groepswijzigingen te berekenen. De frequentie waarmee de exemplaarruimte verandert, neemt toe naarmate u extra management packs in een beheergroep importeert. Wanneer nieuwe agents aan een beheergroep worden toegevoegd, verhoogt ook tijdelijk de snelheid waarmee de exemplaarruimte verandert.
• Het aantal Operations-consoles en andere SDK-verbindingen dat tegelijk wordt uitgevoerd. Elke Operations-console leest gegevens uit de Operations Manager-database. Het uitvoeren van query's op deze gegevens verbruikt mogelijk veel I/O-opslagbronnen, CPU-tijd en RAM-geheugen. Operations-consoles die in de weergave Gebeurtenis, Status, Waarschuwing en Prestatiegegevens grote hoeveelheden operationele gegevens weergeven, zorgen doorgaans voor de grootste belasting op de database.

De Operations Manager-database is één foutenbron voor de beheergroep. Deze kan dus maximaal beschikbaar worden gemaakt met behulp van ondersteunde failoverconfiguraties zoals SQL Server Always On-beschikbaarheidsgroepen of failover-clusterexemplaren.

U kunt Operations Manager-databases instellen en upgraden met een bestaande SQL-Always-On-installatie zonder dat er na de configuratie wijzigingen nodig zijn.

SQL Broker inschakelen in de Operations Manager-database

System Center Operations Manager is afhankelijk van SQL Server Service Broker om alle taakbewerkingen te implementeren. Als SQL Server Service Broker is uitgeschakeld, worden alle taakbewerkingen beïnvloed. Het resulterende gedrag kan variëren, afhankelijk van de taak die wordt gestart. Daarom is het belangrijk om de status van SQL Server Service Broker te controleren wanneer onverwacht gedrag wordt waargenomen rond een taak in System Center Operations Manager.

Voer de volgende stappen uit om SQL Server Service Broker in te schakelen:

1. Voer de volgende SQL-query uit:

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

2. Sla deze stap over als de waarde die wordt weergegeven in het is_broker_enabled veld 1 (één) is. Anders voert u de volgende SQL-query's uit:

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

Operations Manager-datawarehouse-database

System Center - Operations Manager voegt gegevens in bijna realtime in het rapportagedatawarehouse in. Het is belangrijk dat er voldoende capaciteit op deze server is die ondersteuning biedt voor het schrijven van alle gegevens die worden verzameld naar het rapportagedatawarehouse. Net als voor de Operations Manager-database is ook in het Rapportagedatawarehouse het I/O-subsysteem voor opslag de meest kritieke resource. Op de meeste systemen zijn de belasting van het rapportagedatawarehouse vergelijkbaar met de Operations Manager-database, maar deze kunnen variëren. Bovendien is de werkbelasting die door rapportage op het Rapportagedatawarehouse wordt geplaatst anders dan de werkbelasting die door het gebruik van de Operations-console op de Operations Manager-database wordt geplaatst.

Dit zijn enkele factoren die de werkbelasting van het Rapportagedatawarehouse beïnvloeden:

• De frequentie waarmee operationele gegevens worden verzameld. Voor een efficiëntere rapportage worden door het Rapportagedatawarehouse niet alleen geaggregeerde gegevens berekend en opgeslagen, maar ook een beperkte hoeveelheid ruwe gegevens. Door dit extra werk is het verzamelen van operationele gegevens in het Rapportagedatawarehouse mogelijk iets duurder dan in de Operations Manager-database. Deze extra kosten worden doorgaans gecompenseerd door de lagere kosten van het verwerken van detectiegegevens door het Rapportagedatawarehouse in vergelijking met die van de Operations Manager-database.
• Het aantal gelijktijdige rapportagegebruikers of het aantal geplande rapporten dat gelijktijdig wordt gegenereerd. Aangezien rapporten vaak grote hoeveelheden gegevens samenvatten, kan elke rapportagegebruiker het systeem aanzienlijk extra belasten. Het aantal rapporten dat gelijktijdig wordt uitgevoerd en het type rapporten dat wordt uitgevoerd, hebben allebei invloed op de totale behoeften aan capaciteit. Over het algemeen vereisen rapporten die query's uitvoeren op grote datumbereiken of op een groot aantal objecten meer systeemresources.

Op basis van deze factoren zijn er verschillende aanbevolen procedures om te overwegen bij het aanpassen van de grootte van het rapportagedatawarehouse:

• Kies een geschikt opslagsubsysteem. Omdat het rapportagedatawarehouse een integraal onderdeel is van de algehele gegevensstroom door de beheergroep, is het belangrijk om een geschikt opslagsubsysteem voor het rapportagedatawarehouse te kiezen. Net als bij de Operations Manager-database is RAID 0 + 1 vaak de beste keuze. In het algemeen moet het opslagsubsysteem voor het Rapportagedatawarehouse vergelijkbaar zijn met het opslagsubsysteem voor de Operations Manager-database en is de richtlijn die voor de Operations Manager-database geldt, ook van toepassing op het Rapportagedatawarehouse.
• Overweeg de juiste plaatsing van gegevenslogboeken en transactielogboeken. Voor de Operations Manager-database is het scheiden van SQL-gegevens en transactielogboeken vaak een geschikte keuze wanneer u het aantal agents omhoog schaalt. Als de Operations Manager-database en het Rapportagedatawarehouse zich op dezelfde server bevinden en u gegevens en transactielogboeken van elkaar wilt scheiden, moet u de transactielogboeken voor de Operations Manager-database op een afzonderlijk fysiek volume en afzonderlijke schijfaandrijfassen plaatsen opdat het Rapportagedatawarehouse hier enig voordeel uit haalt. De gegevensbestanden voor de Operations Manager-database en het rapportagedatawarehouse kunnen hetzelfde fysieke volume delen zolang het volume voldoende capaciteit biedt en de I/O-prestaties van de schijf geen negatieve invloed hebben op de bewakings- en rapportagefunctionaliteit.
• Overweeg om het Rapportagedatawarehouse op een andere server te plaatsen dan die van de Operations Manager-database. Hoewel kleinere implementaties vaak de Operations Manager-database en het rapportagedatawarehouse op dezelfde server kunnen consolideren, is het voordelig om ze te scheiden wanneer u het aantal agents en het volume van binnenkomende operationele gegevens omhoog schaalt. Wanneer het rapportagedatawarehouse en de rapportageserver zich op een afzonderlijke server van de Operations Manager-database bevinden, ervaart u betere rapportageprestaties.

De Operations Manager-datawarehouse-database is één foutenbron voor de beheergroep. Deze kan dus maximaal beschikbaar worden gemaakt met behulp van ondersteunde failoverconfiguraties zoals SQL Server Always On-beschikbaarheidsgroepen of failover-clusterexemplaren.

SQL Server Always On

Always On-beschikbaarheidsgroepen voor SQL Server ondersteunen failoveromgevingen voor een afzonderlijke set met gebruikersdatabases (beschikbaarheidsdatabases). Elke set met beschikbaarheidsdatabases wordt gehost door een beschikbaarheidsreplica.

Met System Center 2016 en hoger - Operations Manager heeft SQL AlwaysOn de voorkeur boven failoverclustering om hoge beschikbaarheid voor databases te bieden. Alle databases, met uitzondering van de native modus van de Reporting Services-installatie, die gebruikmaakt van twee databases om permanente gegevensopslag te scheiden van de vereisten voor tijdelijke opslag, kunnen in een Always On-beschikbaarheidsgroep worden gehost.

Met Operations Manager 2022 kunt u Operations Manager-databases instellen en upgraden met een bestaande SQL-Always-On-installatie zonder dat er na de configuratie wijzigingen nodig zijn.

Als u een beschikbaarheidsgroep wilt instellen, moet u een WSFC-cluster (Windows Server Failover Clustering) implementeren om de beschikbaarheidsreplica te hosten en AlwaysOn inschakelen op de clusterknooppunten. Vervolgens kunt u de Operations Manager SQL Server-database als een beschikbaarheidsdatabase toevoegen.

• Meer informatie over de vereisten voor AlwaysOn.
• Meer informatie over het instellen van een WSFC voor AlwaysOn-beschikbaarheidsgroepen.
• Meer informatie over het instellen van een beschikbaarheidsgroep.

Notitie

Nadat u Operations Manager hebt geïmplementeerd op de SQL-serverknooppunten die deelnemen aan SQL AlwaysOn, voert u het SQL-script uit op elke Operations Manager-database om clr strikte beveiliging in te schakelen.

Tekenreeks met meerdere subnetten

Operations Manager biedt geen ondersteuning voor de verbindingsreeks sleutelwoorden (MultiSubnetFailover=True). Omdat een beschikbaarheidsgroep een listenernaam heeft (ook wel bekend als de netwerknaam of clienttoegangspunt in WSFC-clusterbeheer), afhankelijk van meerdere IP-adressen van verschillende subnetten, bijvoorbeeld wanneer u implementeert in een failoverconfiguratie op meerdere sites, krijgen clientverbindingsaanvragen van beheerservers naar de listener van de beschikbaarheidsgroep een verbindingstime-out.

De aanbevolen aanpak om deze beperking te omzeilen wanneer u serverknooppunten in de beschikbaarheidsgroep in een omgeving met meerdere subnetten hebt geïmplementeerd, is het volgende te doen:

1. Stel de netwerknaam van de listener van uw beschikbaarheidsgroep in op slechts één actief IP-adres in DNS te registreren.
2. Configureer het cluster om een lage TTL-waarde te gebruiken voor de geregistreerde DNS-record.

Met deze instellingen kunt u, bij een failover naar een knooppunt in een ander subnet, de clusternaam met het nieuwe IP-adres sneller herstellen en omzetten.

Voer de volgende PowerShell-opdrachten uit op een van de SQL-knooppunten om de instellingen te wijzigen:

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"

Als u AlwaysOn gebruikt met een listenernaam, moet u deze configuratiewijzigingen ook aanbrengen op de listener. Zie de documentatie hier voor meer informatie over het configureren van een listener voor beschikbaarheidsgroepen: Listener voor beschikbaarheidsgroepen configureren - SQL Server AlwaysOn

Voer de volgende PowerShell-opdrachten uit op het SQL-knooppunt dat momenteel als host fungeert voor de listener om de instellingen te wijzigen:

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>

Wanneer een geclusterd of AlwaysOn SQL-exemplaar wordt gebruikt voor hoge beschikbaarheid, moet u de functie voor automatisch herstel op uw beheerservers inschakelen om te voorkomen dat de Operations Manager Data Access-service opnieuw wordt opgestart wanneer er een failover tussen knooppunten plaatsvindt. Zie het volgende KB-artikel De System Center Management-service reageert niet meer nadat een exemplaar van SQL Server offline gaat voor meer informatie over het configureren hiervan.

SQL Server optimaliseren

In het algemeen blijkt uit eerdere implementatie-ervaringen met klanten dat prestatieproblemen meestal niet worden veroorzaakt door een hoog resourcegebruik (dat wil gezegd, processor of geheugen) met SQL Server zelf; het is eerder rechtstreeks gerelateerd aan de configuratie van het opslagsubsysteem. Prestatieknelpunten worden meestal toegeschreven aan het niet volgen van de aanbevolen configuratierichtlijnen met de opslag die is ingericht voor het SQL Server database-exemplaar. Voorbeelden hiervan zijn:

• Er zijn onvoldoende aandrijfassen toegewezen opdat de I/O-vereisten van Operations Manager door de LUN's kunnen worden ondersteund.
• Transactielogboeken en databasebestanden worden op hetzelfde volume gehost. Deze twee workloads hebben verschillende I/O- en latentiekenmerken.
• De configuratie van TempDB is onjuist met betrekking tot plaatsing, groottebepaling, enzovoort.
• Onjuiste uitlijning van schijfpartitievolumes die als host fungeren voor de databasetransactielogboeken, databasebestanden en TempDB.
• Met uitzicht op de basisconfiguratie SQL Server, zoals het gebruik van AUTOGROW voor database- en transactielogboekbestanden, MAXDOP-instelling voor queryparallellisme, het maken van meerdere TempDB-gegevensbestanden per CPU-kern, enzovoort.

Opslagconfiguratie is een van de essentiële onderdelen voor een SQL Server-implementatie voor Operations Manager. Databaseservers zijn meestal sterk I/O-gebonden vanwege strengere lees- en schrijfactiviteiten in databases en de verwerking van transactielogboeken. Het I/O-gedragspatroon van Operations Manager bestaat doorgaans uit 80% schrijf- en 20% leesbewerkingen. Als gevolg hiervan kan een onjuiste configuratie van I/O-subsystemen leiden tot slechte prestaties en werking van SQL Server-systemen, wat merkbaar is in Operations Manager.

Het is belangrijk om het SQL Server ontwerp te testen door doorvoertests van het IO-subsysteem uit te voeren voordat u SQL Server implementeert. Zorg ervoor dat deze tests uw I/O-vereisten kunnen bereiken met een acceptabele latentie. Gebruik het hulpprogramma Diskspd om de I/O-capaciteit te evalueren van het opslagsubsysteem dat SQL Server ondersteunt. Het volgende blogartikel, geschreven door een lid van het bestandsserverteam in de productgroep, bevat gedetailleerde richtlijnen en aanbevelingen voor het uitvoeren van stresstests met behulp van dit hulpprogramma met powershell-code en het vastleggen van de resultaten met Behulp van PerfMon. U kunt ook de Helper voor het aanpassen van de grootte van Operations Manager raadplegen voor de eerste hulp.

Grootte van NTFS-toewijzingseenheid

Volume-uitlijning, ook wel sectoruitlijning genoemd, moet worden uitgevoerd op het bestandssysteem (NTFS) wanneer een volume op een RAID-apparaat wordt gemaakt. Als u dit niet doet, kan dit leiden tot aanzienlijke prestatievermindering en is meestal het gevolg van onjuiste uitlijning van partities met de grenzen van stripe-eenheden. Dit kan ook leiden tot onjuiste uitlijning van de hardwarecache, wat resulteert in inefficiënt gebruik van de matrixcache. Bij het opmaken van de partitie die wordt gebruikt voor SQL Server gegevensbestanden, is het raadzaam om een toewijzingseenheid van 64 kB (dat wil gezegd, 65.536 bytes) te gebruiken voor gegevens, logboeken en tempdb. Houd er echter rekening mee dat het gebruik van toewijzingseenheden groter dan 4 kB resulteert in het onvermogen om NTFS-compressie op het volume te gebruiken. Hoewel SQL Server alleen-lezengegevens op gecomprimeerde volumes ondersteunt, wordt dit niet aanbevolen.

Geheugen reserveren

Notitie

Veel van de informatie in deze sectie is afkomstig van Jonathan Kehayias in zijn blogpost Hoeveel geheugen heeft mijn SQL Server eigenlijk nodig? (sqlskills.com).

Het is niet altijd eenvoudig om de juiste hoeveelheid fysiek geheugen en processors te identificeren die moeten worden toegewezen aan SQL Server ter ondersteuning van System Center Operations Manager (of voor andere workloads buiten dit product). De groottecalculator van de productgroep biedt richtlijnen op basis van workloadschaal, maar de aanbevelingen zijn gebaseerd op tests die worden uitgevoerd in een testomgeving die al dan niet is afgestemd op uw werkelijke workload en configuratie.

met SQL Server kunt u de minimale en maximale hoeveelheid geheugen configureren die door het proces wordt gereserveerd en gebruikt. SQL Server kan de geheugenvereisten standaard dynamisch wijzigen op basis van beschikbare systeemresources. De standaardinstelling voor minimaal servergeheugen is 0 en de standaardinstelling voor maximaal servergeheugen is 2.147.483.647 MB.

Prestatie- en geheugenproblemen kunnen zich voordoen als u geen geschikte waarde instelt voor het maximale servergeheugen. Veel factoren zijn van invloed op de hoeveelheid geheugen die u moet toewijzen aan SQL Server om ervoor te zorgen dat het besturingssysteem ondersteuning kan bieden voor andere processen die op dat systeem worden uitgevoerd, zoals de HBA-kaart, beheeragents en realtime scannen van antivirusprogramma's. Als er onvoldoende geheugen is ingesteld, worden het besturingssysteem en SQL naar de schijf weergegeven. Dit kan ertoe leiden dat de I/O van de schijf toeneemt, waardoor de prestaties verder afnemen en er een rimpeleffect ontstaat waarbij dit merkbaar wordt in Operations Manager.

U wordt aangeraden ten minste 4 GB RAM op te geven voor minimaal servergeheugen. Dit moet worden gedaan voor elk SQL-knooppunt dat als host fungeert voor een van de Operations Manager-databases (operationeel, datawarehouse, ACS).

Voor maximaal servergeheugen raden we u aan om in eerste instantie een totaal van:

• 1 GB RAM voor het besturingssysteem
• 1 GB RAM per 4 GB RAM-geheugen (maximaal 16 GB RAM)
• 1 GB RAM per 8 GB RAM-geheugen (meer dan 16 GB RAM)

Nadat u deze waarden hebt ingesteld, controleert u de teller Memory\Available MBytes in Windows om te bepalen of u het beschikbare geheugen voor SQL Server kunt vergroten. Windows geeft aan dat het beschikbare fysieke geheugen op 96 MB bijna leeg is, dus in het ideale geval moet de teller niet lager zijn dan ongeveer 200-300 MB, om ervoor te zorgen dat u een buffer hebt. Voor servers met 256 GB RAM of hoger wilt u er waarschijnlijk voor zorgen dat deze niet minder dan 1 GB wordt uitgevoerd.

Houd er rekening mee dat u bij deze berekeningen ervan uitgaat dat SQL Server alle beschikbare geheugen moet kunnen gebruiken, tenzij u deze wijzigt om rekening te houden met andere toepassingen. Houd rekening met de specifieke geheugenvereisten voor uw besturingssysteem, andere toepassingen, de SQL Server threadstack en andere toewijzingen met meerdere pagina's. Een typische formule is ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), waarbij het geheugen voor threadstack = is ((max worker threads) (stack size)). De stackgrootte is 512 KB voor x86-systemen, 2 MB voor x64-systemen en 4 MB voor IA64-systemen. U vindt de waarde voor het maximum aantal werkrolthreads in de kolom max_worker_count van sys.dm_os_sys_info.

Deze overwegingen zijn ook van toepassing op de geheugenvereisten voor SQL Server worden uitgevoerd op een virtuele machine. Omdat SQL Server is ontworpen om gegevens in de buffergroep in de cache op te slaan en meestal zoveel mogelijk geheugen gebruikt, kan het lastig zijn om de ideale hoeveelheid RAM-geheugen te bepalen die nodig is. Wanneer u het geheugen vermindert dat is toegewezen aan een SQL Server-exemplaar, bereikt u uiteindelijk een punt waarop lagere geheugentoewijzing wordt ingewisseld voor hogere schijf-I/O-toegang.

Als u SQL Server geheugen wilt configureren in een omgeving die te veel is ingericht, begint u met het bewaken van de omgeving en de huidige metrische prestatiegegevens, waaronder de waarden voor de levensduur van de pagina SQL Server bufferbeheer en pagina-leesbewerkingen per seconde en de leesbewerkingen per seconde van de fysieke schijf. Als de omgeving een overschot aan geheugen heeft, neemt de levensverwachting van de pagina met een waarde van één seconde toe zonder dat er een afname van de werkbelasting optreedt als gevolg van caching; de SQL Server waarde voor leesbewerkingen per seconde van de pagina Bufferbeheer is laag nadat de cache is opgevoerd; en de leesbewerkingen van de fysieke schijfschijf per seconde blijven ook laag.

Zodra u de omgevingsbasislijn begrijpt, kunt u het maximale servergeheugen met 1 GB verminderen en zien hoe dit van invloed is op uw prestatiemeteritems (nadat de eerste cache is leeggemaakt). Als de metrische gegevens acceptabel blijven, vermindert u met nog eens 1 GB en controleert u opnieuw, waarbij u deze naar wens herhaalt totdat u een ideale configuratie hebt vastgesteld.

Zie Configuratieopties voor servergeheugen voor meer informatie.

TempDB optimaliseren

De grootte en de fysieke plaatsing van de tempdb-database kunnen invloed hebben op de prestaties van Operations Manager. Als bijvoorbeeld de grootte die voor tempdb is gedefinieerd te klein is, kan een deel van de werkbelasting van de systeemverwerking worden verwerkt door tempdb met automatische groei (AutoGrow) uit te breiden tot de grootte die vereist is om de werkbelasting te ondersteunen telkens wanneer u het exemplaar van SQL Server opnieuw opstart. Als u tempdb optimaal wilt laten presteren, kunt u het best de volgende configuratie voor tempdb in een productieomgeving gebruiken:

• Stel het herstelmodel van tempdb in op EENVOUDIG. Dit model maakt logboekruimte automatisch weer vrij om de benodigde ruimte klein te houden.
• Wijs vooraf ruimte voor alle tempdb-bestanden toe door de bestandsgrootte in te stellen op een waarde die groot genoeg is voor de typische werkbelasting in de omgeving. Hiermee voorkomt u dat tempdb te vaak wordt uitgebreid, wat de prestaties kan beïnvloeden. De tempdb-database kan worden ingesteld op automatische groei, maar die mogelijkheid moet worden gebruikt om de schijfruimte te verhogen voor niet-geplande uitzonderingen.
• Maak net zo veel bestanden als nodig om de bandbreedte van de schijf te maximaliseren. Het gebruik van meerdere bestanden vermindert tempdb-opslagconflicten en levert een verbeterde schaalbaarheid op. Maak echter niet te veel bestanden, omdat dit de prestaties kan verminderen en de beheeroverhead kan verhogen. Als algemene richtlijn maakt u één gegevensbestand voor elke logische processor op de server (rekening houdend met instellingen voor het affiniteitsmasker) en verhoogt of verlaagt u vervolgens zo nodig het aantal bestanden. Wanneer het aantal logische processors kleiner dan of gelijk aan 8 is, gebruikt u over het algemeen net zoveel gegevensbestanden als logische processors. Als het aantal logische processors groter is dan 8, gebruikt u acht gegevensbestanden. Als het conflict zich blijft voordoen, verhoogt u het aantal gegevensbestanden met veelvouden van 4 (tot het aantal logische processors) totdat het conflict tot een acceptabel niveau is teruggebracht of wijzigingen aanbrengt in de workload/code. Als het conflict niet wordt verminderd, moet u mogelijk het aantal gegevensbestanden meer verhogen.
• Zorg ervoor dat elk gegevensbestand dezelfde grootte heeft, zodat de prestaties van proportioneel doorvoeren optimaal zijn. Het is essentieel dat de gegevensbestanden even groot worden gemaakt omdat het algoritme voor evenredige opvulling gebaseerd is op de grootte van de bestanden. Als gegevensbestanden worden gemaakt die niet even groot zijn, probeert het algoritme voor evenredige opvulling het grootste bestand meer te gebruiken voor GAM-toewijzingen in plaats van de toewijzingen te spreiden tussen alle bestanden, waardoor het weinig nut heeft meerdere gegevensbestanden te maken.
• Plaats de tempdb-database op een snel I/O-subsysteem met solid-state drives voor de meest optimale prestaties. Gebruik schijfsegmentering (disk striping) als er veel rechtstreeks aangesloten schijven zijn.
• Plaats de tempdb-database op andere schijven dan degene die door gebruikersdatabases worden gebruikt.

Als u tempdb wilt configureren, kunt u de volgende query uitvoeren of de eigenschappen ervan wijzigen in 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

Voer de T-SQL-query SELECT * from sys.sysprocesses uit om paginatoewijzingsconflicten voor de tempdb-database te detecteren. In de uitvoer van de systeemtabel kan de wachtresource worden weergegeven als '2:1:1' (PFS-pagina) of '2:1:3' (Gedeelde globale toewijzingskaartpagina). Afhankelijk van de graad van conflicten kan dit er ook toe leiden dat SQL Server even niet lijkt te reageren. Een andere benadering is het onderzoeken van de dynamische beheerweergaven [sys.dm_exec_request of sys.dm_os_waiting_tasks]. De resultaten laten zien dat deze aanvragen of taken wachten op tempdb-resources en vergelijkbare waarden hebben zoals eerder is gemarkeerd wanneer u de sys.sysprocesses-query uitvoert.

Als de vorige aanbevelingen het toewijzingsconflict niet aanzienlijk verminderen en het conflict zich op SGAM-pagina's bevindt, implementeert u traceringsvlag -T1118 in de opstartparameters voor SQL Server, zodat de traceringsvlag van kracht blijft, zelfs nadat SQL Server is gerecycled. Onder deze traceringsvlag wijst SQL Server volledige gebieden toe aan elk databaseobject, waardoor de conflicten op SGAM's worden verholpen.

Notitie

Deze traceringsvlag is van invloed op elke database op het exemplaar van SQL Server.

Maximale graad van parallelle uitvoering

De standaardconfiguratie van SQL Server voor kleine tot middelgrote implementaties van Operations Manager volstaat voor de meeste behoeften. Wanneer de workload van de beheergroep echter omhoog wordt geschaald naar een bedrijfsscenario (meestal meer dan 2000 door agents beheerde systemen en een geavanceerde bewakingsconfiguratie, waaronder bewaking op serviceniveau met geavanceerde synthetische transacties, bewaking van netwerkapparaten, platformoverschrijdende, enzovoort), moet de configuratie van SQL Server die in dit gedeelte van het document worden beschreven, worden geoptimaliseerd. Een configuratieoptie die niet is besproken in de vorige richtlijnen, is MAXDOP.

De Microsoft SQL Server-configuratieoptie voor maximale graad van parallelle uitvoering (MAXDOP) bepaalt het aantal processors dat wordt gebruikt om een query in een parallel plan uit te voeren. Deze optie bepaalt het aantal reken- en threadresources dat wordt gebruikt voor de operators van het queryplan, die het werk parallel uitvoeren. Afhankelijk van of SQL Server is ingesteld op een SMP-computer (symmetrische multiprocessing), een NUMA-computer (Non-Uniform Memory Access) of processors met hyperthreading, moet u de optie voor maximale mate van parallelle uitvoering op de juiste manier configureren.

Wanneer SQL Server wordt uitgevoerd op een computer met meer dan één microprocessor of CPU, detecteert de computer de beste graad van parallelle uitvoering (het aantal processors dat wordt ingezet om één instructie uit te voeren, voor de uitvoering van elk parallel plan). De waarde voor deze optie is standaard 0, waardoor SQL Server de maximale graad van parallelle uitvoering kan bepalen.

De opgeslagen procedures en query's die vooraf zijn gedefinieerd in Operations Manager, omdat deze betrekking hebben op de operationele, datawarehouse- en zelfs auditdatabase, bevatten niet de MAXDOP-optie, omdat er tijdens de installatie geen manier is om dynamisch op te vragen hoeveel processors er aan het besturingssysteem worden gepresenteerd. Evenmin wordt geprobeerd de waarde voor deze instelling vast te stellen, wat negatieve gevolgen kan hebben wanneer de query wordt uitgevoerd.

Notitie

De maximale mate van parallelle configuratie beperkt niet het aantal processors dat de SQL Server gebruikt. Gebruik de configuratieoptie voor het affiniteitsmasker om het aantal processors dat door SQL Server wordt gebruikt te configureren.

• Voor servers die gebruikmaken van meer dan acht processors, gebruikt u deze configuratie: MAXDOP=8
• Voor servers die acht of minder processors gebruiken, gebruikt u de volgende configuratie: MAXDOP=0 tot N

  Notitie

  In deze configuratie vertegenwoordigt N het aantal processors.