Designöverväganden för SQL Server

System Center Operations Manager kräver åtkomst till en instans av en server som kör Microsoft SQL Server för att stödja driftdatabasen, informationslagret och ACS-granskningsdatabasen. Driftdatabasen och informationslagerdatabasen krävs och skapas när du distribuerar den första hanteringsservern i hanteringsgruppen, medan ACS-databasen skapas när du distribuerar en ACS-insamlare i hanteringsgruppen.

I en laboratoriemiljö eller vid en småskalig distribution av Operations Manager kan SQL Server vara samordnad på den första hanteringsservern i hanteringsgruppen.

I en distribution på medelhög nivå till företagsnivå ska SQL Server-instansen finns på en dedikerad fristående server eller i en SQL Server-konfiguration med hög tillgänglighet. I vilket fall måste instansen av Microsoft SQL Server redan finnas och vara tillgänglig innan du påbörjar installationen av den första hanteringsservern eller ACS-insamlaren.

Vi rekommenderar inte användning av Operations Manager-databaser från en SQL-instans som har andra programdatabaser. Detta är för att undvika eventuella problem med I/O och andra begränsningar för maskinvaruresurser.

Viktigt

Operations Manager stöder inte PaaS-instanser (Platform as a Service) av SQL, inklusive produkter som Azure SQL Managed Instance eller Amazon Relational Database Service (AWS RDS). Använd en instans av SQL Server som är installerad på en Windows-dator. Det enda undantaget till detta är i Azure Monitor SCOM Managed Instance, som använder Azure SQL MI och inte kan konfigureras om.

SQL Server-krav

Följande versioner av SQL Server Enterprise & Standard Edition stöds för en befintlig installation av System Center Operations Manager-versionen som värd för Rapportserver, Drift, Data Warehouse och ACS-databas:

• SQL Server 2022

• SQL Server 2019 med kumulativ uppdatering 8 (CU8) eller senare enligt beskrivningen här

  Anteckning

  • Operations Manager 2022 stöder SQL 2019 med CU8 eller senare. Den stöder dock inte SQL 2019 RTM.
  • Använd ODBC 17.3 eller senare och MSOLEDBSQL 18.2 eller senare.

• SQL Server 2017 och kumulativ Uppdateringar enligt beskrivningen här

Innan du uppgraderar SQL Server kan du läsa uppgraderingsinformation för 2017 och uppgraderingsinformation för SQL 2019.

Anteckning

• Var och en av följande SQL Server komponenter som stöder en SCOM-infrastruktur måste ha samma SQL Server huvudversion:
  • SQL Server databasmotorinstanser som är värdar för någon av SCOM-databaserna (dvs. OperationManager-, OperationManagerDW- och SSRS-databaserna ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services-instans (SSRS).
• Inställningen SQL Server sortering måste vara en av de typer som stöds enligt beskrivningen i avsnittet SQL Server sorteringsinställning nedan.
• SQL Server fulltextsökning krävs för alla SQL Server databasmotorinstanser som är värdar för någon av SCOM-databaserna.
• De Windows Server 2016 installationsalternativen (Server Core, Server med skrivbordsmiljö och Nano Server) som stöds av Operations Manager-databaskomponenter baseras på vilka installationsalternativ för Windows Server som stöds av SQL Server.

Anteckning

System Center Operations Manager Reporting kan inte installeras sida vid sida med en tidigare version av rapportrollen och måste endast installeras i enhetligt läge (SharePoint-integrerat läge stöds inte).

Ytterligare överväganden för maskin- och programvara vid planering av din design:

• Vi rekommenderar att du kör SQL Server på datorer med NTFS-filformatet.
• Det måste finnas minst 1 024 MB ledigt diskutrymme för driftdatabasen och informationslagerdatabasen. Den framtvingas när databasen skapas och kommer sannolikt att växa avsevärt efter installationen.
• .NET Framework 4 krävs.
• .NET Framework 4.8 stöds från Operations Manager 2022.
• Reporting Server stöds inte på Windows Server Core.

Mer information finns i Maskinvaru- och programvarukrav för att installera SQL Server.

Anteckning

Även om Operations Manager endast använder Windows-autentisering under installationen fungerar autentiseringsinställningen för blandat SQL-läge fortfarande om inget lokalt konto har den db_owner rollen. Lokala konton med db_owner roll är kända för att orsaka problem med System Center Operations Manager. Ta bort rollen db_owner från alla lokala konton innan du installerar produkten och lägg inte till rollen db_owner till något av de lokala kontona efter installationen.

Sorteringsinställningar för SQL Server

Följande SQL Server och Windows-sortering stöds av System Center Operations Manager.

Anteckning

För att undvika kompatibilitetsproblem vid jämförelse eller kopiering rekommenderar vi att du använder samma sortering för SQL- och Operations Manager-databasen.

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

Om din SQL Server-instans inte har konfigurerats med någon av de sorteringar som stöds ovan misslyckas en ny installation av Operations Manager-installationen. En uppgradering bör däremot lyckas.

Konfigurering av brandvägg

Operations Manager är beroende av SQL Server som värd för databaserna och en rapporteringsplattform att analysera och presentera historiska driftdata. Hanteringsserver-, drift- och webbkonsolrollerna måste kunna kommunicera med SQL Server och det är viktigt att förstå kommunikationssökvägen och portarna för att kunna konfigurera din miljö korrekt.

Om du utformar en distribuerad distribution som kräver SQL AlwaysOn-tillgänglighetsgrupper för att tillhandahålla redundansfunktioner för Operations Manager-databaserna finns det ytterligare konfigurationsinställningar för brandväggen som måste ingå i brandväggens säkerhetsstrategi.

I följande tabell kan du identifiera brandväggsportar som krävs av SQL Server som behöver tillåtas som ett minimum för att serverroller i din Operations Manager-hanteringsgrupp ska kunna kommunicera.

Scenario	Port	Riktning	Operations Manager-roll
SQL Server som är värd för Operations Manager-databaser	TCP 1433 *	Inkommande	hanteringsserver och webbkonsol (för Programkontroll och Programdiagnostik)
Tjänsten SQL Server Browser	UDP 1434	Inkommande	hanteringsserver
SQL Server-dedicerad administrationsanslutning	TCP 1434	Inkommande	hanteringsserver
Ytterligare portar som används av SQL Server – Microsofts fjärrproceduranrop (MS RPC) – Windows Management Instrumentation (WMI) – Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Inkommande	hanteringsserver
Ständigt aktiverad lyssningsfunktion för tillgänglighetsgrupp i SQL Server	Administratörskonfigurerad port	Inkommande	hanteringsserver
SQL Server Reporting Services som är värd för Operations Manager Reporting Server	TCP 80 (standard)/443 (SSL)	Inkommande	hanteringsserver och driftkonsol

* TCP 1433 är standardporten för standardinstansen av databasmotorn, men när du skapar en namngiven instans på en fristående SQL Server eller har distribuerat en SQL AlwaysOn-tillgänglighetsgrupp, definieras en anpassad port och dokumenteras som referens så att du konfigurerar brandväggarna korrekt och anger den här informationen under installationen.

En mer detaljerad översikt över brandväggskraven för SQL Server finns i Konfigurera Windows-brandväggen för att tillåta SQL Server åtkomst.

Överväganden rörande kapacitet och lagring

Operations Manager-databas

Operations Manager-databasen är en SQL Server-databas som innehåller alla de data som krävs av Operations Manager för daglig övervakning. Databasserverns storlek och konfiguration är avgörande för övergripande prestanda hos hanteringsgruppen. Den mest kritiska resurs som används av Operations Manager-databasen är underlagringssystemet, men processor och RAM-minne har också betydelse.

Följande faktorer påverkar belastningen på Operations Manager-databasen:

• Frekvens vid insamling av driftdata. Driftdata består av alla händelser, varningar, tillståndsändringar och prestandadata som samlats in av agenterna. De flesta av de resurser som används av Operations Manager-databasen används för att skriva dessa data till disk när de kommer in i systemet. Frekvensen för driftdata som samlas in tenderar att öka i takt med att ytterligare hanteringspaket importeras och fler agenter läggs till. Den typ av dator som en agent övervakar också en viktig faktor som används vid fastställande av övergripande frekvens för insamling av driftdata. Exempelvis kan en agent som övervakar en verksamhetskritisk stationär dator förväntas samla in mindre mängd data än en agent som övervakar en server som kör en instans av SQL Server med ett stort antal databaser.
• Instansutrymmets förändringsfrekvens. Att uppdatera data i Operations Manager-databasen är dyrt i förhållande till att skriva nya driftdata. När utrymmesinstansdata ändras skickar hanteringsservrarna dessutom extra frågor till Operations Manager-databasen för att kunna beräkna konfigurations- och gruppändringar. Instansutrymmesändringarnas frekvens ökar när du importerar ytterligare hanteringspaket till en hanteringsgrupp. Att lägga till nya agenter till en hanteringsgrupp ökar också tillfälligt utrymmesändringarnas frekvens.
• Antalet driftkonsoler och andra SDK-anslutningar som körs samtidigt. Varje driftkonsol läser data från Operations Manager-databasen. Denna datafrågan förbrukar potentiellt stora mängder I/O-lagringsresurser, mycket processortid och en stor andel RAM-minne. Driftkonsoler som visar stora mängder driftdata i händelsevyn, tillståndsvyn, aviseringsvyn, och prestandadatavyn har en tendens att orsaka den största belastningen på databasen.

Operations Manager-databasen är en enskild felkälla för hanteringsgruppen, och kan därför konfigureras för hög tillgänglighet med hjälp av redundanskonfigurationer som stöds, exempelvis ständigt aktiverade SQL Server-tillgänglighetsgrupper eller redundansklusterinstanser.

Du kan konfigurera och uppgradera Operations Manager-databaser med en befintlig SQL-Always-On utan att behöva göra ändringar efter konfigurationen.

Aktivera SQL Broker i Operations Manager-databasen

System Center Operations Manager är beroende av SQL Server Service Broker för att implementera alla aktivitetsåtgärder. Om SQL Server Service Broker är inaktiverad påverkas alla aktivitetsåtgärder. Det resulterande beteendet kan variera beroende på vilken uppgift som initieras. Därför är det viktigt att kontrollera tillståndet för SQL Server Service Broker när oväntat beteende observeras runt en uppgift i System Center Operations Manager.

Följ dessa steg för att aktivera SQL Server Service Broker:

1. Kör följande SQL-fråga:

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

2. Hoppa över det här steget om värdet som visas i fältet is_broker_enabled är 1 (ett). Annars kör du följande SQL-frågor:

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

Informationslagerdatabasen i Operations Manager

System Center – Operations Manager infogar data i informationslagret för rapportering nästan i realtid. Det är viktigt att ha tillräcklig kapacitet på den här servern som stöder skrivning av alla data som samlas in till informationslagret för rapportering. Precis som med Operations Manager-databasen är den viktigaste resursen för informationslagret för rapportering dess I/O-undersystem. I de flesta system liknar inläsningarna i informationslagret för rapportering Operations Manager-databasen, men de kan variera. Dessutom skiljer dig arbetsbelastningen på informationslagret för rapportering från den belastning som läggs på Operations Manager-databasen efter Operations-konsolanvändning.

Faktorer som påverkar belastningen på informationslagret för rapportering innefattar följande:

• Frekvens vid insamling av driftdata. Om du vill möjliggöra mer effektiv rapportering beräknar och lagrar informationslagret för rapportering sammanställda data, förutom en begränsad mängd rådata. Det här extraarbetet innebär att insamling av driftdata till informationslagret för rapportering kan vara något mer kostsamt än insamling till Operations Manager-databasen. Den här extra kostnaden vägs vanligtvis upp av minskade kostnaden för bearbetning av identifieringsdata i informationslagret för rapportering jämfört med Operations Manager-databasen.
• Antalet samtidiga rapporteringsanvändare eller schemalagd rapportgenerering. Eftersom rapporterna ofta summerar stora datavolymer kan varje rapporteringsanvändare lägga till en avsevärd belastning på systemet. Antalet rapporter som körs samtidigt och vilken typ av rapporter som körs påverkar det övergripande kapacitetsbehovet. I allmänhet kräver rapporter som frågar efter stora datumintervall eller ett stort antal objekt ytterligare systemresurser.

Baserat på dessa faktorer finns det flera rekommenderade metoder att tänka på när du ändrar storlek på informationslagret för rapportering:

• Välj ett lämpligt underlagringssystem. Eftersom informationslagret för rapportering är en integrerad del av det övergripande dataflödet genom hanteringsgruppen är det viktigt att välja ett lämpligt lagringsundersystem för informationslagret för rapportering. Precis som för Operations Manager-databasen är RAID-0 + 1 ofta det bästa valet. I allmänhet ska underlagringssystemet för informationslagret för rapportering likna underlagringssystemet för Operations Manager-databasen och de anvisningar som gäller för Operations Manager-databasen gäller även för informationslagret för rapportering.
• Tänk på korrekt placering av dataloggar kontra transaktionsloggar. När det gäller Operations Manager-databasen är det ofta lämpligt att separera SQL-data och transaktionsloggar när du skalar upp antalet agenter. Om både Operations Manager-databasen och informationslagret för rapportering finns på samma server och du vill separera data- och transaktionsloggarna, måste du placera transaktionsloggarna för Operations Manager-databasen på en separat fysisk volym och diskaxlarna från informationslagret för rapportering för att få fördelar. Datafilerna för Operations Manager-databasen och informationslagret för rapportering kan dela samma fysiska volym så länge volymen ger tillräcklig kapacitet och diskens I/O-prestanda påverkar inte övervaknings- och rapporteringsfunktionerna negativt.
• Överväg att placera informationslagret för rapportering på en annan server än Operations Manager-databasen. Även om distributioner i mindre skala ofta kan konsolidera Operations Manager-databasen och informationslagret för rapportering på samma server är det fördelaktigt att separera dem när du skalar upp antalet agenter och mängden inkommande driftdata. När informationslagret för rapportering och rapporteringsservern finns på en separat server från Operations Manager-databasen får du bättre rapporteringsprestanda.

Informationslagerdatabasen för Operations Manager utgör en enda källa för fel för hanteringsgruppen, så den kan göras högtillgänglig med hjälp av redundanskonfigurationer som stöds, till exempel ständigt aktiverade SQL Server-tillgänglighetsgrupper eller redundansklusterinstanser.

Ständig aktivering av SQL Server

Ständigt aktiverade tillgänglighetsgrupper i SQL Server ger stöd för redundansmiljöer för en diskret uppsättning användardatabaser (tillgänglighetsdatabaser). Varje uppsättning tillgänglighetsdatabaser har en tillgänglighetsreplik som värd.

Med System Center 2016 och senare – Operations Manager föredras SQL AlwaysOn framför redundansklustring för att ge hög tillgänglighet för databaser. Alla databaser utom Reporting Services-installationen med enhetligt läge, där man använder två databaser för att separera beständig datalagring från temporära lagringskrav, kan finnas i en ständigt aktiverad tillgänglighetsgrupp.

Med Operations Manager 2022 kan du konfigurera och uppgradera Operations Manager-databaser med en befintlig SQL-Always-On utan att behöva göra ändringar efter konfigurationen.

Om du vill konfigurera en tillgänglighetsgrupp måste du distribuera ett WSFC-kluster (Windows Server Failover Clustering) som värd för tillgänglighetsrepliken och aktivera AlwaysOn på klusternoderna. Sedan kan du lägga till Operations Manager SQL Server-databasen som en tillgänglighetsdatabas.

• Läs mer om krav för AlwaysOn.
• Läs mer om hur du konfigurerar en WSFC för AlwaysOn-tillgänglighetsgrupper.
• Läs mer om hur du konfigurerar en tillgänglighetsgrupp.

Anteckning

När du har distribuerat Operations Manager på DE SQL-servernoder som deltar i SQL AlwaysOn, kör du SQL-skriptet på varje Operations Manager-databas för att aktivera STRIKT SÄKERHET i CLR.

Multisubnet-sträng

Operations Manager stöder inte anslutningssträng nyckelord (MultiSubnetFailover=True). Eftersom en tillgänglighetsgrupp har ett lyssnarnamn (kallas nätverksnamn eller klientåtkomstpunkt i WSFC-klusterhanteraren) beroende på flera IP-adresser från olika undernät, till exempel när du distribuerar i en konfiguration för redundans mellan platser, når klientanslutningsbegäranden från hanteringsservrar till tillgänglighetsgruppens lyssnare en tidsgräns för anslutningen.

Den rekommenderade metoden för att kringgå den här begränsningen när du har distribuerat servernoder i tillgänglighetsgruppen i en miljö med flera undernät är att göra följande:

1. Ange nätverksnamnet för din tillgänglighetsgruppslyssnare så att endast en enda aktiv IP-adress registreras i DNS.
2. Konfigurera klustret så att det använder ett lågt TTL-värde för den registrerade DNS-posten.

De här inställningarna tillåter, vid redundansväxling till en nod i ett annat undernät, snabbare återställning och lösning av klusternamnet med den nya IP-adressen.

Kör följande PowerShell-kommandon på någon av SQL-noderna för att ändra dess inställningar:

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"

Om du använder AlwaysOn med ett lyssnarnamn bör du även göra dessa konfigurationsändringar på lyssnaren. Mer information om hur du konfigurerar en tillgänglighetsgruppslyssnare finns i dokumentationen här: Konfigurera tillgänglighetsgrupplyssnare – SQL Server Alltid på

Kör följande PowerShell-kommandon på den SQL-nod som för närvarande är värd för lyssnaren för att ändra dess inställningar:

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>

När en klustrad eller en AlwaysOn SQL-instans används för hög tillgänglighet bör du aktivera funktionen för automatisk återställning på hanteringsservrarna för att undvika att Operations Manager-tjänsten för dataåtkomst startas om när en redundansväxling mellan noder sker. Information om hur du konfigurerar detta finns i följande KB-artikel System Center Management Service slutar svara när en instans av SQL Server kopplas från.

Optimera SQL Server

I allmänhet visar tidigare distributionsupplevelse med kunder att prestandaproblem vanligtvis inte orsakas av hög resursanvändning (dvs. processor eller minne) med SQL Server sig själv, snarare är det direkt relaterat till konfigurationen av underlagringssystemet. Prestandaflaskhalsar beror vanligtvis på att inte följa rekommenderade konfigurationsvägledning med lagringen som etablerats för SQL Server-databasinstansen. Sådana exempel är:

• Otillräcklig allokering av axlar för de logiska enhetsnummer som ger stöd för I/O-kraven på Operations Manager.
• Värdhantering av transaktionsloggar och databasfiler på samma volym. Dessa två arbetsbelastningar har olika egenskaper för I/O och svarstid.
• Konfigurationen av TempDB är felaktig när det gäller placering, storlek och så vidare.
• Diskpartitionens feljustering av volymer som är värdar för databastransaktionsloggarna, databasfilerna och TempDB.
• Med utsikt över den grundläggande SQL Server konfiguration som att använda AUTOGROW för databas- och transaktionsloggfiler, MAXDOP-inställning för frågeparallellitet, skapa flera TempDB-datafiler per PROCESSORkärna och så vidare.

Lagringskonfigurationen är en av de viktigaste komponenterna vid en SQL Server-distribution för Operations Manager. Databasservrar brukar vara mycket I/O-bundna på grund av rigorösa läsning- och skrivningsaktiviteter och bearbetning av transaktionsloggar i databasen. I/O-beteendemönstret för Operations Manager är vanligtvis 80 % skrivningar och 20 % läsningar. Därför kan felaktig konfiguration av I/O-undersystem leda till sämre prestanda och drift av SQL Server system och blir märkbar i Operations Manager.

Det är viktigt att testa SQL Server design genom att utföra dataflödestestning av I/O-undersystemet innan du distribuerar SQL Server. Se till att dessa tester kan uppfylla dina I/O-krav med en acceptabel svarstid. Använd Diskspd-verktyget för att utvärdera I/O-kapaciteten för det lagringsundersystem som stöder SQL Server. Följande bloggartikel, som skapats av en medlem i filserverteamet i produktgruppen, innehåller detaljerad vägledning och rekommendationer om hur du utför stresstestning med hjälp av det här verktyget med viss PowerShell-kod och samlar in resultaten med hjälp av PerfMon. Du kan också läsa mer i storlekshjälpen för Operations Manager för inledande vägledning.

Storlek på NTFS-allokeringsenhet

Justering av volymen, något som brukar kallas för sektorjustering, ska utföras i filsystemet (NTFS) när en volym skapas på en RAID-enhet. Om du inte gör det kan det leda till betydande prestandaförsämring och är oftast resultatet av partitionsjustering med randenhetsgränser. Det kan också leda till felaktig justering av maskinvarucachen, vilket resulterar i ineffektiv användning av matriscachen. När du formaterar partitionen som ska användas för SQL Server datafiler rekommenderar vi att du använder en storlek på 64 KB allokeringsenhet (dvs. 65 536 byte) för data, loggar och tempdb. Tänk dock på att användning av allokeringsenhetsstorlekar som är större än 4 KB resulterar i att det inte går att använda NTFS-komprimering på volymen. Även om SQL Server stöder skrivskyddade data på komprimerade volymer, rekommenderas det inte.

Reservera minne

Anteckning

Mycket av informationen i det här avsnittet kommer från Jonathan Kehayias i sitt blogginlägg Hur mycket minne behöver min SQL Server faktiskt? (sqlskills.com).

Det är inte alltid lätt att identifiera rätt mängd fysiskt minne och processorer som ska allokeras för SQL Server till stöd för System Center Operations Manager (eller för andra arbetsbelastningar utanför den här produkten). Storlekskalkylatorn som tillhandahålls av produktgruppen ger vägledning baserat på arbetsbelastningsskala, men dess rekommendationer baseras på testning som utförs i en labbmiljö som kanske eller kanske inte överensstämmer med din faktiska arbetsbelastning och konfiguration.

SQL Server kan du konfigurera den minsta och högsta mängden minne som ska reserveras och användas av processen. SQL Server kan som standard ändra sina minneskrav dynamiskt baserat på tillgängliga systemresurser. Standardinställningen för minsta serverminne är 0 och standardinställningen för maximalt serverminne är 2 147 483 647 MB.

Prestanda- och minnesrelaterade problem kan uppstå om du inte anger ett lämpligt värde för maximalt serverminne. Många faktorer påverkar hur mycket minne du behöver allokera till SQL Server för att säkerställa att operativsystemet kan stödja andra processer som körs på systemet, till exempel HBA-kortet, hanteringsagenter och antivirusgenomsökning i realtid. Om tillräckligt med minne inte har angetts går operativsystemet och SQL till disken. Detta kan leda till att diskens I/O ökar, vilket ytterligare minskar prestanda och skapar en krusningseffekt där det blir märkbart i Operations Manager.

Vi rekommenderar att du anger minst 4 GB RAM-minne för minsta serverminne. Detta bör göras för varje SQL-nod som är värd för en av Operations Manager-databaserna (drift, informationslager, ACS).

För maximalt serverminne rekommenderar vi att du först reserverar totalt:

• 1 GB RAM-minne för operativsystemet
• 1 GB RAM-minne per 4 GB INSTALLERAT RAM-minne (upp till 16 GB RAM-minne)
• 1 GB RAM-minne per 8 GB INSTALLERAT RAM-minne (över 16 GB RAM-minne)

När du har angett dessa värden övervakar du räknaren Minne\Tillgängligt MB i Windows för att avgöra om du kan öka det tillgängliga minnet för SQL Server. Windows signalerar att det tillgängliga fysiska minnet börjar ta slut på 96 MB, så helst bör räknaren inte köras lägre än cirka 200–300 MB för att säkerställa att du har en buffert. För servrar med 256 GB RAM-minne eller högre vill du förmodligen se till att det inte körs lägre än 1 GB.

Tänk på att dessa beräkningar förutsätter att du vill att SQL Server ska kunna använda allt tillgängligt minne, såvida du inte ändrar dem för att ta hänsyn till andra program. Överväg de specifika minneskraven för ditt operativsystem, andra program, SQL Server trådstacken och andra multipage-allokerare. En typisk formel är ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), där minnet för trådstacken = ((max worker threads) (stack size)). Stackstorleken är 512 kB för x86-system, 2 MB för x64-system och 4 MB för IA64-system, och du hittar värdet för maximalt antal arbetstrådar i kolumnen max_worker_count i sys.dm_os_sys_info.

Dessa överväganden gäller även minneskraven för SQL Server som ska köras på en virtuell dator. Eftersom SQL Server är utformat för att cachelagrat data i buffertpoolen och vanligtvis använder så mycket minne som möjligt kan det vara svårt att fastställa den ideala mängden RAM-minne som behövs. När du minskar det allokerade minnet till en SQL Server instans når du så småningom en punkt där kolonilotter med lägre minne byts mot högre disk-I/O-åtkomst.

Om du vill konfigurera SQL Server minne i en miljö som har överetablerats börjar du med att övervaka miljön och de aktuella prestandamåtten, inklusive SQL Server Buffer Manager-sidans förväntade livslängd och sidläsningar/sek och värdena för fysiska diskars läsningar/sek. Om miljön har överflödigt minne ökar den förväntade sidlivslängden med ett värde på en sekund varje sekund utan någon minskning under arbetsbelastningen, på grund av cachelagring. SQL Server bufferthanterarens sidläsningar/sek-värde kommer att vara lågt när cacheminnet har ökat och fysiska diskläsningar/s förblir också låga.

När du förstår baslinjen för miljön kan du minska det maximala serverminnet med 1 GB och sedan se hur det påverkar prestandaräknarna (när eventuell inledande cachetömning avtar). Om måtten förblir acceptabla minskar du med ytterligare 1 GB och övervakar sedan igen och upprepar som du vill tills du fastställer en perfekt konfiguration.

Mer information finns i Konfigurationsalternativ för serverminne.

Optimera TempDB

Storleken och den fysiska placeringen av tempdb-databasen kan påverka prestanda för Operations Manager. Om exempelvis den storlek som har definierats för tempdb är för liten, kan en del av systembehandlingens belastning tas upp med en automatiskt växande tempdb till den storlek som krävs för att stödja arbetsbelastningen varje gång du startar om SQL Server-instansen. Vi rekommenderar följande konfiguration för tempdb i en produktionsmiljö för att uppnå bästa tempdb-prestanda:

• Ange återställningsmodellen för tempdb till ENKEL. Den här modellen återtar automatiskt loggutrymmet för att hålla utrymmeskraven små.
• Förallokera utrymme för alla tempdb-filer genom att ange filstorleken till ett värde som är tillräckligt stort för att hantera den typiska arbetsbelastningen i miljön. Det förhindrar att tempdb expanderas för ofta, vilket kan påverka prestandan. Tempdb-databasen kan ställas in så att den växer automatiskt, men det här alternativet bör användas för att öka diskutrymmet vid oplanerade undantag.
• Skapa så många filer som behövs för att maximera diskbandbredden. Om du använder flera filer minskar konkurrensen i tempdb-lagringen och ger bättre skalbarhet. Men skapa inte för många filer eftersom det kan minska prestanda och öka hanteringskostnaderna. Som en generell riktlinje bör du skapa en fil för varje logisk processor på servern (och väga in eventuella inställningar för tillhörighetsmasker) och sedan justera antalet filer uppåt eller nedåt efter behov. Som en allmän regel ska du använda samma antal datafiler som logiska processorer om antalet logiska processorer är mindre än eller lika med åtta. Om antalet logiska processorer är större än 8 använder du åtta datafiler och om konkurrensen fortsätter ökar du antalet datafiler med multiplar av 4 (upp till antalet logiska processorer) tills konkurrensen minskas till godkända nivåer eller gör ändringar i arbetsbelastningen/koden. Om konkurrensen inte minskar kan du behöva öka antalet datafiler mer.
• Gör varje datafil till samma storlek, vilket ger optimala prestanda för proportionell fyllning. Lika storlek på datafilerna är viktigt eftersom algoritmen för proportionell fyllning är baserad på storleken på filerna. Om datafilerna skapas med olika storlekar försöker algoritmen för proportionell fyllning använda den största filen mer för GAM-allokeringar i stället för att sprida allokeringarna mellan alla filer, vilket omintetgör syftet med att skapa flera datafiler.
• Placera tempdb-databasen i ett snabbt I/O-undersystem med SSD-enheter för bästa möjliga prestanda. Använd diskstripning om det finns många direktanslutna diskar.
• Placera tempdb-databasen på andra diskar än de som används av databaserna.

Om du vill konfigurera tempdb-databasen du kör följande fråga eller ändrar databasens egenskaper i 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

Kör T-SQL-frågan SELECT * from sys.sysprocesses för att identifiera sidallokeringskonkurens för tempdb-databasen. I systemtabellens utdata kan vänteresursen visas som "2:1:1" (PFS-sida) eller "2:1:3" (sida för delad global allokeringskarta). Beroende på graden av konkurrens kan detta även leda till att SQL Server inte verkar svara under korta stunder. En annan metod är att undersöka de dynamiska hanteringsvyerna [sys.dm_exec_request eller sys.dm_os_waiting_tasks]. Resultatet visar att dessa begäranden eller aktiviteter väntar på tempdb-resurser och har liknande värden som markerats tidigare när du kör frågan sys.sysprocesses .

Om de tidigare rekommendationerna inte avsevärt minskar allokeringskonkurvansen och konkurrensen finns på SGAM-sidor implementerar du spårningsflaggan -T1118 i startparametrarna för SQL Server så att spårningsflaggan fortsätter att gälla även efter att SQL Server har återvinns. Under den här spårningsflaggan allokerar SQL Server fullständiga omfång för varje databasobjekt, vilket eliminerar konkurrensen på SGAM-sidorna.

Anteckning

Den här spårningsflaggan påverkar alla databaser på instansen av SQL Server.

Maxgrad av parallellitet

Standardkonfigurationen av SQL Server för små till medelstora distributioner av Operations Manager är tillräcklig för de flesta behov. Men när hanteringsgruppens arbetsbelastning skalar uppåt mot ett scenario i företagsklass (vanligtvis över 2 000 agenthanterade system och en avancerad övervakningskonfiguration, som omfattar övervakning på tjänstnivå med avancerade syntetiska transaktioner, övervakning av nätverksenheter, plattformsoberoende och så vidare) är det dock nödvändigt att optimera konfigurationen av SQL Server som beskrivs i det här avsnittet av dokumentet. Ett konfigurationsalternativ som inte har diskuterats i tidigare vägledning är MAXDOP.

I Microsoft SQL Server används konfigurationsalternativet för högsta graden av parallellitet (MAXDOP) för att styra antalet processorer som används för körning av en fråga i ett parallellt plan. Det här alternativet anger de beräknings- och trådresurser som används för de frågeplansoperatörer som utför arbetet parallellt. Beroende på om SQL Server har konfigurerats på en SMP-dator (symmetrisk multiprocessing), en NUMA-dator (icke-enhetlig minnesåtkomst) eller hypertrådningsaktiverade processorer måste du konfigurera alternativet för maximal grad av parallellitet på lämpligt sätt.

När SQL Server körs på en dator med fler än en mikroprocessor eller processor, identifierar den bästa grad av parallellitet, det vill säga det antal processorer som används för att köra en enskild instruktion för varje parallellplanskörning. Som standard är värdet för det här alternativet 0, vilket gör att SQL Server kan fastställa högsta grad av parallellitet.

Lagrade procedurer och frågor som är fördefinierade i Operations Manager när det gäller driften, informationslagret och till och med granskningsdatabasen innehåller inte alternativet MAXDOP, eftersom det inte finns något sätt under installationen att dynamiskt fråga hur många processorer som presenteras för operativsystemet och inte heller försöker hårdkoda värdet för den här inställningen, vilket kan få negativa konsekvenser när frågan körs.

Anteckning

Konfigurationsalternativet för maximal grad av parallellitet begränsar inte antalet processorer som SQL Server använder. Om du vill konfigurera det antal processorer som används av SQL Server använder du konfigurationsalternativet tillhörighetsmask.

• För servrar som använder fler än åtta processorer använder du följande konfiguration: MAXDOP = 8
• För servrar som använder åtta eller färre processorer använder du följande konfiguration: MAXDOP=0 till N

  Anteckning

  I den här konfigurationen representerar N antalet processorer.