Überlegungen zum SQL Server-Entwurf

System Center Operations Manager basiert auf Microsoft SQL Server, um die Betriebs-, Data Warehouse- und ACS-Überwachungsdatenbanken zu unterstützen. Diese Datenbanken sind unerlässlich und werden während der Bereitstellung des ersten Verwaltungsservers oder ACS-Sammlers in Ihrer Verwaltungsgruppe erstellt.

In einer Laborumgebung oder einer kleinen Bereitstellung von Operations Manager kann SQL Server auf dem ersten Verwaltungsserver in der Verwaltungsgruppe zugeordnet werden.

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-Collectors starten.

Die Verwendung von Operations Manager-Datenbanken aus einer SQL-Instanz mit anderen Anwendungsdatenbanken wird nicht empfohlen, um potenzielle Probleme mit E/A und anderen Hardwareressourceneinschränkungen zu vermeiden.

Wichtig

Operations Manager unterstützt keine Platform as a Service (PaaS)-Instanzen von SQL, einschließlich Produkten wie Azure SQL Managed Instance 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 der verwalteten Azure Monitor SCOM-Instanz zu finden, die 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 von System Center Operations Manager unterstützt, um die Berichtsserver‑, Betriebs‑, Data Warehouse‑ und ACS-Datenbank zu hosten:

• SQL Server 2022 mit mindestens einem kumulativen Update 11 (CU11) oder höher wie hier verfügbar
• SQL Server 2019 mit mindestens einem kumulativen Update 8 (CU8) oder höher, wie hier verfügbar
• SQL Server 2017 mit dem neuesten verfügbaren Update wie hier verfügbar

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

SQL Server-Treiber

Die OLE DB - und ODBC-SQL Server-Treiber müssen auf allen Verwaltungsservern und dem Webkonsolenserver installiert werden, da diese Komponenten direkt mit den Datenbanken und diesen Treibern den Zugriff auf SQL auf API-Ebene ermöglichen.

Die empfohlenen Versionen für die Verwendung mit Operations Manager sind:

• Microsoft ODBC-Treiber , Version 17.10.6.
• Microsoft OLE DB-Treiber , Version 18.7.4.

Wenn Sie eine verschlüsselte SQL Server-Verbindung verwenden, müssen Sie stattdessen die neuesten Versionen des Treibers installieren:

• Neueste Version des Microsoft OLE DB-Treibers .
• Neueste Version des Microsoft ODBC-Treibers .

Weitere Informationen zum Konfigurieren der SQL-Verbindungsverschlüsselung finden Sie hier: Konfigurieren von SQL Server-Datenbank-Engine zum Verschlüsseln von Verbindungen

SQL Server-Updates

Jede der folgenden SQL Server-Komponenten, die eine Operations Manager-Infrastruktur unterstützen, muss sich in derselben SQL Server-Hauptversion befinden:

• SQL Server-Datenbankmodulinstanzen, die eine der Operations Manager-Datenbanken hosten, einschließlich:
  • OperationManager
  • OperationManagerDW
  • SSRS-Datenbanken ReportServer und ReportServerTempDB
• SQL Server Reporting Services-Instanz (SSRS)

SQL Server-Authentifizierungsmodus

Sql arbeitet standardmäßig in einer Authentifizierungskonfiguration für den gemischten Modus. Operations Manager verwendet jedoch nur Windows-Authentifizierung für die Kommunikation mit SQL Server. Wenn die Einstellung für die SQL Mixed Mode Authentication standardmäßig übrig bleibt, funktioniert dieS weiterhin, wenn kein lokales Konto über die db_owner Rolle verfügt. Lokale Konten mit der db_owner Rolle sind bekannt, um Probleme mit Operations Manager zu verursachen.

Es wird dringend empfohlen, die Rolle vor der db_owner Installation des Produkts aus allen lokalen Konten zu entfernen und die Rolle nach der db_owner Installation nicht zu lokalen Konten hinzuzufügen.

Andere Aspekte

Andere Hardware- und Softwareüberlegungen gelten für Ihre Entwurfsplanung:

• ES wird empfohlen, SQL-Datenträger im NTFS-Dateiformat zu verwenden.
• Sie müssen mindestens 1 GB freien Speicherplatz für die Betriebs- und Data Warehouse-Datenbank haben, dies wird zum Zeitpunkt der Datenbankerstellung erzwungen. Beachten Sie, dass die Datenträgerauslastung der Datenbanken nach dem Setup erheblich zunimmt, stellen Sie sicher, dass über dieser Basisanforderung ausreichend freier Speicherplatz vorhanden ist.
• .NET Framework 4 ist erforderlich.
• .NET Framework 4.8 wird ab Operations Manager 2022 unterstützt.
• Der Berichtsserver wird nicht auf Windows Server Core unterstützt.
• Die SQL Server-Sortiereinstellung muss einen der unterstützten Typen sein, wie im Abschnitt beschrieben: SQL Server-Sortiereinstellung.
• Sql Server Full Text Search ist für alle SQL Server-Datenbankmodulinstanzen erforderlich, die eine der Operations Manager-Datenbanken hosten.
• Die Windows Server-Installationsoptionen (Server Core, Server mit Desktopdarstellung und Nano Server), die von Operations Manager-Datenbankkomponenten unterstützt werden, basieren darauf, welche Installationsoptionen von SQL Server unterstützt werden.

Weitere Informationen finden Sie im Abschnitt "Hardware- und Softwareanforderungen" in der SQL Server-Installations- und Planungsdokumentation: Planen einer SQL Server-Installation

SQL Server-Sortierungseinstellung

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

Hinweis

Um Kompatibilitätsprobleme beim Vergleichen oder Kopieren von Vorgängen zu vermeiden, empfehlen wir Ihnen, für die SQL‑ und Operations Manager-Datenbank die gleiche Sortierung 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 die Durchführung eines neuen Setups der Operations Manager-Einrichtung fehl. Ein direktes Upgrade wird jedoch erfolgreich abgeschlossen.

Firewallkonfiguration

Operations Manager ist auf SQL Server angewiesen, um seine Datenbanken zu hosten, und auf eine Berichtsplattform, um historische Betriebsdaten zu analysieren und darzustellen. Die Rollen „Verwaltungsserver“, „Vorgänge“ und „Webkonsole“ müssen erfolgreich mit SQL Server kommunizieren können. Es ist wichtig, den Kommunikationspfad und die Ports zu verstehen, um Ihre Umgebung richtig zu konfigurieren.

Wenn Sie eine verteilte Bereitstellung entwerfen, die SQL AlwaysOn-Verfügbarkeitsgruppen verwendet, gibt es zusätzliche Firewallkonfigurationseinstellungen, die in Ihre Firewallsicherheitsstrategie einbezogen werden müssen.

In der folgenden Tabelle sind die Firewallports aufgeführt, die von SQL Server benötigt werden, damit Verwaltungsserver mit den Datenbanken kommunizieren können:

Szenario	Port	Direction	Operations Manager-Rolle
SQL Server, der Operations Manager-Datenbanken hostet	TCP 1433 *	Eingehend	Verwaltungsserver und Webkonsole (für Application Advisor und Anwendungsdiagnose)
SQL Server-Browserdienst	UDP 1434	Eingehend	Verwaltungsserver
SQL Server – dedizierte Adminverbindung	TCP 1434	Eingehend	Verwaltungsserver
Andere 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-Verfügbarkeitsgruppenlistener	Vom Admin konfigurierter Port	Eingehend	Verwaltungsserver
SQL Server Reporting Services hostet Operations Manager-Berichtsserver	TCP 80 (Standard)/443 (SSL)	Eingehend	Verwaltungsserver und Betriebskonsole

Hinweis

Während TCP 1433 der Standardport für die Standardinstanz des Datenbank-Engine ist, wenn Sie eine benannte Instanz auf einem eigenständigen SQL Server erstellen oder eine SQL AlwaysOn-Verfügbarkeitsgruppe bereitgestellt haben, wird ein benutzerdefinierter Port definiert und sollte referenziert werden, damit Sie Ihre Firewalls ordnungsgemäß konfigurieren und diese Informationen während des Setups eingeben.

Eine ausführlichere Übersicht über die Firewallanforderungen für SQL Server finden Sie unter Konfigurieren der Windows-Firewall für den SQL Server-Zugriff.

Überlegungen zu Daten 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öße und Konfiguration des Datenbankservers ist für die Gesamtleistung der Verwaltungsgruppe entscheidend. Die kritischste Ressource, die von der Operations Manager-Datenbank verwendet wird, ist das Speichersubsystem, aber CPU und RAM sind ebenfalls wichtig.

Zu den Faktoren, die die Auslastung der Operations Manager-Datenbank beeinflussen, gehören:

• Rate der betrieblichen Datensammlung.
  • Die Häufigkeit der Erfassung operativer Daten wird durch Faktoren wie die Anzahl der importierten Management Packs, die Anzahl der hinzugefügten Agents und den Typ des zu überwachenden Computers beeinflusst. Beispielsweise sammelt ein Agent, der einen unternehmenskritischen Desktopcomputer überwacht, weniger Daten im Vergleich zu einem Agent, der einen Server überwacht, auf dem SQL Server mit mehreren Datenbanken ausgeführt wird.
• Rate der Änderung des Instanzbereichs.
  • Das Aktualisieren vorhandener Daten in der Operations Manager-Datenbank ist im Vergleich zum Schreiben neuer Betriebsdaten ressourcenintensiv. Darüber hinaus müssen die Verwaltungsserver bei Änderungen an Instanzraumdaten weitere Abfragen an der Datenbank vornehmen, um Konfigurations- und Gruppenänderungen zu berechnen. Die Anzahl der Instanzenplatzänderungen nimmt zu, wenn neue Management Packs importiert oder neue Agents zur Verwaltungsgruppe hinzugefügt werden.
• Die Anzahl der Gleichzeitig ausgeführten Operations Consoles und andere SDK-Verbindungen wirkt sich auch auf die Auslastung der Datenbank aus.
  • Jede Betriebskonsole 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. Betriebskonsolen, die große Mengen an Betriebsdaten in der Ereignisansicht, der Statusansicht, der Warnungsansicht und der Leistungsdatenansicht anzeigen, verursachen in der Regel die größte Belastung der Datenbank.

Die Operations Manager-Datenbank ist eine einzige Fehlerquelle für die Verwaltungsgruppe, sodass sie mithilfe unterstützter Failover-Konfigurationen wie SQL Server-Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen hochverfü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 im Zusammenhang mit einer Aufgabe in System Center Operations Manager unerwartetes Verhalten beobachtet wird.

Um den SQL Server Service Broker zu aktivieren, führen Sie diese Schritte aus:

1. Führen Sie die folgende SQL-Abfrage aus, um zu überprüfen, ob der Broker bereits aktiviert ist, angegeben durch ein Ergebnis von 1 (eins) im is_broker_enabled Feld:

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

2. Wenn der wert, der is_broker_enabled im Feld angezeigt wird, 0 (null) ist, führen Sie die folgende SQL-Anweisung aus, um den Broker zu aktivieren:

   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

Hinweis

Das Operations Manager Data Warehouse wird in einigen Dokumentationen auch als "Reporting Data Warehouse"-Datenbank oder einfach "Data Warehouse" bezeichnet.

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

Zu den Faktoren, die die Last des Data Warehouse beeinflussen, gehören:

• Rate der betrieblichen Datensammlung.
  • Das Data Warehouse führt Berechnungen durch und speichert aggregierte Daten zusammen mit einer begrenzten Menge von Rohdaten, um eine effizientere Berichterstellung zu ermöglichen. Die Kosten für die Erfassung operativer Daten an das Data Warehouse sind daher im Vergleich zur Operations Manager-Datenbank etwas höher. Diese Kosten werden jedoch durch die reduzierten Verarbeitungskosten von Ermittlungsdaten im Data Warehouse im Vergleich zur Operations Manager-Datenbank ausgeglichen.
• Anzahl der gleichzeitigen Berichterstellungsbenutzenden oder der geplanten Berichtsgenerierung.
  • Jeder Berichterstellungsbenutzer kann eine erhebliche Belastung für das System hinzufügen, da Berichte häufig große Datenmengen zusammenfassen. Die Gesamtkapazitätsanforderungen werden durch die Anzahl der gleichzeitig ausgeführten Berichte und den Typ der ausgeführten Berichte beeinflusst. Berichte, die große Datumsbereiche oder große Anzahl von Objekten abfragen, erfordern zusätzliche Systemressourcen.

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

• Wählen Sie ein geeignetes Speichersubsystem aus.
  • Da das Data Warehouse ein integraler Bestandteil des gesamten Datenflusses über die Verwaltungsgruppe ist, ist die Auswahl eines geeigneten Speichersubsystems für das Data Warehouse wichtig. Wie bei der Operations Manager-Datenbank ist RAID 0 + 1 oft die beste Option. Im Allgemeinen sollte das Speichersubsystem für das 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 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 Option, wenn Sie die Anzahl der Agents skalieren. Wenn sich sowohl die Operations Manager-Datenbank als auch das 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 Data Warehouse ablegen, um alle Vorteile zu erhalten. Die Datendateien für die Operations Manager-Datenbank und das 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 Data Warehouse auf einem separaten Server von der Operations Manager-Datenbank zu platzieren.
  • Obwohl kleinere Bereitstellungen häufig die Operations Manager-Datenbank und das Data Warehouse auf demselben Server konsolidieren können, ist es vorteilhaft, sie zu trennen, wenn Sie die Anzahl der Agents und das Volumen eingehender Betriebsdaten skalieren. Wenn sich das 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 Always On-Verfügbarkeitsgruppen unterstützen Failover-Umgebunden für eine diskrete Gruppe von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jede Gruppe von Verfügbarkeitsdatenbanken wird in 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 nativen Reporting Services-Installation, die zwei Datenbanken verwendet, um den persistenten Datenspeicher von den Anforderungen an die temporäre Speicherung zu trennen, können in einer AlwaysOn-Verfügbarkeitsgruppe gehostet werden.

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

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

Tipp

Ab Operations Manager 2022 können Sie Operations Manager-Datenbanken mit einem vorhandenen SQL Always-On-Setup einrichten und aktualisieren, ohne dass Nachkonfigurationsänderungen erforderlich sind.

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

• Erfahren Sie mehr über Always On-Voraussetzungen.
• Erfahren Sie mehr über das Einrichten einer WSFC für Always On-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, zur Aktivierung von CLR Strict Security das SQL-Skript auf jeder Operations Manager-Datenbank aus.

Multisubnet-Zeichenfolge

Operations Manager unterstützt die Verbindungszeichenfolge Schlüsselwörter (MultiSubnetFailover=True). Da eine Verfügbarkeitsgruppe einen Listener-Namen (im WSFC-Cluster-Manager als Netzwerkname oder Clientzugriffspunkt bezeichnet) hat, der von mehreren IP-Adressen aus verschiedenen Subnetzen abhängt, wie etwa bei der Bereitstellung in einer standortübergreifenden Failover-Konfiguration, kommt es bei Clientverbindungsanfragen von Verwaltungsservern am Verfügbarkeitsgruppen-Listener zu einem Verbindungstimeout.

Der empfohlene Ansatz zur Umgehung dieser Einschränkung bei bereitgestellten Verfügbarkeitsgruppenserverknoten in einer Multi-Subnetz-Umgebung ist:

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-Datensatz verwendet wird.

Diese Einstellungen ermöglichen eine schnellere Wiederherstellung und Auflösung des Clusternamens mit der neuen IP-Adresse, wenn ein Failover zu einem Knoten in einem anderen Subnetz fehlschlägt.

Führen Sie die folgenden PowerShell-Befehle auf einem der SQL-Knoten aus, um diese 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.

Die folgenden PowerShell-Befehle können auf dem SQL-Knoten ausgeführt werden, 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 geclusterte oder eine Always On-SQL-Instanz für Hochverfügbarkeit verwendet wird, sollten Sie die automatische Wiederherstellungsfunktion auf Ihren Verwaltungsservern aktivieren, um zu vermeiden, dass der Operations Manager-Datenzugriffsdienst 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

Supporterfahrungen haben gezeigt, dass Leistungsprobleme in der Regel nicht durch eine hohe Ressourcenauslastung (d. h. Prozessor oder Arbeitsspeicher) mit SQL Server selbst verursacht werden; vielmehr bezieht sich das Problem direkt auf die Konfiguration des Speichersubsystems. Leistungsengpässe sind häufig darauf zurückzuführen, dass die empfohlenen Konfigurationsanweisungen für den für die SQL Server-Datenbankinstanz bereitgestellten Speicher nicht befolgt werden. Beispiele dafür sind:

• Unzureichende Zuweisung von Spindeln für die LUNs zur Unterstützung der E/A--Anforderungen von Operations Manager.
• Hosting von Transaktionsprotokollen und Datenbankdateien auf dem gleichen Volume. Diese beiden Workloads weisen unterschiedliche E/A- und Latenzmerkmale auf.
• Die Konfiguration von TempDB ist in Bezug auf Platzierung, Größe usw. falsch.
• Fehlausrichtung der Datenträgerpartition von Volumes, die die Datenbank-Transaktionsprotokolle, Datenbankdateien und TempDB hosten.
• Überblick über die grundlegende SQL Server-Konfiguration, wie etwa Verwendung von AUTOGROW für Datenbank- und Transaktionsprotokolldateien, MAXDOP-Einstellung für Abfrageparallelität, Erstellung mehrerer TempDB-Datendateien pro CPU-Kern usw.

Die Speicherkonfiguration ist eine der kritischen 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 umfasst 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 Durchsatztests des E/A-Subsystems ausgeführt werden, bevor SQL Server bereitgestellt wird. 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 – DiskSpd, PowerShell und Speicherleistung: Messen von IOPs, Durchsatz und Latenz für lokale Datenträger und SMB-Dateifreigaben.

Größe der NTFS-Zuordnungseinheiten

Die Volumenausrichtung, allgemein als Sektorausrichtung bezeichnet, sollte im Dateisystem (NTFS) durchgeführt werden, wenn ein Volumen auf einem RAID-Gerät erstellt wird. Wird dies nicht beachtet, kann dies zu einer erheblichen Leistungsbeeinträchtigung führen und ist in der Regel das Ergebnis einer Fehlausrichtung der Partition mit den Grenzen der Stripeeinheiten. Es kann auch zu einer Fehlausrichtung des Hardware-Caches führen, was eine ineffiziente Nutzung des Array-Caches zur Folge hat.

Beim Formatieren der Partition, die für SQL Server-Datendateien verwendet wird, empfiehlt es sich, eine 64-KB-Zuordnungseinheitsgröße (d. h. 65.536 Bytes) 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 Datenträgern, dies wird jedoch nicht empfohlen.

Reservierter Speicher

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 Speicher 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) zugewiesen werden müssen. Der von der Produktgruppe bereitgestellte Größenrechner bietet eine Orientierungshilfe auf der Grundlage des Workloads, aber seine Empfehlungen basieren auf Tests, die in einer Laborumgebung durchgeführt wurden und die möglicherweise nicht mit Ihrem tatsächlichen Workload und Ihrer tatsächlichen Konfiguration übereinstimmen.

SQL Server ermöglicht es Ihnen, den minimalen und maximalen Arbeitsspeicher zu konfigurieren, der von seinem Prozess reserviert und verwendet wird. Standardmäßig kann SQL Server seine Speicheranforderungen dynamisch basierend auf den verfügbaren Systemressourcen anpassen. Die Standardeinstellung für Min. Serverarbeitsspeicher ist 0, und die Standardeinstellung für Max. Serverarbeitsspeicher ist 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 dem System ausgeführt werden, wie etwa die HBA-Karte, Verwaltungsagenten und Echtzeit-Virenscans. Wenn nicht genügend Speicher vorhanden ist, werden das Betriebssystem und SQL auf der Festplatte eingeteilt. 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 durchgeführt werden, der eine der Operations Manager-Datenbanken hostet (operativ, Data Warehouse, ACS).

Für den maximalen Serverspeicher empfehlen wir, zunächst eine Gesamtmenge zu reservieren 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 Zähler Arbeitsspeicher\Verfügbare MB in Windows, um zu ermitteln, ob Sie den für SQL Server verfügbaren Speicher erhöhen können. Windows signalisiert, dass der verfügbare physische Arbeitsspeicher bei 96 MB niedrig ist, daher sollte der Zähler im Idealfall nicht unter 200-300 MB ausgeführt werden, um sicherzustellen, dass Sie über einen Puffer verfügen. Stellen Sie für Server mit 256 GB RAM oder höher sicher, dass sie nicht unter 1 GB ausgeführt wird.

Beachten Sie, dass diese Berechnungen davon ausgehen, dass SQL Server den gesamten verfügbaren Speicher verwendet, es sei denn, Sie führen Veränderungen durch, um andere Anwendungen zu berücksichtigen. Berücksichtigen Sie die spezifischen Speicheranforderungen für Ihr Betriebssystem, andere Anwendungen, den SQL Server-Thread-Stack und andere Multipage-Allokatoren. Eine typische Formel wäre ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)) mit dem 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 zum Zwischenspeichern von Daten im Pufferpool konzipiert ist und 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 Speicher verringern, können Sie einen Punkt erreichen, an dem ein geringerer Speicherzugriff für einen höheren Datenträger-E/A-Zugriff gehandelt wird.

Um den SQL Server-Speicher in einer überdimensionierten Umgebung zu konfigurieren, überwachen Sie zunächst die Umgebung und die aktuellen Leistungsmetriken, einschließlich der Lebensdauer der SQL Server-Puffermanagerseite und und der Werte für Seitenlesevorgänge/Sekundeund physische Datenträgerlesevorgänge/Sekunde. Wenn die Umgebung über ausreichend Arbeitsspeicher verfügt, erhöht das Caching die Seitenlebensdauer pro Sekunde um den Wert 1, ohne dass es bei hoher Arbeitsauslastung zu einem Abfall kommt. Der Wert für die Lesevorgänge pro Sekunde des SQL Server-Puffermanagers ist nach dem Start des Caches niedrig. Die physischen Festplattenlesungen pro Sekunde bleiben ebenfalls 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 Konfigurationsoptionen für den Serverarbeitsspeicher.

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 den 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 die 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 nötig, um die Festplattenbandbreite zu maximieren.
  • Die Verwendung mehrerer Dateien reduziert die TempDB-Speicherkonfliktion und bietet eine verbesserte Skalierbarkeit. Erstellen Sie jedoch nicht zu viele Dateien, da dies die Leistung verringern und den Verwaltungsaufwand erhöhen kann.
  • Als allgemeine Richtlinie gilt, dass Sie eine Datendatei für jeden logischen Prozessor auf dem Server erstellen (unter Berücksichtigung aller Affinitätsmaskeneinstellungen) und die Anzahl der Dateien dann nach 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 der logischen Prozessoren größer als 8 ist, verwenden Sie acht Datendateien und erhöhen Sie dann, falls die Konflikte weiterhin bestehen, die Anzahl der Datendateien um ein Vielfaches von 4 (bis zur Anzahl der logischen Prozessoren), bis die Konflikte auf ein akzeptables Maß reduziert sind, oder nehmen Sie Änderungen an der Arbeitslastauslastung oder am Code vor.
    • Wenn der Inhalt nicht reduziert wird, müssen Sie möglicherweise die Anzahl der Datendateien erhöhen.
• Stellen Sie sicher, dass alle Dateien dieselbe Größe haben, um eine optimale proportionale Füllleistung zu ermöglichen.
  • 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 Algorithmus für das proportionale Füllen, die größte Datei mehr für GAM-Zuweisungen zu verwenden, anstatt die Zuweisungen auf alle Dateien zu verteilen, wodurch der Zweck der Erstellung mehrerer Datendateien zunichte gemacht wird.
• Setzen Sie die TempDB-Datenbank auf ein schnelles E/A-Subsystem mit Festkörperlaufwerken für die optimale Leistung.
  • Verwenden Sie Datenträgerstriping, wenn viele Datenträger direkt angeschlossen sind.
• Legen Sie die tempdb-Datenbank auf anderen Datenträgern ab als denen, die von den Benutzerdatenbanken verwendet werden.

Zum Konfigurieren von TempDB können Sie die folgende Abfrage ausführen oder dessen 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 kann die Warteressource als "2:1:1" (PFS-Seite) oder "2:1:3" (Shared Global Allocation Map Page) angezeigt werden. Je nach Grad des Inhalts kann diese Einstellung dazu führen, dass SQL Server für kurze Zeiträume nicht reagiert. Ein weiterer Ansatz besteht darin, die dynamischen Verwaltungsansichten [sys.dm_exec_request or sys.dm_os_waiting_tasks] zu untersuchen. Die Ergebnisse zeigen, dass diese Anforderungen oder Aufgaben auf TempDB-Ressourcen warten und ähnliche Werte wie zuvor hervorgehoben haben, 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 das Ablaufverfolgungskennzeichnung -T1118 in den Startparametern für SQL Server, sodass das Ablaufverfolgungsflaggen auch nach dem Wiederverwenden von SQL Server wirksam bleibt. Unter dieser Ablaufverfolgungsflag weist SQL Server jedem Datenbankobjekt volle Ausmaße zu, wodurch der Inhalt auf SGAM-Seiten eliminiert wird.

Hinweis

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

Max. Grad an Parallelität

Tipp

Die neuesten bewährten Methoden und Empfehlungen des SQL Server-Teams finden Sie in ihrer Dokumentation hier: Festlegen des maximalen Grads der Parallelitätsoption für optimale Leistung

Die Standardkonfiguration von SQL Server für kleine bis mittlere Bereitstellungen von Operations Manager ist für die meisten Anforderungen geeignet. Wenn jedoch der Workload der Verwaltungsgruppe in Richtung eines Szenarios der Unternehmensklasse ansteigt (in der Regel mehr als 2.000 von Agents verwaltete Systeme und eine erweiterte Überwachungskonfiguration, die eine Überwachung auf Dienstebene mit erweiterten synthetischen Transaktionen, eine Überwachung von Netzwerkgeräten, plattformübergreifend usw. umfasst), ist es notwendig, die in diesem Abschnitt des Dokuments beschriebene Konfiguration von SQL Server zu optimieren. Eine Konfigurationsoption, die in früheren Anleitungen nicht erläutert wird, ist MAXDOP.

Die Konfigurationsoption „Max. Grad an Parallelität (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 Rechen‑ und Thread-Ressourcen, 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 Nichtuniform-Speicherzugriff (NUMA) 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 es für jede parallele Planausführung den besten Grad an Parallelität, das bedeutet die Anzahl der Prozessoren, die für die Ausführung einer einzelnen Anweisung verwendet werden. Standardmäßig ist der Wert für diese Option 0, wodurch SQL Server den maximalen Grad an Parallelität bestimmen kann.

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

Hinweis

Die Option „Max. Grad der Parallelitätskonfiguration“ beschränkt nicht die Anzahl der Prozessoren, die der SQL Server verwendet. Verwenden Sie die Konfigurationsoption „Affinitätsmaske“, um die Anzahl der Prozessoren zu konfigurieren, die SQL Server verwendet.

• 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

  Tipp

  In dieser Konfiguration N stellt die Anzahl der Prozessoren dar.

• Für Server, die NUMA konfiguriert haben, sollte MAXDOP die Anzahl der CPUs, die jedem NUMA-Knoten zugewiesen sind, nicht überschreiten.

• Für Server mit aktivierter Hyperthreading-Funktion sollte der MAXDOP-Wert die Anzahl der physischen Prozessoren nicht überschreiten.

• Für Server mit aktivierter NUMA-Konfiguration und Hyperthreading sollte der MAXDOP-Wert die Anzahl der physischen Prozessoren pro NUMA-Knoten nicht überschreiten.

Sie können die Anzahl der parallelen Worker überwachen, indem Sie abfragen select * from sys.dm_os_tasks.

In diesem Beispiel war die Hardwarekonfiguration des Servers ein HP Blade G6 mit 24 Kernprozessoren und 196 GB RAM. Die Instanz, in der die Operations Manager-Datenbank gehostet wird, hatte eine MAXMEM-Einstellung von 64 GB. Nachdem Sie die vorgeschlagenen Optimierungen in diesem Abschnitt durchgeführt haben, wurde die Leistung verbessert. Ein Abfrage-Parallelismus-Engpass bleibt jedoch weiterhin bestehen. Nach dem Testen verschiedener Werte wurde die optimale Leistung durch Festlegen von MAXDOP=4 gefunden.

Anfängliche Datenbankgröße

Es wird versucht, das zukünftige Wachstum der Operations Manager-Datenbanken, insbesondere der Operativen Und Data Warehouse-Datenbanken, innerhalb der ersten Monate nach der Bereitstellung nicht einfach zu schätzen. Während der Operations Manager Sizing Helper vernünftig ist, potenzielles Wachstum basierend auf der Formel zu schätzen, die von der Produktgruppe aus ihren Tests im Labor abgeleitet wurde, berücksichtigt er nicht mehrere Faktoren, die das Wachstum kurzfristig im Vergleich zu langfristig beeinflussen können.

Die anfängliche Datenbankgröße, wie vom Sizing Helper vorgeschlagen, sollte einer vorhergesagten Größe zugewiesen werden, um die Fragmentierung und den entsprechenden Aufwand zu reduzieren, der zur Einrichtungszeit für die Operational- und Data Warehouse-Datenbanken angegeben werden kann. Wenn während des Setups nicht genügend Speicherplatz verfügbar ist, können die Datenbanken später mithilfe von SQL Management Studio erweitert und anschließend erneut indiziert werden, um die Defragmentierung zu defragmentieren und entsprechend zu optimieren. Diese Empfehlung gilt auch für die ACS-Datenbank.

Die proaktive Überwachung des Wachstums der Operativen und Data Warehouse-Datenbank sollte täglich oder wöchentlich durchgeführt werden. Dies ist erforderlich, um unerwartete und signifikante Wachstumsspuren zu identifizieren und mit der Problembehandlung zu beginnen, um die Kausalität zu ermitteln, ob durch einen Fehler in einem Management Pack-Workflow (d. h. Ermittlungsregel, Leistungs- oder Ereignissammlungsregel) oder einem anderen Symptom mit einem Management Pack, das während der Test- und Qualitätssicherungsphase des Releaseverwaltungsprozesses nicht identifiziert wurde.

Datenbank automatisch wächst

Wenn die reservierte Datenbankdatei voll wird, kann SQL Server die Größe automatisch um einen Prozentsatz oder einen festen Betrag erhöhen. Darüber hinaus kann eine maximale Datenbankgröße konfiguriert werden, um zu verhindern, dass alle verfügbaren Speicherplatz auf dem Datenträger gefüllt werden. Standardmäßig ist die Operations Manager-Datenbank nicht mit aktivierter automatischer Vergrößerung konfiguriert. nur die Data Warehouse- und ACS-Datenbanken sind.

Verlassen Sie sich nur auf das automatische Wachstum als Notfall für unerwartetes Wachstum. AutoGrow führt zu einer Leistungsstrafe, die beim Umgang mit einer stark transaktionsalen Datenbank berücksichtigt werden sollte. Leistungsstrafen umfassen:

• Wenn Sie keinen geeigneten Wachstumsschritt bereitstellen, kann die Fragmentierung der Protokolldatei oder Datenbank auftreten.
• Wenn Sie eine Transaktion ausführen, die mehr Protokollspeicher benötigt, als verfügbar ist, und die automatische Vergrößerung für das Transaktionsprotokoll dieser Datenbank aktiviert ist, enthält die Zeit, die die Transaktion bis zum Abschluss benötigt, die Zeit, die das Transaktionsprotokoll benötigt, um den konfigurierten Betrag zu vergrößern.
• Wenn Sie eine große Transaktion ausführen, für die das Protokoll vergrößert werden muss, müssen andere Transaktionen, die einen Schreibvorgang in das Transaktionsprotokoll erfordern, auch warten, bis der Erweiterungsvorgang abgeschlossen ist.

Wenn die Optionen für automatisches Anwachsen und AutomatischesHrinken kombiniert werden, kann dies unnötigen Aufwand verursachen. Stellen Sie sicher, dass die Schwellenwerte, die die An- und Verkleinerungsvorgänge auslösen, keine häufigen Größenänderungen nach oben und unten verursachen. Sie können z. B. eine Transaktion ausführen, die bewirkt, dass das Transaktionsprotokoll um 100 MB um 100 MB vergrößert wird, wenn ein Commit ausgeführt wird; einige Zeit nach dem Starten und Verkleinern des Transaktionsprotokolls um 100 MB. Anschließend führen Sie dieselbe Transaktion aus, und das Transaktionsprotokoll wird erneut um 100 MB vergrößert. In diesem Beispiel erstellen Sie unnötigen Mehraufwand und erstellen möglicherweise Fragmentierung der Protokolldatei, die sich negativ auf die Leistung auswirken kann.

Konfigurieren Sie diese beiden Einstellungen sorgfältig. Die jeweilige Konfiguration hängt wirklich von Ihrer Umgebung ab. Die allgemeine Empfehlung besteht darin, die Datenbankgröße um einen festen Betrag zu erhöhen, um die Datenträgerfragmentierung zu verringern. Sehen Sie sich beispielsweise die folgende Abbildung an, in der die Datenbank so konfiguriert ist, dass sie bei jeder automatischen Vergrößerung um 1.024 MB vergrößert wird.

Clusterfailoverrichtlinie

Windows Server-Failoverclustering ist eine Hochverfügbarkeitsplattform, die die Netzwerkverbindungen und den Status der Knoten in einem Cluster ständig überwacht. Wenn ein Knoten nicht über das Netzwerk erreichbar ist, wird die Wiederherstellungsaktion ausgeführt, um Anwendungen und Dienste auf einem anderen Knoten im Cluster online zu stellen. Die standardmäßigen Einstellungen sind für Fehler optimiert, bei denen ein vollständiger Verlust eines Servers auftritt, der als "harter" Fehler gilt. Dies wäre nicht behebbare Fehlerszenarien, wie z. B. der Ausfall nichtredundanter Hardware oder Leistung. In diesen Situationen geht der Server verloren, und das Ziel besteht darin, Failoverclustering schnell den Verlust des Servers zu erkennen und schnell auf einem anderen Server im Cluster wiederherzustellen. Um diese schnelle Wiederherstellung von schwierigen Fehlern zu erreichen, sind die Standardeinstellungen für die Clusterintegritätsüberwachung ziemlich aggressiv. Sie sind jedoch vollständig konfigurierbar, um Flexibilität für verschiedene Szenarien zu ermöglichen.

Diese Standardeinstellungen bieten das beste Verhalten für die meisten Kunden. Da cluster jedoch von Zoll bis möglicherweise Meilen auseinander gestreckt werden, kann der Cluster mehr und potenziell unzuverlässige Netzwerkkomponenten zwischen den Knoten ausgesetzt werden. Ein weiterer Faktor ist, dass die Qualität der Rohstoffserver ständig steigt, gekoppelt mit erweiterter Resilienz durch redundante Komponenten (z. B. duale Stromversorgungen, NIC-Teaming und Mehrpfad-E/A), die Anzahl nichtredunder Hardwarefehler kann möglicherweise ziemlich selten sein. Da harte Fehler möglicherweise weniger häufig auftreten, möchten einige Kunden den Cluster möglicherweise auf vorübergehende Fehler optimieren, bei denen der Cluster stabiler für kurze Netzwerkfehler zwischen den Knoten ist. Indem Sie die Standardfehlerschwellenwerte erhöhen, können Sie die Empfindlichkeit für kurze Netzwerkprobleme verringern, die einen kurzen Zeitraum dauern.

Es ist wichtig zu verstehen, dass hier keine richtige Antwort vorhanden ist, und die optimierte Einstellung kann je nach Ihren spezifischen Geschäftsanforderungen und Vereinbarungen zum Servicelevel variieren.

Virtualisieren von SQL Server

In virtuellen Umgebungen wird aus Leistungsgründen empfohlen, die Betriebsdatenbank und die Data Warehouse-Datenbank in einem direkten angefügten Speicher und nicht auf einem virtuellen Datenträger zu speichern. Sie können das für Operations Manager 2012 veröffentlichte Hilfsprogramm zum Skalieren von Operations Manager 2012 verwenden, um die erforderlichen IOPS zu schätzen und Ihre Datenträger zu überprüfen. Die Speicherleistung kann mit dem DiskSpd-Dienstprogramm getestet werden. Weitere Anleitungen zur virtualisierten Operations Manager-Umgebung finden Sie unter Operations Manager-Virtualisierungsunterstützung .

AlwaysOn- und Wiederherstellungsmodell

Obwohl es sich nicht unbedingt um eine Optimierung handelt, ist eine wichtige Überlegung in Bezug auf Always On Availability Group die Tatsache, dass dieses Feature standardmäßig die Datenbanken im Wiederherstellungsmodell "Vollständig" festlegen muss. Die Transaktionsprotokolle werden also nie verworfen, bis entweder eine vollständige Sicherung oder nur das Transaktionsprotokoll abgeschlossen ist. Aus diesem Grund ist eine Sicherungsstrategie nicht optional, sondern ein erforderlicher Teil des AlwaysOn-Entwurfs für Operations Manager-Datenbanken. Andernfalls füllen Datenträger mit Transaktionsprotokollen mit Zeit aus.

Eine Sicherungsstrategie muss die Details Ihrer Umgebung berücksichtigen. In der folgenden Tabelle wird ein typischer Sicherungszeitplan angegeben.

Sicherungstyp	Zeitplan
Nur Transaktionsprotokoll	Alle eine Stunde
Vollständig	Wöchentlich, Sonntag um 3:00 Uhr

Optimieren von SQL Server Reporting Services

Die Reporting Services-Instanz fungiert als Proxy für den Zugriff auf Daten in der Data Warehouse-Datenbank. Sie generiert berichte basierend auf Vorlagen, die in den Management Packs gespeichert sind, und zeigt sie an.

Die Operations Manager-Berichterstellungsrolle 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).

Hinter den Kulissen von Reporting Services gibt es eine SQL Server-Datenbankinstanz, die die ReportServer- und ReportServerTempDB-Datenbanken hostt. Allgemeine Empfehlungen zur Leistungsoptimierung dieser Instanz gelten.

Hinweis

Ab SQL Server Reporting Services (SSRS) 2017 Version 14.0.600.1274 und höher erlauben die Standard-Sicherheitseinstellungen keine Uploads von Ressourcenerweiterungen. Dies führt zu ResourceFileFormatNotAllowedException Ausnahmen im Operations Manager während der Bereitstellung von Berichtskomponenten.

So beheben Sie dieses Problem:

1. Öffnen Sie SQL Management Studio.
2. Stellen Sie eine Verbindung mit Ihrer Reporting Services-Instanz her.
3. Klicken Sie im fenster Objekt-Explorer mit der rechten Maustaste auf die Serverinstanz.
4. Wählen Sie Eigenschaften aus.
5. Wählen Sie auf der linken Randleiste "Erweitert" aus.
6. Zur Liste für AllowedResourceExtensionsForUpload hinzufügen.*.*

Alternativ können Sie die vollständige Liste der Berichtserweiterungen von Operations Manager zur Zulassungsliste in SSRS hinzufügen. Die Liste wird hier in "Lösung 2" beschrieben: Operations Manager-Berichte können nicht bereitgestellt werden.

Nächste Schritte

Informationen zum Konfigurieren des Hostings des (Reporting) Data Warehouse hinter einer Firewall finden Sie unter Connect the (Reporting) Data Warehouse Across a Firewall.