Überlegungen zum SQL Server-Entwurf

System Center Operations Manager erfordert Zugriff auf eine Instanz eines Servers, auf dem Microsoft SQL Server ausgeführt wird, um die Betriebs-, Data Warehouse- und ACS-Überwachungsdatenbank zu unterstützen. Die Betriebs- und Data Warehouse-Datenbanken sind erforderlich und werden erstellt, wenn Sie den ersten Verwaltungsserver in Ihrer Verwaltungsgruppe bereitstellen, während die ACS-Datenbank erstellt wird, wenn Sie einen ACS-Sammler in Ihrer Verwaltungsgruppe bereitstellen.

In einer Lab-Umgebung oder einer kleinen Bereitstellung von Operations Manager kann SQL Server auf dem ersten Verwaltungsserver in der Verwaltungsgruppe koexistieren.

In einer mittelgroßen und unternehmensweiten verteilten Bereitstellung sollte sich die SQL Server-Instanz auf einem dedizierten eigenständigen Server oder in einer SQL Server-Hochverfügbarkeitskonfiguration befinden. In beiden Fällen muss SQL Server bereits vorhanden sein und ist zugänglich, bevor Sie die Installation des ersten Verwaltungsservers oder ACS-Sammlers starten.

Die Verwendung von Operations Manager-Datenbanken aus einer SQL-Instanz mit anderen Anwendungsdatenbanken wird nicht empfohlen. Dies ist die Vermeidung potenzieller Probleme mit E/A und anderen Hardwareressourceneinschränkungen.

Wichtig

Operations Manager unterstützt keine Platform as a Service (PaaS)-Instanzen von SQL, einschließlich Produkten wie Azure SQL verwaltete Instanz oder Amazon Relational Database Service (AWS RDS). Verwenden Sie eine Instanz von SQL Server, die auf einem Windows-Computer installiert ist. Die einzige Ausnahme ist in Azure Monitor SCOM verwaltete Instanz, das Azure SQL MI verwendet und nicht neu konfiguriert werden kann.

SQL Server-Anforderungen

Die folgenden Versionen von SQL Server Enterprise & Standard Edition werden für eine vorhandene Installation der System Center Operations Manager-Version unterstützt, um Reporting Server, Operational, Data Warehouse und ACS-Datenbank zu hosten:

• SQL Server 2022

• SQL Server 2019 mit kumulativem Update 8 (CU8) oder höher, wie hier beschrieben

  Hinweis

  • Operations Manager 2022 unterstützt SQL 2019 mit CU8 oder höher; Sql 2019 RTM wird jedoch nicht unterstützt.
  • Verwenden Sie ODBC 17.3 oder 17.10.6 und MSOLEDBSQL 18.2 oder 18.7.2.

• SQL Server 2017 und kumulative Updates wie hier beschrieben

Informationen zum Upgrade von SQL Server finden Sie unter Upgradeinformationen für 2017 und Upgradeinformationen für SQL 2019.

Hinweis

• Jede der folgenden SQL Server-Komponenten, die eine SCOM-Infrastruktur unterstützen, muss sich in derselben SQL Server-Hauptversion befinden:
  • SQL Server-Datenbankmodulinstanzen, die eine der SCOM-Datenbanken hosten (d. r . OperationManager, OperationManagerDW und SSRS-Datenbanken ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services-Instanz (SSRS)
• Die SQL Server-Sortierungseinstellung muss einen der unterstützten Typen aufweisen, wie im Abschnitt Einstellung für die SQL Server-Sortierung unten beschrieben.
• Die SQL Server-Volltextsuche ist für alle Instanzen der SQL Server-Datenbank-Engine erforderlich, die eine der SCOM-Datenbanken hosten.
• Die Installationsoptionen von Windows Server 2016 (Server Core, Server mit Desktopdarstellung und Nano Server), die von Operations Manager-Datenbankkomponenten unterstützt werden, basieren darauf, welche Installationsoptionen von Windows Server von SQL Server unterstützt werden.

Hinweis

System Center Operations Manager Reporting kann nicht parallel mit einer früheren Version der Berichtsrolle installiert werden und muss nur im nativen Modus installiert werden (der integrierte SharePoint-Modus wird nicht unterstützt).

Zusätzliche Hardware- und Softwareüberlegungen gelten für ihre Entwurfsplanung:

• Es wird empfohlen, SQL Server auf Computern mit dem NTFS-Dateiformat auszuführen.
• Für die Betriebs- und Data Warehouse-Datenbank muss mindestens 1024 MB freier Speicherplatz vorhanden sein. Sie wird zum Zeitpunkt der Datenbankerstellung erzwungen, und sie wird nach dem Setup wahrscheinlich erheblich wachsen.
• .NET Framework 4 ist erforderlich.
• .NET Framework 4.8 wird ab Operations Manager 2022 unterstützt.
• Reporting Server wird unter Windows Server Core nicht unterstützt.

Weitere Informationen finden Sie unter Hardware- und Softwareanforderungen für die Installation von SQL Server.

Hinweis

Obwohl Operations Manager während der Installation nur Windows-Authentifizierung verwendet, funktioniert die Sql Mixed Mode Authentication-Einstellung weiterhin, wenn kein lokales Konto über die rolle db_owner verfügt. Lokale Konten mit der Rolle db_owner sind bekannt, um Probleme mit System Center Operations Manager zu verursachen. Entfernen Sie die rolle db_owner aus allen lokalen Konten, bevor Sie das Produkt installieren, und fügen Sie die db_owner Rolle nach der Installation nicht zu einem der lokalen Konten hinzu.

SQL Server-Sortiereinstellung

Die folgenden SQL Server- und Windows-Sortierungen werden von System Center Operations Manager unterstützt.

Hinweis

Um Kompatibilitätsprobleme beim Vergleichen oder Kopieren von Vorgängen zu vermeiden, empfiehlt es sich, dieselbe Sortierung für die SQL- und Operations Manager DB zu verwenden.

SQL Server-Sortierung

• SQL_Latin1_General_CP1_CI_AS

Windows-Sortierung

• 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

Wenn Ihre SQL Server-Instanz nicht mit einer der zuvor aufgeführten unterstützten Sortierungen konfiguriert ist, schlägt das Ausführen eines neuen Setups des Operations Manager-Setups fehl. Ein direktes Upgrade wird jedoch erfolgreich abgeschlossen.

Firewallkonfiguration

Operations Manager hängt von SQL Server ab, um seine Datenbanken und eine Berichtsplattform zu hosten, um historische Betriebsdaten zu analysieren und darzustellen. Die Verwaltungsserver-, Operations- und Webkonsolenrollen müssen in der Lage sein, erfolgreich mit SQL Server zu kommunizieren, und es ist wichtig, den Kommunikationspfad und die Ports zu verstehen, um Ihre Umgebung ordnungsgemäß zu konfigurieren.

Wenn Sie eine verteilte Bereitstellung entwerfen, die SQL AlwaysOn-Verfügbarkeitsgruppen erfordert, um Failoverfunktionen für die Operations Manager-Datenbanken bereitzustellen, gibt es zusätzliche Firewallkonfigurationseinstellungen, die in Ihre Firewallsicherheitsstrategie einbezogen werden müssen.

In der folgenden Tabelle können Sie die firewallports identifizieren, die von SQL Server benötigt werden, die mindestens zulässig sein müssen, damit Serverrollen in Ihrer Operations Manager-Verwaltungsgruppe erfolgreich kommunizieren können.

Szenario	Port	Direction	Operations Manager-Rolle
SQL Server hosting Operations Manager-Datenbanken	TCP 1433 *	Eingehend	Verwaltungsserver und Webkonsole (für Anwendungsratgeber und Anwendungsdiagnose)
SQL Server-Browserdienst	UDP 1434	Eingehend	Verwaltungsserver
Dedizierte SQL Server-Administratorverbindung	TCP 1434	Eingehend	Verwaltungsserver
Zusätzliche Ports, die von SQL Server verwendet werden – Microsoft-Remoteprozeduraufrufe (MS RPC) - Windows-Verwaltungsinstrumentation (WMI) - Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Eingehend	Verwaltungsserver
SQL Server Always On Availability Group Listener	Vom Administrator konfigurierter Port	Eingehend	Verwaltungsserver
SQL Server Reporting Services hosting Operations Manager Reporting Server	TCP 80 (Standard)/443 (SSL)	Eingehend	Verwaltungsserver und Operations-Konsole

* TCP 1433 ist der Standardport für die Standardinstanz der Datenbank-Engine. Wenn Sie jedoch eine benannte Instanz auf einer eigenständigen SQL Server-Instanz erstellen oder eine SQL Always On-Verfügbarkeitsgruppe bereitgestellt haben, wird ein benutzerdefinierter Port festgelegt. Dieser sollte zur Referenz dokumentiert sein, sodass Sie Ihre Firewalls ordnungsgemäß konfigurieren und diese Informationen während des Setups eingeben können.

Eine ausführlichere Übersicht über die Firewallanforderungen für SQL Server finden Sie unter Konfigurieren der Windows-Firewall zum Zulassen des SQL Server-Zugriffs.

Überlegungen zu Kapazität und Speicher

Operations Manager-Datenbank

Die Operations Manager-Datenbank ist eine SQL Server-Datenbank, die alle Daten enthält, die von Operations Manager für die tägliche Überwachung benötigt werden. Die Größenanpassung und Konfiguration des Datenbankservers ist für die Gesamtleistung der Verwaltungsgruppe von entscheidender Bedeutung. Die kritischste Ressource, die von der Operations Manager-Datenbank verwendet wird, ist das Speichersubsystem, aber CPU und RAM sind ebenfalls wichtig.

Faktoren, die die Auslastung der Operations Manager-Datenbank beeinflussen, umfassen:

• Rate der Betrieblichen Datensammlung. Betriebsdaten bestehen aus allen Ereignissen, Warnungen, Zustandsänderungen und Leistungsdaten, die von Agents gesammelt werden. Die meisten Ressourcen, die von der Operations Manager-Datenbank verwendet werden, werden verwendet, um diese Daten auf den Datenträger zu schreiben, sobald sie in das System gelangen. Die Rate der gesammelten Betriebsdaten steigt tendenziell, da zusätzliche Management Packs importiert und zusätzliche Agents hinzugefügt werden. Der Computertyp, den ein Agent überwacht, ist auch ein wichtiger Faktor, der bei der Ermittlung der Gesamtrate der Betriebsdatensammlung verwendet wird. Ein Agent, der einen unternehmenskritischen Desktopcomputer überwacht, kann beispielsweise erwarten, dass weniger Daten gesammelt werden als ein Agent, der einen Server überwacht, auf dem eine Instanz von SQL Server mit einer großen Anzahl von Datenbanken ausgeführt wird.
• Rate der Änderung des Instanzenraums. Das Aktualisieren dieser Daten in der Operations Manager-Datenbank ist im Verhältnis zum Schreiben neuer Betriebsdaten kostspielig. Darüber hinaus nehmen die Verwaltungsserver zusätzliche Abfragen an der Operations Manager-Datenbank vor, wenn sich Raumdaten ändern, um Konfigurations- und Gruppenänderungen zu berechnen. Die Anzahl der Änderungen am Instanzenspeicher nimmt zu, wenn Sie zusätzliche Management Packs in eine Verwaltungsgruppe importieren. Durch das Hinzufügen neuer Agents zu einer Verwaltungsgruppe wird auch vorübergehend die Rate von Änderungen am Instanzenbereich erhöht.
• Anzahl der Operations Consoles und anderer SDK-Verbindungen, die gleichzeitig ausgeführt werden. Jede Operations-Konsole liest Daten aus der Operations Manager-Datenbank. Die Abfrage dieser Daten verbraucht potenziell große Mengen an Speicher-E/A-Ressourcen, CPU-Zeit und RAM. Operationskonsolen, die große Mengen von Betriebsdaten in der Ereignisansicht, der Statusansicht, der Warnungsansicht und der Leistungsdatenansicht anzeigen, führen dazu, dass die Datenbank am meisten geladen wird.

Die Operations Manager-Datenbank ist eine einzige Fehlerquelle für die Verwaltungsgruppe, sodass sie mithilfe unterstützter Failoverkonfigurationen wie SQL Server AlwaysOn-Verfügbarkeitsgruppen oder Failoverclusterinstanzen hoch verfügbar gemacht werden kann.

Sie können Operations Manager-Datenbanken mit einem vorhandenen SQL Always-On-Setup einrichten und aktualisieren, ohne Änderungen nach der Konfiguration vornehmen zu müssen.

Aktivieren des SQL-Brokers in der Operations Manager-Datenbank

System Center Operations Manager hängt vom SQL Server Service Broker ab, um alle Aufgabenvorgänge zu implementieren. Wenn der SQL Server-Dienstbroker deaktiviert ist, sind alle Vorgangsvorgänge betroffen. Das resultierende Verhalten kann je nach initiierter Aufgabe variieren. Daher ist es wichtig, den Status von SQL Server Service Broker zu überprüfen, wenn unerwartetes Verhalten bei einer Aufgabe in System Center Operations Manager beobachtet wird.

Führen Sie die folgenden Schritte aus, um sql Server Service Broker zu aktivieren:

1. Führen Sie die folgende SQL-Abfrage aus:

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

2. Überspringen Sie diesen Schritt, wenn der wert, der is_broker_enabled im Feld angezeigt wird, 1 (eins) ist. Führen Sie andernfalls die folgenden SQL-Abfragen aus:

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

Operations Manager Data Warehouse-Datenbank

System Center – Operations Manager fügt Daten in das Reporting Data Warehouse in nahezu Echtzeit ein, es ist wichtig, über ausreichende Kapazität auf diesem Server zu verfügen, die das Schreiben aller Daten unterstützt, die in das Reporting Data Warehouse gesammelt werden. Wie bei der Operations Manager-Datenbank ist die wichtigste Ressource im Reporting Data Warehouse das Speicher-E/A-Subsystem. Bei den meisten Systemen sind Lasten im Reporting Data Warehouse mit der Operations Manager-Datenbank vergleichbar, können jedoch variieren. Darüber hinaus unterscheidet sich die arbeitslast, die das Reporting Data Warehouse durch Berichterstellung ausführt, von der Auslastung der Operations Manager-Datenbank durch die Verwendung der Operations-Konsole.

Zu den Faktoren, die die Belastung des Berichtsdatenlagers beeinflussen, gehören:

• Rate der Betrieblichen Datensammlung. Um eine effizientere Berichterstellung zu ermöglichen, berechnet und speichert das Reporting Data Warehouse aggregierte Daten zusätzlich zu einer begrenzten Menge an Rohdaten. Diese zusätzliche Arbeit bedeutet, dass die Operative Datensammlung im Reporting Data Warehouse etwas teurer sein kann als die Operations Manager-Datenbank. Diese zusätzlichen Kosten werden in der Regel durch die reduzierten Kosten für die Verarbeitung von Ermittlungsdaten durch das Berichtsdatenlager im Vergleich zur Operations Manager-Datenbank ausgeglichen.
• Anzahl der gleichzeitigen Berichterstellungsbenutzer oder der geplanten Berichtsgenerierung. Da Berichte häufig große Datenmengen zusammenfassen, kann jeder Berichtsbenutzer eine erhebliche Belastung für das System hinzufügen. Die Anzahl der gleichzeitig ausgeführten Berichte und der Typ der ausgeführten Berichte wirken sich auf die Gesamtkapazitätsanforderungen aus. Im Allgemeinen erfordern Berichte, die große Datumsbereiche oder große Anzahl von Objekten abfragen, zusätzliche Systemressourcen.

Basierend auf diesen Faktoren gibt es mehrere empfohlene Methoden für die Größenanpassung des Berichtsdatenlagers:

• Wählen Sie ein geeignetes Speichersubsystem aus. Da das Reporting Data Warehouse ein integraler Bestandteil des gesamten Datenflusses über die Verwaltungsgruppe ist, ist die Auswahl eines geeigneten Speichersubsystems für das Reporting Data Warehouse wichtig. Wie bei der Operations Manager-Datenbank ist RAID 0 + 1 oft die beste Wahl. Im Allgemeinen sollte das Speichersubsystem für das Reporting Data Warehouse dem Speichersubsystem für die Operations Manager-Datenbank ähneln, und die Anleitungen, die für die Operations Manager-Datenbank gelten, gelten auch für das Reporting Data Warehouse.
• Berücksichtigen Sie die geeignete Platzierung von Datenprotokollen im Vergleich zu Transaktionsprotokollen. Wie bei der Operations Manager-Datenbank ist das Trennen von SQL-Daten und Transaktionsprotokollen häufig eine geeignete Wahl, wenn Sie die Anzahl der Agents skalieren. Wenn sich sowohl die Operations Manager-Datenbank als auch das Reporting Data Warehouse auf demselben Server befinden und Sie Daten- und Transaktionsprotokolle trennen möchten, müssen Sie die Transaktionsprotokolle für die Operations Manager-Datenbank auf einem separaten physischen Volume und Datenträgerspindeln aus dem Berichtsdatenlager ablegen, um alle Vorteile zu erhalten. Die Datendateien für die Operations Manager-Datenbank und das Reporting-Data Warehouse können dasselbe physische Volume gemeinsam nutzen, solange das Volume ausreichende Kapazität bietet und die Leistung der Datenträger-E/A nicht negativ auf die Überwachungs- und Berichterstellungsfunktion wirkt.
• Erwägen Sie, das Reporting Data Warehouse auf einem separaten Server von der Operations Manager-Datenbank zu platzieren. Obwohl kleinere Bereitstellungen häufig die Operations Manager-Datenbank und das Reporting Data Warehouse auf demselben Server konsolidieren können, ist es vorteilhaft, sie zu trennen, während Sie die Anzahl der Agents und das Volumen eingehender Betriebsdaten skalieren. Wenn sich das Reporting Data Warehouse und Reporting Server auf einem separaten Server von der Operations Manager-Datenbank befinden, können Sie eine bessere Berichterstellungsleistung erzielen.

Die Operations Manager-Data Warehouse-Datenbank ist eine einzige Fehlerquelle für die Verwaltungsgruppe, sodass sie mithilfe unterstützter Failoverkonfigurationen wie SQL Server AlwaysOn-Verfügbarkeitsgruppen oder Failoverclusterinstanzen hoch verfügbar gemacht werden kann.

SQL Server Always On

SQL Server AlwaysOn-Verfügbarkeitsgruppen unterstützen Failoverumgebungen für einen separaten Satz von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jeder Satz von Verfügbarkeitsdatenbanken wird von einem Verfügbarkeitsreplikat gehostet.

Mit System Center 2016 und höher – Operations Manager wird SQL Always On gegenüber Failoverclustering bevorzugt, um eine hohe Verfügbarkeit für Datenbanken bereitzustellen. Alle Datenbanken mit Ausnahme der Systemeigenen Reporting Services-Installation, die zwei Datenbanken verwendet, um beständigen Datenspeicher von temporären Speicheranforderungen zu trennen, können in einer AlwaysOn-Verfügbarkeitsgruppe gehostet werden.

Bei Operations Manager 2022 können Sie Operations Manager-Datenbanken mit einem vorhandenen SQL Always-On-Setup einrichten und aktualisieren, ohne Änderungen nach der Konfiguration vornehmen zu müssen.

Um eine Verfügbarkeitsgruppe einzurichten, müssen Sie einen Windows Server Failover Clustering (WSFC)-Cluster bereitstellen, um das Verfügbarkeitsreplikat zu hosten und AlwaysOn auf den Clusterknoten zu aktivieren. Anschließend können Sie die Operations Manager SQL Server-Datenbank als Verfügbarkeitsdatenbank hinzufügen.

• Erfahren Sie mehr über die Voraussetzungen für Always On.
• Erfahren Sie mehr über das Einrichten einer WSFC für AlwaysOn-Verfügbarkeitsgruppen.
• Erfahren Sie mehr über das Einrichten einer Verfügbarkeitsgruppe.

Hinweis

Führen Sie nach der Bereitstellung von Operations Manager auf den SQL Server-Knoten, die an SQL Always On teilnehmen, das SQL-Skript für jede Operations Manager-Datenbank aus, um clR strict security zu aktivieren.

Multisubnet-Zeichenfolge

Operations Manager unterstützt die Verbindungszeichenfolge Schlüsselwörter (MultiSubnetFailover=True) nicht. Da eine Verfügbarkeitsgruppe einen Listenernamen (bekannt als Netzwerkname oder Clientzugriffspunkt im WSFC-Cluster-Manager) hat, hängt es von mehreren IP-Adressen aus verschiedenen Subnetzen ab, z. B. wenn Sie eine standortübergreifende Failoverkonfiguration bereitstellen, werden Clientverbindungsanforderungen von Verwaltungsservern bis zum Verfügbarkeitsgruppenlistener auf ein Verbindungstimeout getroffen.

Der empfohlene Ansatz, um diese Einschränkung zu umgehen, wenn Sie Serverknoten in der Verfügbarkeitsgruppe in einer Multi-Subnetzumgebung bereitgestellt haben, besteht darin, Folgendes zu tun:

1. Legen Sie den Netzwerknamen Ihres Verfügbarkeitsgruppenlisteners fest, um nur eine einzelne aktive IP-Adresse in DNS zu registrieren.
2. Konfigurieren Sie den Cluster so, dass ein niedriger TTL-Wert für den registrierten DNS-Eintrag verwendet wird.

Diese Einstellungen ermöglichen beim Failover auf einen Knoten in einem anderen Subnetz eine schnellere Wiederherstellung und Auflösung des Clusternamens mit der neuen IP-Adresse.

Führen Sie die folgenden PowerShell-Befehle auf einem der SQL-Knoten aus, um ihre Einstellungen zu ändern:

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"

Wenn Sie Always On mit einem Listenernamen verwenden, sollten Sie diese Konfigurationsänderungen auch für den Listener vornehmen. Weitere Informationen zum Konfigurieren eines Verfügbarkeitsgruppenlisteners finden Sie in der Dokumentation hier: Konfigurieren des Verfügbarkeitsgruppenlisteners – SQL Server AlwaysOn

Führen Sie die folgenden PowerShell-Befehle auf dem SQL-Knoten aus, der derzeit den Listener hostet, um seine Einstellungen zu ändern:

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>

Wenn eine Cluster- oder Always On SQL-Instanz für hohe Verfügbarkeit verwendet wird, sollten Sie das Feature für die automatische Wiederherstellung auf Ihren Verwaltungsservern aktivieren, um zu vermeiden, dass der Operations Manager Data Access-Dienst bei jedem Failover zwischen Knoten neu gestartet wird. Informationen zur Konfiguration finden Sie im folgenden KB-Artikel : Der System Center Management-Dienst reagiert nicht mehr, nachdem eine Instanz von SQL Server offline ist.

Optimieren von SQL Server

Im Allgemeinen zeigt die vorherige Bereitstellungserfahrung mit Kunden, dass Leistungsprobleme in der Regel nicht durch eine hohe Ressourcenauslastung (d. r. Prozessor oder Arbeitsspeicher) mit SQL Server selbst verursacht werden; vielmehr ist sie direkt mit der Konfiguration des Speichersubsystems verknüpft. Leistungsengpässe werden häufig nicht empfohlenen Konfigurationsanweisungen zugeordnet, wobei der für die SQL Server-Datenbankinstanz bereitgestellte Speicher nicht eingehalten wird. Beispiele hierfür sind:

• Unzureichende Zuordnung von Spindeln für die LUNs zur Unterstützung der E/A-Anforderungen von Operations Manager.
• Hosten von Transaktionsprotokollen und Datenbankdateien auf demselben Volume. Diese beiden Workloads weisen unterschiedliche E/A- und Latenzmerkmale auf.
• Die Konfiguration von TempDB ist in Bezug auf Platzierung, Größe usw. falsch.
• Datenträgerpartitionsfehler bei Volumes, die die Datenbanktransaktionsprotokolle, Datenbankdateien und TempDB hosten.
• Mit Blick auf die grundlegende SQL Server-Konfiguration, z. B. die Verwendung von AUTOGROW für Datenbank- und Transaktionsprotokolldateien, die MAXDOP-Einstellung für die Abfrageparallelität, das Erstellen mehrerer TempDB-Datendateien pro CPU-Kern usw.

Die Speicherkonfiguration ist eine der wichtigen Komponenten einer SQL Server-Bereitstellung für Operations Manager. Datenbankserver sind aufgrund strenger Lese- und Schreibvorgänge und Transaktionsprotokollverarbeitung in der Regel stark an E/A gebunden. Das E/A-Verhaltensmuster von Operations Manager beträgt in der Regel 80 % Schreibvorgänge und 20 % Lesevorgänge. Infolgedessen kann eine unsachgemäße Konfiguration von E/A-Subsystemen zu einer schlechten Leistung und dem Betrieb von SQL Server-Systemen führen und in Operations Manager spürbar werden.

Es ist wichtig, den SQL Server-Entwurf zu testen, indem vor der Bereitstellung von SQL Server Durchsatztests des E/A-Subsystems durchgeführt werden. Stellen Sie sicher, dass diese Tests Ihre E/A-Anforderungen mit einer akzeptablen Latenz erreichen können. Verwenden Sie das Diskspd-Hilfsprogramm , um die E/A-Kapazität des Speichersubsystems zu bewerten, das SQL Server unterstützt. Der folgende Blogartikel, der von einem Mitglied des File Server-Teams in der Produktgruppe verfasst wurde, enthält detaillierte Anleitungen und Empfehlungen zum Ausführen von Stresstests mithilfe dieses Tools mit einigen PowerShell-Code und zum Erfassen der Ergebnisse mithilfe von PerfMon. Eine erste Anleitung finden Sie auch im Tool zur Dimensionierung von Operations Manager.

NTFS-Zuordnungseinheitsgröße

Die Volumeausrichtung, die häufig als Sektorausrichtung bezeichnet wird, sollte auf dem Dateisystem (NTFS) ausgeführt werden, wenn ein Volume auf einem RAID-Gerät erstellt wird. Dies kann zu erheblicher Leistungsbeeinträchtigung führen und ist am häufigsten das Ergebnis einer Partitionsverlagerung mit Streifeneinheitsgrenzen. Es kann auch zu Einer Fehlausrichtung des Hardwarecaches führen, was zu einer ineffizienten Nutzung des Arraycaches führt. Beim Formatieren der Partition, die für SQL Server-Datendateien verwendet wird, empfiehlt es sich, eine Größe der 64-KB-Zuordnungseinheit (d. h. 65.536 Byte) für Daten, Protokolle und tempdb zu verwenden. Beachten Sie jedoch, dass die Verwendung von Zuordnungseinheitsgrößen größer als 4 KB dazu führt, dass die NTFS-Komprimierung auf dem Volume nicht verwendet werden kann. Sql Server unterstützt zwar schreibgeschützte Daten auf komprimierten Volumes, wird jedoch nicht empfohlen.

Speicher reservieren

Hinweis

Viele der Informationen in diesem Abschnitt stammen aus Jonathan Kehayias in seinem Blogbeitrag Wie viel Arbeitsspeicher benötigt mein SQL Server eigentlich? (sqlskills.com).

Es ist nicht immer einfach, die richtige Menge an physischem Arbeitsspeicher und Prozessoren zu identifizieren, um SQL Server zur Unterstützung von System Center Operations Manager (oder für andere Workloads außerhalb dieses Produkts) zuzuweisen. Der von der Produktgruppe bereitgestellte Größenrechner bietet Anleitungen basierend auf der Workloadskala, ihre Empfehlungen basieren jedoch auf Tests, die in einer Laborumgebung durchgeführt wurden, die möglicherweise oder nicht mit Ihrer tatsächlichen Workload und Konfiguration übereinstimmen.

SQL Server ermöglicht Es Ihnen, den minimalen und maximalen Arbeitsspeicher zu konfigurieren, der von seinem Prozess reserviert und verwendet wird. Sql Server kann seine Speicheranforderungen standardmäßig dynamisch basierend auf verfügbaren Systemressourcen ändern. Die Standardeinstellung für min. Serverspeicher ist 0, und die Standardeinstellung für den maximalen Serverspeicher beträgt 2.147.483.647 MB.

Leistungs- und Speicherprobleme können auftreten, wenn Sie keinen geeigneten Wert für den maximalen Serverspeicher festlegen. Viele Faktoren beeinflussen, wie viel Arbeitsspeicher Sie sql Server zuweisen müssen, um sicherzustellen, dass das Betriebssystem andere Prozesse unterstützen kann, die auf diesem System ausgeführt werden, z. B. die HBA-Karte, Verwaltungs-Agents und das Scannen von Viren in Echtzeit. Wenn nicht genügend Arbeitsspeicher festgelegt ist, wird das Betriebssystem und SQL auf den Datenträger blättern. Dies kann dazu führen, dass die Datenträger-E/A-Funktion zunimmt, die Leistung weiter verringert und ein Welleneffekt entsteht, in dem es in Operations Manager spürbar wird.

Es wird empfohlen, mindestens 4 GB RAM für min. Serverspeicher anzugeben. Dies sollte für jeden SQL-Knoten erfolgen, der eine der Operations Manager-Datenbanken hostet (betriebsbereit, Data Warehouse, ACS).

Für den maximalen Serverspeicher empfehlen wir, zunächst eine Gesamtmenge von:

• 1 GB RAM für das Betriebssystem
• 1 GB RAM pro 4 GB RAM installiert (bis zu 16 GB RAM)
• 1 GB RAM pro 8-GB RAM installiert (über 16 GB RAM)

Nachdem Sie diese Werte festgelegt haben, überwachen Sie den Indikator "Memory\Available MBytes " in Windows, um zu ermitteln, ob Sie den für SQL Server verfügbaren Arbeitsspeicher erhöhen können. Windows signalisiert, dass der verfügbare physische Arbeitsspeicher bei 96 MB niedrig ist. Im Idealfall sollte der Zähler also nicht unter 200-300 MB ausgeführt werden, um sicherzustellen, dass Sie über einen Puffer verfügen. Für Server mit 256-GB RAM oder höher möchten Sie wahrscheinlich sicherstellen, dass sie nicht unter 1 GB ausgeführt wird.

Beachten Sie, dass bei diesen Berechnungen davon ausgegangen wird, dass SQL Server den gesamten verfügbaren Arbeitsspeicher verwenden kann, es sei denn, Sie ändern sie so, dass sie für andere Anwendungen berücksichtigt werden. Berücksichtigen Sie die spezifischen Speicheranforderungen für Ihr Betriebssystem, andere Anwendungen, den SQL Server-Threadstapel und andere mehrseitige Zuweisungen. Eine typische Formel wäre ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), wobei der Speicher für Threadstapel = ((max worker threads) (stack size)). Die Stapelgröße beträgt 512 KB für x86-Systeme, 2 MB für x64-Systeme und 4 MB für IA64-Systeme, und Sie finden den Wert für maximale Arbeitsthreads in der spalte max_worker_count von sys.dm_os_sys_info.

Diese Überlegungen gelten auch für die Speicheranforderungen für SQL Server, die auf einem virtuellen Computer ausgeführt werden sollen. Da SQL Server für das Zwischenspeichern von Daten im Pufferpool konzipiert ist und in der Regel so viel Arbeitsspeicher wie möglich verwendet, kann es schwierig sein, die ideale Menge an RAM zu ermitteln, die benötigt wird. Wenn Sie den für eine SQL Server-Instanz zugewiesenen Arbeitsspeicher verringern, erreichen Sie schließlich einen Punkt, an dem niedrigere Speicherzuweisungen für einen höheren E/A-Zugriff auf Datenträger gehandelt werden.

Zum Konfigurieren des SQL Server-Speichers in einer Umgebung, die überlastet wurde, überwachen Sie zunächst die Umgebung und die aktuellen Leistungsmetriken, einschließlich der Lebenserwartung der SQL Server-Puffer-Manager-Seite und der Seitenlese/Sek. und der Physische Datenträger liest/s Werte. Wenn die Umgebung über einen übermäßigen Arbeitsspeicher verfügt, erhöht sich die Lebensdauer der Seiten um einen Wert von jeweils einer Sekunde, ohne dass die Arbeitsauslastung verringert wird. Die SQL Server-Puffer-Manager-Seite liest/s-Wert wird niedrig sein, nachdem die Cache-Rampen hoch sind. Außerdem bleibt der Lese-/Sek. des physischen Datenträgers niedrig.

Sobald Sie den Basisplan der Umgebung verstanden haben, können Sie den maximalen Serverspeicher um 1 GB reduzieren und dann sehen, wie sich dies auf Ihre Leistungsindikatoren auswirkt (nach allen anfänglichen Cache-Leerungsunterteilungen). Wenn die Metriken akzeptabel bleiben, verringern Sie sie um weitere 1 GB, und überwachen Sie dann erneut, und wiederholen Sie diese, bis Sie eine ideale Konfiguration bestimmen.

Weitere Informationen finden Sie unter Serverspeicherkonfigurationsoptionen.

Optimieren von TempDB

Die Größe und physische Platzierung der tempdb-Datenbank kann sich auf die Leistung von Operations Manager auswirken. Wenn die für tempdb definierte Größe z. B. zu klein ist, kann ein Teil der Systemverarbeitungslast mit der automatischen Vergrößerung von tempdb auf die Größe angewendet werden, die erforderlich ist, um die Workload jedes Mal zu unterstützen, wenn Sie die Instanz von SQL Server neu starten. Um eine optimale tempdb-Leistung zu erzielen, empfehlen wir die folgende Konfiguration für tempdb in einer Produktionsumgebung:

• Legen Sie das Wiederherstellungsmodell von tempdb auf SIMPLE fest. Mit diesem Modell wird automatisch der Protokollspeicherplatz freigegeben, um Platzbedarf klein zu halten.
• Weisen Sie allen tempdb-Dateien im Voraus Speicherplatz zu, indem Sie die Dateigröße auf einen Wert festlegen, der hoch genug ist, um der typischen Arbeitsauslastung in der Umgebung gerecht zu werden. Es verhindert, dass tempdb zu häufig erweitert wird, was sich auf die Leistung auswirken kann. Die tempdb-Datenbank kann auf automatische Vergrößerung festgelegt werden, dies sollte jedoch verwendet werden, um Speicherplatz für ungeplante Ausnahmen zu erhöhen.
• Erstellen Sie so viele Dateien wie erforderlich, um die Datenträgerbandbreite zu maximieren. Die Verwendung mehrerer Dateien reduziert die Tempdb-Speicherkonfliktion und führt zu einer verbesserten Skalierbarkeit. Erstellen Sie jedoch nicht zu viele Dateien, da sie die Leistung verringern und den Verwaltungsaufwand erhöhen kann. Erstellen Sie als allgemeine Richtlinie eine Datendatei für jeden logischen Prozessor auf dem Server (für alle Einstellungen für Affinitätsmasken), und passen Sie dann die Anzahl der Dateien bei Bedarf nach oben oder unten an. Folgende Faustregel gilt: Wenn die Anzahl von logischen Prozessoren kleiner oder gleich acht ist, verwenden Sie genauso viele Datendateien wie logische Prozessoren. Wenn die Anzahl der logischen Prozessoren größer als 8 ist, verwenden Sie acht Datendateien, und erhöhen Sie dann die Anzahl der Datendateien um Vielfache von 4 (bis zur Anzahl der logischen Prozessoren), bis der Inhalt auf akzeptable Ebenen reduziert wird, oder nehmen Sie Änderungen an der Workload/code vor. Wenn der Inhalt nicht reduziert wird, müssen Sie möglicherweise die Anzahl der Datendateien erhöhen.
• Sorgen Sie dafür, dass jede Datendatei die gleiche Größe aufweist, sodass eine optimale Proportionalfüllleistung erzielt werden kann. Die gleiche Größe von Datendateien ist wichtig, da der proportionale Füllalgorithmus auf der Größe der Dateien basiert. Wenn Datendateien mit ungleichen Größen erstellt werden, versucht der proportionale Füllalgorithmus, die größte Datei mehr für GAM-Zuordnungen zu verwenden, anstatt die Zuordnungen zwischen allen Dateien zu verbreiten, wodurch der Zweck der Erstellung mehrerer Datendateien verloren geht.
• Platzieren Sie die tempdb-Datenbank auf einem schnellen E/A-Subsystem mit Solid-State-Laufwerken für die optimale Leistung. Verwenden Sie Datenträgerstriping, wenn viele Datenträger direkt angeschlossen sind.
• Legen Sie die tempdb-Datenbank auf anderen Datenträgeren ab als denen, die von den Benutzerdatenbanken verwendet werden.

Zum Konfigurieren von tempdb können Sie die folgende Abfrage ausführen oder deren Eigenschaften in Management Studio ändern.

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

Führen Sie die T-SQL-Abfrage SELECT * from sys.sysprocesses aus, um seitenzuordnungsinhalte für die tempdb-Datenbank zu erkennen. In der Systemtabellenausgabe wird die Warteressource möglicherweise als "2:1:1" (PFS-Seite) oder "2:1:3" (Shared Global Allocation Map Page) angezeigt. Je nach Grad des Inhalts kann dies auch dazu führen, dass SQL Server für kurze Zeiträume nicht reagiert. Ein weiterer Ansatz besteht darin, die dynamischen Verwaltungsansichten zu untersuchen [sys.dm_exec_request oder sys.dm_os_waiting_tasks]. Die Ergebnisse zeigen, dass diese Anforderungen oder Aufgaben auf tempdb-Ressourcen warten und ähnliche Werte aufweisen, wie zuvor hervorgehoben, wenn Sie die Sys.sysprocesses-Abfrage ausführen.

Wenn die vorherigen Empfehlungen die Zuordnungsverknüpfung nicht erheblich reduzieren und sich der Inhalt auf SGAM-Seiten befindet, implementieren Sie ablaufverfolgungskennzeichnung -T1118 in den Startparametern für SQL Server, sodass das Ablaufverfolgungsflagge auch nach der Wiederverwendung von SQL Server wirksam bleibt. Unter dieser Ablaufverfolgungskennzeichnung weist SQL Server jedem Datenbankobjekt volle Ausmaße zu, wodurch der Inhalt auf SGAM-Seiten eliminiert wird.

Hinweis

Dieses Ablaufverfolgungskennzeichnung wirkt sich auf jede Datenbank in der Instanz von SQL Server aus.

Max. Grad der Parallelität

Die Standardkonfiguration von SQL Server für kleine bis mittlere Bereitstellungen von Operations Manager ist für die meisten Anforderungen geeignet. Wenn die Arbeitsauslastung der Verwaltungsgruppe jedoch auf ein Szenario der Unternehmensklasse (in der Regel 2.000+ agentverwaltete Systeme und eine erweiterte Überwachungskonfiguration, einschließlich Überwachung auf Dienstebene mit erweiterten synthetischen Transaktionen, Netzwerkgeräteüberwachung, plattformübergreifende usw.) skaliert wird, ist es erforderlich, die konfiguration von SQL Server zu optimieren, die in diesem Abschnitt des Dokuments beschrieben wird. Eine Konfigurationsoption, die in früheren Anleitungen nicht erläutert wurde, ist MAXDOP.

Die Max.-Parallelitätsoption (MaxDOP) von Microsoft SQL Server steuert die Anzahl der Prozessoren, die für die Ausführung einer Abfrage in einem parallelen Plan verwendet werden. Diese Option bestimmt die Computer- und Threadressourcen, die für die Abfrageplanoperatoren verwendet werden, die die Arbeit parallel ausführen. Je nachdem, ob SQL Server auf einem symmetrischen Multiprocessing-Computer (SMP), einem nicht uniform memory access (NUMA)-Computer oder Hyperthreading-fähigen Prozessoren eingerichtet ist, müssen Sie die maximale Parallelitätsoption entsprechend konfigurieren.

Wenn SQL Server auf einem Computer mit mehr als einem Mikroprozessor oder einer CPU ausgeführt wird, erkennt er den besten Grad an Parallelität, d. h. die Anzahl der Prozessoren, die zum Ausführen einer einzelnen Anweisung verwendet werden, für jede parallele Planausführung. Standardmäßig ist der Wert für diese Option 0, wodurch SQL Server den maximalen Grad an Parallelität bestimmen kann.

Die gespeicherten Prozeduren und Abfragen, die in Operations Manager vordefiniert sind, wie sie sich auf das operative, Data Warehouse und sogar die Überwachungsdatenbank beziehen, enthalten nicht die OPTION MAXDOP, da während der Installation keine Möglichkeit besteht, dynamisch abzufragen, wie viele Prozessoren dem Betriebssystem angezeigt werden, noch versucht es, den Wert für diese Einstellung zu hartcodieren, was negative Folgen haben könnte, wenn die Abfrage ausgeführt wird.

Hinweis

Der maximale Grad der Parallelitätskonfigurationsoption beschränkt nicht die Anzahl der Prozessoren, die der SQL Server verwendet. Verwenden Sie die Konfigurationsoption "Affinitätsmaske", um die Anzahl der von SQL Server verwendeten Prozessoren zu konfigurieren.

• Verwenden Sie für Server, die mehr als acht Prozessoren verwenden, die folgende Konfiguration: MAXDOP=8
• Verwenden Sie für Server, die acht oder weniger Prozessoren verwenden, die folgende Konfiguration: MAXDOP=0 bis N

  Hinweis

  In dieser Konfiguration stellt N die Anzahl der Prozessoren dar.