Überlegungen zum Entwurf von SQL Server

System Center Operations Manager erfordert Zugriff auf eine Serverinstanz, auf der Microsoft SQL Server ausgeführt wird, um die Betriebsdatenbank, die Data Warehouse-Datenbank und die ACS-Überwachungsdatenbank zu unterstützen. Die Betriebsdatenbank und die Data Warehouse-Datenbank sind erforderlich und werden erstellt, wenn Sie den ersten Verwaltungsserver in Ihrer Verwaltungsgruppe bereitstellen. Die ACS-Datenbank wird erstellt, wenn Sie eine ACS-Sammlung in Ihrer Verwaltungsgruppe bereitstellen.

In einer Laborumgebung oder einer kleinen Operations Manager-Bereitstellung kann SQL Server zusammen mit anderen Komponenten auf dem ersten Verwaltungsserver in der Verwaltungsgruppe installiert werden.

In einer verteilten mittelgroßen oder sehr großen Bereitstellung sollte die SQL Server-Instanz auf einem dedizierten eigenständigen Server oder in einer SQL Server-Hochverfügbarkeitskonfiguration installiert werden. In beiden Fällen muss die SQL Server-Instanz bereits vorhanden und verfügbar sein, bevor Sie mit der Installation des ersten Verwaltungsservers oder der ersten ACS-Sammlung beginnen.

Es wird nicht empfohlen, Operations Manager-Datenbanken aus einer SQL-Instanz zu verwenden, die über andere Anwendungsdatenbanken verfügt. Dadurch sollen potenzielle Probleme mit Einschränkungen von E/A- und anderen Hardwareressourcen vermieden werden.

Wichtig

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

SQL Server-Anforderungen

Die folgenden Versionen von SQL Server Enterprise und SQL Server Standard werden für eine vorhandene Installation der System Center Operations Manager-Version zum Hosten des Berichtsservers, der Betriebsdatenbank, von Data Warehouse und der ACS-Datenbank unterstützt:

• 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 höher und MSOLEDBSQL 18.2 oder höher.

• SQL Server 2017 und kumulative Updates, wie hier beschrieben

Lesen Sie vor dem Upgrade SQL Server die Upgradeinformationen für 2017 und Upgradeinformationen für SQL 2019.

Hinweis

• Alle folgenden SQL Server Komponenten, die eine SCOM-Infrastruktur unterstützen, müssen dieselbe SQL Server-Hauptversion aufweisen:
  • SQL Server Datenbank-Engine-Instanzen, die eine der SCOM-Datenbanken hosten (d. a. 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 einheitlichen Modus installiert werden (der integrierte SharePoint-Modus wird nicht unterstützt).

In Ihrer Entwurfsplanung müssen noch einige weitere Aspekte hinsichtlich der Hardware und Software berücksichtigt werden:

• Es wird empfohlen, SQL Server auf Computern mit dem NTFS-Dateiformat auszuführen.
• Für die Betriebsdatenbank und die Data Warehouse-Datenbank müssen mindestens 1024 MB freier Speicherplatz verfügbar sein. Dies wird zum Zeitpunkt der Datenbankerstellung erzwungen und wird nach dem Setup wahrscheinlich erheblich zunehmen.
• .NET Framework 4 ist erforderlich.
• .NET Framework 4.8 wird ab Operations Manager 2022 unterstützt.
• Der Berichtsserver 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 Authentifizierungseinstellung für SQL im gemischten Modus weiterhin, wenn kein lokales Konto über die rolle "db_owner" verfügt. Lokale Konten mit der rolle "db_owner" verursachen bekanntermaßen Probleme mit System Center Operations Manager. Entfernen Sie die Rolle db_owner aus allen lokalen Konten, bevor Sie das Produkt installieren, und fügen Sie die rolle db_owner nach der Installation keinem der lokalen Konten hinzu.

Einstellung für die SQL Server-Sortierung

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

Hinweis

Es wird empfohlen, dieselbe Sortierung für die SQL- und Operations Manager-Datenbank zu verwenden, um Kompatibilitätsprobleme beim Vergleichen oder Kopieren von Vorgängen zu vermeiden.

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 Ihr SQL Server instance nicht mit einer der zuvor aufgeführten unterstützten Sortierungen konfiguriert ist, schlägt die Durchführung einer neuen Einrichtung des Operations Manager-Setups fehl. Allerdings kann ein direktes Upgrade erfolgreich abgeschlossen werden.

Firewallkonfiguration

Operations Manager benötigt SQL Server zum Hosten der Datenbanken und einer Berichtsplattform, um operative Verlaufsdaten zu analysieren und darzustellen. Die Verwaltungsserver-, Betriebs- 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 richtig konfigurieren zu können.

Wenn Sie eine verteilte Bereitstellung entwerfen, bei der SQL Always On-Verfügbarkeitsgruppen Failoverfunktionen für die Operations Manager-Datenbanken bereitstellen müssen, müssen zusätzliche Firewallkonfigurationseinstellungen in Ihre Firewallsicherheitsstrategie aufgenommen werden.

In der folgenden Tabelle finden Sie die Firewallports, die für SQL Server mindestens zugelassen werden müssen, damit die Serverrollen in Ihrer Operations Manager-Verwaltungsgruppe erfolgreich kommunizieren können.

Szenario	Port	Richtung	Operations Manager-Rolle
SQL Server-Instanz, auf der Operations Manager-Datenbanken gehostet werden	TCP 1433 *	Eingehende Verbindungen	Verwaltungsserver und Webkonsole (für Application Advisor und Anwendungsdiagnose)
SQL Server-Browserdienst	UDP 1434	Eingehende Verbindungen	-Verwaltungsserver
Dedizierte SQL Server-Verwaltungsverbindung	TCP 1434	Eingehende Verbindungen	-Verwaltungsserver
Zusätzliche von SQL Server verwendete Ports – Microsoft Remoteprozeduraufrufe (MS RPC) – Windows-Verwaltungsinstrumentation (WMI) – Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Eingehende Verbindungen	-Verwaltungsserver
Listener für SQL Server-Always On-Verfügbarkeitsgruppen	Vom Administrator konfigurierter Port	Eingehende Verbindungen	-Verwaltungsserver
SQL Server Reporting Services, die den Operations Manager-Berichtsserver hosten	TCP 80 (Standard)/443 (SSL)	Eingehende Verbindungen	Verwaltungsserver und Betriebskonsole

* 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 detailliertere Übersicht über die Firewallanforderungen für SQL Server finden Sie unter Konfigurieren der Windows Firewallanforderungen für das Zulassen von SQL Server-Zugriff.

Überlegungen zu Kapazität und Speicher

Operations Manager-Datenbank

Die Operations Manager-Datenbank ist eine SQL Server-Datenbank, die alle Daten enthält, die Operations Manager für die tägliche Überwachung benötigt. Die richtige Dimensionierung und Konfiguration des Datenbankservers ist entscheidend für die Gesamtleistung der Verwaltungsgruppe. Die wichtigste Ressource, die von der Operations Manager-Datenbank genutzt wird, ist das Speichersubsystem. CPU und RAM sind jedoch ebenfalls von großer Bedeutung.

Folgende Faktoren beeinflussen die Auslastung auf der Operations Manager-Datenbank:

• Sammlungsrate für operative Daten. Bei operativen Daten handelt es sich um all die Ereignisse, Warnungen, Zustandsänderungen und Leistungsdaten, die von Agents gesammelt werden. Die meisten Ressourcen, die von der Operations Manager-Datenbank verwendet werden, dienen dazu, diese Daten auf Datenträger zu schreiben, sobald sie in das System gelangen. Die Rate, mit der operative Daten gesammelt werden, steigt üblicherweise, wenn weitere Management Packs importiert und weitere Agents hinzugefügt werden. Auch der von einem Agent überwachte Computertyp ist ein wichtiger Faktor, der bei der Bestimmung der Gesamtrate der Sammlung von operativen Daten berücksichtigt werden muss. Ein Agent, der einen geschäftskritischen Desktopcomputer überwacht, wird z.B. wahrscheinlich weniger Daten sammeln als ein Agent, der einen Server überwacht, auf dem eine SQL Server-Instanz mit einer großen Zahl von Datenbanken ausgeführt wird.
• Rate der Änderungen am Instanzspeicherplatz. Die Aktualisierung dieser Daten in der Operations Manager-Datenbank ist teuer im Vergleich zum Schreiben neuer operativer Daten. Wenn sich Daten im Instanzspeicherplatz ändern, führen die Verwaltungsserver zusätzliche Abfragen in der Operations Manager-Datenbank aus, um Konfigurations- und Gruppenänderungen zu berechnen. Die Rate der Änderungen im Instanzspeicherplatz steigt, wenn Sie weitere Management Packs in eine Verwaltungsgruppe importieren. Durch Hinzufügen neuer Agents zu einer Verwaltungsgruppe steigt die Änderungsrate im Instanzspeicherplatz vorübergehend ebenfalls.
• Die Anzahl von Betriebskonsolen und anderen gleichzeitig ausgeführten SDK-Verbindungen. Jede Betriebskonsole liest Daten aus der Operations Manager-Datenbank. Die Abfrage dieser Daten kann große Mengen an E/A-Speicherressourcen, CPU-Zeit und RAM verbrauchen. Betriebskonsolen, die große Mengen an operativen Daten in der Ereignisansicht, der Statusansicht, der Warnungsansicht und der Leistungsdatenansicht anzeigen, verursachen tendenziell die größte Auslastung auf der Datenbank.

Die Operations Manager-Datenbank ist ein Single Point of Failure (SPOF) für die Verwaltungsgruppe und kann daher mithilfe unterstützter Failoverkonfigurationen hoch verfügbar gemacht werden, z.B. mit SQL Server-Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen.

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 für die Operations Manager-Datenbank

System Center Operations Manager verwendet den SQL Server Service Broker für die Implementierung aller Aufgabenvorgänge. Wenn der SQL Server Service Broker deaktiviert ist, sind davon sämtliche Aufgabenvorgä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 folgende Schritte aus, um den 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 im Feld is_broker_enabled angezeigte Wert is_broker_enabled lautet. Andernfalls führen Sie 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 nahezu in Echtzeit in das Reporting Data Warehouse ein. Es ist wichtig, dass auf diesem Server genügend Kapazität vorhanden ist, der das Schreiben aller daten unterstützt, die in das Reporting Data Warehouse gesammelt werden. Genau wie bei der Operations Manager-Datenbank ist das E/A-Speichersubsystem die wichtigste Ressource im Reporting-Data Warehouse. In den meisten Systemen ähneln die Auslastungen im Reporting-Data Warehouse denen in der Operations Manager-Datenbank, sie können jedoch variieren. Außerdem unterscheidet sich die Arbeitsauslastung, die durch die Berichterstellung im Reporting-Data Warehouse entsteht, von der Auslastung, die durch die Nutzung der Betriebskonsole in der Operations Manager-Datenbank entsteht.

Folgende Faktoren beeinflussen die Auslastung im Reporting-Data Warehouse:

• Sammlungsrate für operative Daten. Um eine effizientere Berichterstellung zu ermöglichen, berechnet und speichert das Reporting-Data Warehouse aggregierte Daten sowie eine begrenzte Menge an Rohdaten. Durch diesen zusätzlichen Aufwand kann die Sammlung operativer Daten im Reporting-Data Warehouse etwas teurer sein als in der Operations Manager-Datenbank. Diese zusätzlichen Kosten werden im Allgemeinen dadurch ausgeglichen, dass für die Verarbeitung von Ermittlungsdaten im Reporting-Data Warehouse geringere Kosten anfallen als in der Operations Manager-Datenbank.
• Die Anzahl von gleichzeitigen Berichterstellungsbenutzern oder die geplante Generierung von Berichten. Da Berichte häufig große Datenmengen zusammenfassen, kann jeder Berichterstellungsbenutzer dem System eine erhebliche Auslastung hinzufügen. Die Anzahl von gleichzeitig ausgeführten Berichten und die Berichtstypen wirken sich auf den gesamten Kapazitätsbedarf aus. Allgemein gilt: Berichte, die sehr große Datumsbereiche oder große Mengen an Objekten abfragen, erfordern zusätzliche Systemressourcen.

Basierend auf diesen Faktoren gibt es mehrere empfohlene Methoden, die berücksichtigt werden sollten, um das Reporting-Data Warehouse richtig zu dimensionieren:

• Wählen Sie ein geeignetes Speichersubsystem. Das Reporting-Data Warehouse ist ein integraler Bestandteil des gesamten Datenflusses durch die Verwaltungsgruppe. Daher ist die Auswahl eines geeigneten Speichersubsystems für das Reporting-Data Warehouse von großer Bedeutung. Ebenso 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 das gleiche sein wie für die Operations Manager-Datenbank, und die Informationen und Anleitungen, die für die Operations Manager-Datenbank gelten, gelten auch für das Reporting-Data Warehouse.
• Planen Sie die geeigneten Speicherorte für die Datenprotokolle und Transaktionsprotokolle. Ebenso wie bei der Operations Manager-Datenbank empfiehlt es sich häufig, die SQL-Datenprotokolle und die Transaktionsprotokolle zu trennen, wenn Sie die Anzahl von Agents erhöhen. Wenn sich die Operations Manager-Datenbank und das Reporting-Data Warehouse auf dem gleichen Server befinden und Sie die Daten- und Transaktionsprotokolle trennen möchten, müssen Sie die Transaktionsprotokolle für die Operations Manager-Datenbank und das Reporting-Data Warehouse auf separaten physischen Volumes und Datenträgerspindeln speichern, um einen Vorteil zu erzielen. Die Datendateien für die Operations Manager-Datenbank und das Reporting Data Warehouse können dasselbe physische Volume gemeinsam nutzen, solange das Volume eine ausreichende Kapazität bietet und die Datenträger-E/A-Leistung die Überwachungs- und Berichterstellungsfunktionen nicht negativ beeinflusst.
• Ziehen Sie in Betracht, das Reporting-Data Warehouse auf einem anderen Server zu installieren als die Operations Manager-Datenbank. Obwohl kleinere Bereitstellungen häufig die Operations Manager-Datenbank und das Reporting Data Warehouse auf demselben Server konsolidieren können, ist es von Vorteil, diese zu trennen, wenn Sie die Anzahl der Agents und die Menge der eingehenden Betriebsdaten hochskalieren. Wenn sich Reporting-Data Warehouse und der Berichtsserver auf einem anderen Server befinden als die Operations Manager-Datenbank, lassen sich bei der Berichterstellung bessere Leistungsergebnisse erzielen.

Die Data Warehouse-Datenbank von Operations Manager ist ein Single Point of Failure (SPOF) für die Verwaltungsgruppe und kann daher mithilfe unterstützter Failoverkonfigurationen hoch verfügbar gemacht werden, z.B. mit SQL Server-Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen.

SQL Server Always On

SQL Server Always On-Verfügbarkeitsgruppen unterstützen Failoverumgebungen für eine gesonderte Gruppe von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jede Gruppe von Verfügbarkeitsdatenbanken wird durch ein Verfügbarkeitsreplikat gehostet.

Bei System Center 2016 – Operations Manager (und höher) ist SQL Always On gegenüber dem Failoverclustering zu bevorzugen, wenn es um die Bereitstellung von Hochverfügbarkeit von Datenbanken geht. Alle Datenbanken können in einer Always On-Verfügbarkeitsgruppe gehostet werden – außer in der Reporting Services-Installation im einheitlichen Modus, bei der zwei Datenbanken verwendet werden, um den permanenten Datenspeicher von temporären Speicheranforderungen zu trennen.

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.

Zum Einrichten einer Verfügbarkeitsgruppe müssen Sie einen WSFC-Cluster (Windows Server Failover Clustering) zum Hosten des Verfügbarkeitsreplikats bereitstellen und Always On auf den Clusterknoten aktivieren. Anschließend können Sie die SQL Server-Datenbank von Operations Manager als Verfügbarkeitsdatenbank hinzufügen.

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

Hinweis

Nachdem Sie Operations Manager auf den SQL Server-Knoten bereitgestellt haben, die in SQL Always On integriert sind, um CLR Strict Security zu aktivieren, führen Sie das SQL-Skript für jede Operations Manager-Datenbank aus.

Zeichenfolge mit mehreren Subnetzen

Operations Manager unterstützt die Verbindungszeichenfolge Schlüsselwörter (MultiSubnetFailover=True) nicht. Da eine Verfügbarkeitsgruppe einen Listenernamen hat (der sogenannte Netzwerkname oder Clientzugriffspunkt im WSFC-Cluster-Manager), der von mehreren IP-Adressen aus unterschiedlichen Subnetzen abhängt, z.B. bei der Bereitstellung einer standortübergreifenden Failoverkonfiguration, erreichen Clientverbindungsanforderungen von den Verwaltungsservern an den Listener der Verfügbarkeitsgruppe ein Verbindungstimeout.

Der empfohlene Ansatz, um diese Einschränkung zu umgehen, wenn Sie Serverknoten in der Verfügbarkeitsgruppe in einer Multisubnetzumgebung bereitgestellt haben, besteht darin, die folgenden Schritte auszuführen:

1. Legen Sie den Netzwerknamen Ihres Verfügbarkeitsgruppenlisteners so fest, dass nur eine einzelne aktive IP-Adresse in DNS registriert wird.
2. Konfigurieren Sie den Cluster so, dass er einen niedrigen TTL-Wert für den registrierten DNS-Eintrag verwendet.

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

Führen Sie die folgenden PowerShell-Befehle auf einem der SQL-Knoten aus, um die zugehörigen 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 auf dem Listener vornehmen. Weitere Informationen zum Konfigurieren eines Verfügbarkeitsgruppenlisteners finden Sie in der Folgenden Dokumentation: Konfigurieren des Verfügbarkeitsgruppenlisteners – SQL Server Always On

Führen Sie die folgenden PowerShell-Befehle auf dem SQL-Knoten aus, auf dem der Listener derzeit gehostet wird, um dessen 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 gruppierte oder Always On-SQL-Instanz für hohe Verfügbarkeit verwendet wird, sollten Sie die automatische Wiederherstellungsfunktion auf Ihren Verwaltungsservern aktivieren, um den Neustart des Operations Manager-Datenzugriffsdiensts bei jedem Auftreten eines Failovers zwischen Knoten zu vermeiden. Informationen zur entsprechenden Konfiguration finden Sie im KB-Artikel Der System Center-Verwaltungsdienst reagiert nicht mehr, nachdem eine SQL Server-Instanz offline gegangen ist.

Optimieren von SQL Server

Im Allgemeinen zeigt die vorherige Bereitstellung von Kunden, dass Leistungsprobleme in der Regel nicht durch eine hohe Ressourcenauslastung (d. h. Prozessor oder Arbeitsspeicher) mit SQL Server selbst verursacht werden, sondern direkt mit der Konfiguration des Speichersubsystems zusammenhängen. Leistungsengpässe sind häufig darauf zurückzuführen, dass beim Bereitstellen des Speichers für die SQL Server-Datenbankinstanz die empfohlenen Konfigurationsrichtlinien nicht eingehalten werden. Einige Beispiele:

• Unzureichende Zuweisung von Spindeln für die LUNs, um die E/A-Anforderungen von Operations Manager zu unterstützen.
• Hosten von Transaktionsprotokollen und Datenbankdateien auf dem gleichen Volume. Diese beiden Workloads verfügen über unterschiedliche E/A- und Latenzmerkmale.
• Die Konfiguration von TempDB ist in Bezug auf Platzierung, Größenanpassung usw. falsch.
• Disk partition misalignment of volumes hosting the database transaction logs, database files, and TempDB.
• Übersehen Sie die grundlegenden SQL Server Konfiguration, z. B. die Verwendung von AUTOGROW für Datenbank- und Transaktionsprotokolldateien, die MAXDOP-Einstellung für Abfrageparallelität, das Erstellen mehrerer TempDB-Datendateien pro CPU-Kern usw.

Die Speicherkonfiguration ist eine der wichtigsten Komponenten einer SQL Server-Bereitstellung für Operations Manager. Datenbankserver sind aufgrund der hohen Lese- und Schreibaktivitäten und Transaktionsprotokollverarbeitung der Datenbank häufig sehr stark auf E/A-Aktivitäten ausgerichtet. Das E/A-Verhaltensmuster von Operations Manager umfasst typischerweise 80% Schreibvorgänge und 20% Lesevorgänge. Eine fehlerhafte Konfiguration von E/A-Subsystemen kann daher zu einer unzureichenden Leistung von SQL Server-Systemen führen und macht sich in Operations Manager bemerkbar.

Es ist wichtig, den entwurf der SQL Server zu testen, indem Sie vor der Bereitstellung von SQL Server Durchsatztests des E/A-Subsystems durchführen. Stellen Sie sicher, dass diese Tests Ihre E/A-Anforderungen mit einer akzeptablen Latenz erfüllen können. Verwenden Sie Diskspd Utility (das Diskspd-Hilfsprogramm), um die E/A-Kapazitäten des Speichersubsystems auszuwerten, das SQL Server unterstützt. Der folgende Blogartikel, der von einem Mitglied des Dateiserverteams in der Produktgruppe verfasst wurde, enthält ausführliche Anleitungen und Empfehlungen zum Ausführen von Stresstests mit diesem Tool mit PowerShell-Code und zum Erfassen der Ergebnisse mit PerfMon. Eine erste Anleitung finden Sie auch im Tool zur Dimensionierung von Operations Manager.

Größe der NTFS-Zuordnungseinheit

Die Volumeausrichtung, häufig auch als Sektorausrichtung bezeichnet, sollte auf dem Dateisystem (NTFS) immer dann durchgeführt werden, wenn ein Volume auf einem RAID-Gerät erstellt wird. Andernfalls kann dies zu einer erheblichen Leistungsbeeinträchtigung führen und ist in der Regel das Ergebnis einer fehlgeleiteten Partitionsausrichtung mit Stripeeinheitsgrenzen. Dies kann auch zu einer fehlerhaften Ausrichtung des Hardwarecaches und damit zu einer ineffizienten Nutzung des Arraycaches führen. Beim Formatieren der Partition, die für SQL Server Datendateien verwendet wird, wird empfohlen, für Daten, Protokolle und tempdb eine Zuordnungseinheitsgröße von 64 KB (d. h. 65.536 Bytes) zu verwenden. Beachten Sie jedoch, dass die Verwendung von Größen von Zuordnungseinheiten, die größer als 4 KB sind, dazu führt, dass die NTFS-Komprimierung auf dem Volume nicht verwendet werden kann. Obwohl SQL Server schreibgeschützte Daten auf komprimierten Volumes unterstützt, wird dies nicht empfohlen.

Reservieren von Arbeitsspeicher

Hinweis

Ein Großteil der Informationen in diesem Abschnitt stammen von Jonathan Kehayias aus seinem Blogbeitrag How much memory does my SQL Server actually need? (sqlskills.com).

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

SQL Server ermöglicht die Konfiguration der Minimal- und Maximalwerte für den Arbeitsspeicher, der für diesen Prozess reserviert wird und von diesem verwendet wird. Standardmäßig kann SQL Server den Arbeitsspeicherbedarf je nach verfügbaren Systemressourcen dynamisch anpassen. Die Standardeinstellung für Min. Serverarbeitsspeicher ist 0, die für Max. Serverarbeitsspeicher 2.147.483.647 MB.

Leistungs- und speicherbezogene Probleme können auftreten, wenn Sie keinen geeigneten Wert für Max. Serverarbeitsspeicher festlegen. Viele Faktoren beeinflussen, wie viel Arbeitsspeicher Sie SQL Server zuordnen 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 Virenscans in Echtzeit. Wenn nicht genügend Arbeitsspeicher festgelegt wird, werden das Betriebssystem und SQL auf Datenträger ausgelagert. Dies kann dazu führen, dass die Datenträger-E/A zunimmt, die Leistung weiter abnimmt und so ein „Welleneffekt“ entsteht, der dann auch in Operations Manager sichtbar wird.

Es wird empfohlen, mindestens 4 GB RAM für den min. Serverarbeitsspeicher anzugeben. Dieser Wert muss für jeden SQL-Knoten angegeben werden, der eine der Operations Manager-Datenbanken (Betriebsdatenbank, Data Warehouse-Datenbank, ACS-Datenbank) hostet.

Für den maximalen Serverspeicher empfiehlt es sich, zunächst insgesamt folgende Werte zu reservieren:

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

Überwachen Sie nach Festlegen dieser Werte den Leistungsindikator 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 mit 96 MB knapp wird. Im Idealfall sollte der Zähler also nicht kleiner als 200 bis 300 MB sein, um sicherzustellen, dass Sie über einen Puffer verfügen. Bei Servern mit 256 GB RAM oder höher sollten Sie wahrscheinlich sicherstellen, dass die Ausführung nicht kleiner als 1 GB ist.

Beachten Sie, dass bei diesen Berechnungen davon ausgegangen wird, dass SQL Server den gesamten verfügbaren Arbeitsspeicher nutzen soll, es sei denn, Sie ändern diesen Wert, um andere Anwendungen zu berücksichtigen. Berücksichtigen Sie die spezifischen Arbeitsspeicheranforderungen für Ihr Betriebssystem, für andere Anwendungen, den SQL Server-Threadstapel und weitere 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 Arbeitsspeicher für den Threadstapel ((max worker threads) (stack size)) beträgt. Die Stapelgröße beträgt 512 KB für x86-Systeme, 2 MB für x64-Systeme und 4 MB für IA64-Systeme. Sie finden den Wert für die max. Anzahl von Arbeitsthreads in der „max_worker_count“-Spalte von sys.dm_os_sys_info.

Diese Überlegungen gelten auch für die Arbeitsspeicheranforderungen für die SQL Server-Instanz, die auf einem virtuellen Computer ausgeführt werden soll. 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 bestimmen. Wenn Sie den Arbeitsspeicher reduzieren, der einer SQL Server-Instanz zugeordnet ist, erreichen Sie schließlich einen Punkt, an dem eine niedrigere Speicherzuweisung für einen höheren Datenträger-E/A-Zugriff erreicht wird.

Wenn Sie SQL Server-Arbeitsspeicher in einer Umgebung konfigurieren möchten, die übermäßig bereitgestellt wurde, beginnen Sie, indem Sie die Umgebung sowie die aktuellen Leistungsmetriken überwachen, einschließlich der Seitenlebenserwartung des Puffer-Mangers von SQL Server sowie der Werte page reads/sec und disk reads/sec des physischen Datenträgers. Wenn die Umgebung einen Überschuss an Arbeitsspeicher aufweist, erhöht sich die Seitenlebenserwartung aufgrund der Zwischenspeicherung um einen Wert von eins pro Sekunde, ohne dass die Arbeitsauslastung abnimmt. Der Wert page reads/sec des Puffer-Managers von SQL Server ist nach dem Anstieg des Caches niedrig, und der Wert disk reads/sec des physischen Datenträgers bleibt ebenfalls niedrig.

Sobald Sie die Umgebungsbaseline verstanden haben, können Sie den maximalen Serverarbeitsspeicher um 1 GB reduzieren und dann beobachten, wie sich dies auf Ihre Leistungsindikatoren auswirkt (nach allen anfänglichen Cacheleerungen). Wenn die Metriken akzeptabel bleiben, verringern Sie sie um weitere 1 GB, überwachen Sie sie dann weiterhin, und wiederholen Sie den Vorgang nach Bedarf, bis eine ideale Konfiguration bestimmt werden kann.

Weitere Informationen finden Sie unter Konfigurationsoptionen für den Serverarbeitsspeicher.

Optimieren von tempdb

Größe und physische Platzierung der tempdb-datenbank-Datenbank können sich auf die Leistung von Operations Manager auswirken. Wenn für „tempdb“ eine zu geringe Größe definiert ist, wird beim Neustarten der SQL Server-Instanz ein Teil der Systemverarbeitungslast möglicherweise dafür verbraucht, „tempdb“ automatisch auf die Größe zu erweitern, die zur Unterstützung der Arbeitsauslastung erforderlich ist. Um eine optimale tempdb-Leistung zu erzielen, empfiehlt sich die folgende tempdb-Konfiguration in einer Produktionsumgebung:

• Legen Sie das Wiederherstellungsmodell von tempdb auf „SIMPLE“ fest. Dieses Modell fordert automatisch Protokollspeicherplatz zurück, um den Speicherplatzbedarf so gering wie möglich zu halten.
• Weisen Sie vorab Speicherplatz für alle tempdb-Dateien zu, indem Sie die Dateigröße auf einen Wert festlegen, der groß genug ist, um die typische Arbeitsauslastung in der Umgebung zu verarbeiten. Dies verhindert, dass „tempdb“ zu häufig erweitert wird, was die Leistung beeinträchtigen kann. Die tempdb-Datenbank kann auf die automatische Vergrößerung festgelegt werden, diese Einstellung sollte aber verwendet werden, um den Datenträgerspeicherplatz bei Ausnahmen zu erweitern.
• Erstellen Sie so viele Dateien, wie benötigt werden, um die Datenträgerbandbreite zu maximieren. Die Verwendung mehrerer Dateien reduziert Speicherkonflikte in „tempdb“ und bietet eine bessere Skalierbarkeit. Erstellen Sie jedoch nicht zu viele Dateien, da dies die Leistung verringern und den Verwaltungsaufwand erhöhen kann. Als allgemeine Richtlinie sollten Sie eine Datendatei für jeden logischen Prozessor auf dem Server erstellen (unter Berücksichtigung eventueller Affinitätsmaskeneinstellungen) und die Anzahl von Dateien dann bei Bedarf nach oben oder unten anpassen. 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 von logischen Prozessoren größer als acht ist, verwenden Sie acht Datendateien, und erhöhen Sie im Fall andauernder Speicherkonflikte die Anzahl von Datendateien so lange um ein Vielfaches von 4 (bis zur Anzahl von logischen Prozessoren), bis die Konflikte auf ein akzeptables Maß reduziert sind. Alternativ dazu können Sie auch Änderungen an Arbeitsauslastung oder Code vornehmen. Wenn der Konflikt nicht reduziert wird, müssen Sie möglicherweise die Anzahl der Datendateien erhöhen.
• Legen Sie für jede Datendatei die gleiche Größe fest, sodass eine optimale proportionale Füllleistung ermöglicht wird. Die gleiche Größe ist sehr wichtig, da der Algorithmus für das proportionale Füllen auf der Dateigröße basiert. Wenn die Datendateien mit verschiedenen Dateigrößen erstellt werden, versucht der Algorithmus für das proportionale Füllen, die größte Datei häufiger für GAM-Zuordnungen zu verwenden, anstatt die Zuordnungen gleichmäßig auf alle Dateien zu verteilen. Damit wäre die Erstellung mehrerer Dateien sinnlos.
• Stellen Sie die tempdb-Datenbank auf einem schnellen E/A-Subsystem bereit, und verwenden Sie Solid-State-Laufwerke, um eine optimale Leistung zu erzielen. Verwenden Sie Datenträgerstriping, wenn das System viele direkt angeschlossene Datenträger umfasst.
• Stellen Sie die tempdb-Datenbank auf anderen als den Datenträgern bereit, die von Benutzerdatenbanken verwendet werden.

Zum Konfigurieren von „tempdb“ können Sie die folgende Abfrage verwenden oder ihre Eigenschaften in Management Studio bearbeiten.

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 Seitenzuordnungskonflikte 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“ (SGAM-Seite [Shared Global Allocation Map]) angezeigt. Je nach Konfliktgrad kann dies auch dazu führen, dass SQL Server kurze Zeit nicht reagiert. Ein anderer Ansatz ist die Untersuchung der dynamischen Verwaltungssichten „sys.dm_exec_request“ oder „sys.dm_os_waiting_tasks“ (Dynamic Management Views, DMVs). 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 den Zuordnungskonflikt nicht erheblich reduzieren und der Konflikt auf SGAM-Seiten liegt, implementieren Sie das Ablaufverfolgungsflag -T1118 in den Startparametern für SQL Server, damit das Ablaufverfolgungsflag auch nach der Wiederverwendung SQL Server wirksam bleibt. Mit diesem Ablaufverfolgungsflag ordnet SQL Server jedem Datenbankobjekt vollständige Blöcke zu und behebt so die Konflikte auf SGAM-Seiten.

Hinweis

Dieses Ablaufverfolgungsflag wirkt sich auf jede Datenbank auf der instance von SQL Server aus.

Maximaler Grad an Parallelität

Die Standardkonfiguration von SQL Server für kleine bis mittelgroße Bereitstellungen von Operations Manager ist für die meisten Zwecke ausreichend. Wenn die Workload der Verwaltungsgruppe jedoch auf ein Unternehmensklassenszenario skaliert wird (in der Regel mehr als 2.000 mit Agent verwaltete Systeme und eine erweiterte Überwachungskonfiguration, die die Überwachung auf Dienstebene mit erweiterten synthetischen Transaktionen, netzwerkübergreifende Überwachung, plattformübergreifende Usw.) umfasst, ist es erforderlich, die Konfiguration der in diesem Abschnitt des Dokuments beschriebenen SQL Server zu optimieren. Eine Konfigurationsoption, die in der vorherigen Anleitung nicht behandelt wurde, ist MAXDOP.

Die Microsoft SQL Server-Konfigurationsoption MAXDOP (Max. Degree Of Parallelism, maximaler Grad an Parallelität) steuert die Anzahl von Prozessoren, die für die Ausführung einer Abfrage in einem parallelen Plan verwendet werden. Diese Option bestimmt die Computing- und Threadressourcen, die für die parallel arbeitenden Abfrageplanoperatoren verwendet werden. Je nachdem, ob SQL Server auf einem SMP-Computer (Symmetric Multiprocessing), einem NUMA-Computer (Non-Uniform Memory Access) oder Hyperthreading-fähigen Prozessoren eingerichtet ist, müssen Sie die Option max. Grad an Parallelität entsprechend konfigurieren.

Wenn SQL Server auf einem Computer mit mehreren Mikroprozessoren oder CPUs ausgeführt wird, wird für jede Ausführung paralleler Pläne der beste Grad an Parallelität ermittelt, also die Anzahl von Prozessoren, die zum Ausführen einer einzelnen Anweisung verwendet werden. Der Standardwert für diese Option lautet 0, sodass SQL Server den maximalen Grad an Parallelität bestimmen kann.

Die in Operations Manager vordefinierten gespeicherten Prozeduren und Abfragen, die sich auf die Betriebs-, Data Warehouse- und sogar Überwachungsdatenbank beziehen, enthalten nicht die MAXDOP-Option, da es während der Installation keine Möglichkeit gibt, dynamisch abzufragen, wie viele Prozessoren dem Betriebssystem angezeigt werden, noch wird versucht, den Wert für diese Einstellung festzucodieren, was negative Auswirkungen haben kann, wenn die Abfrage ausgeführt wird.

Hinweis

Die Konfigurationsoption max. Grad an Parallelität beschränkt nicht die Anzahl der Prozessoren, die vom SQL Server verwendet werden. Um die Anzahl der von SQL Server verwendeten Prozessoren zu konfigurieren, verwenden Sie die Konfigurationsoption „Affinitätsmaske“.

• Bei Servern, die mehr als acht Prozessoren verwenden, legen Sie die Konfiguration folgendermaßen fest: 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.