Überlegungen zum SQL Server-Entwurf

System Center Operations Manager ist auf Microsoft SQL Server angewiesen, um seine Betriebs-, Data-Warehouse- und ACS-Audit-Datenbanken zu unterstützen. Diese Datenbanken sind essenziell und werden während der Bereitstellung des ersten Verwaltungsservers oder ACS-Sammlers in Ihrer Verwaltungsgruppe erstellt.

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

In einer mittelgroßen bis unternehmensweiten verteilten Bereitstellung sollte die SQL Server-Instanz auf einem dedizierten eigenständigen Server oder in einer SQL Server-Hochverfügbarkeitskonfiguration platziert werden. In jedem Fall muss SQL Server bereits vorhanden und zugänglich sein, bevor Sie die Installation des ersten Verwaltungsservers oder des ACS-Sammlers starten.

Wir empfehlen nicht, die Operations Manager-Datenbanken von einer SQL-Instanz zu nutzen, die auch andere Anwendungsdatenbanken enthält, um potenzielle Probleme mit I/O und anderen Hardware-Ressourcenbeschränkungen zu vermeiden.

SQL Server-Anforderungen

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

SQL Server-Treiber

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

Es wird empfohlen, eine verschlüsselte SQL Server-Verbindung zu nutzen; in diesem Fall müssen Sie die neuesten Versionen der SQL-Treiber installieren:

• Microsoft OLE DB-Treiber neueste Version.
• Microsoft ODBC-Treiber neueste Version.

Weitere Informationen zur Konfiguration der Verschlüsselung von SQL-Verbindungen finden Sie hier: Konfigurieren des SQL Server-Datenbankmoduls zur Verschlüsselung von Verbindungen

Wenn keine verschlüsselten SQL-Verbindungen genutzt werden, verwenden Sie frühere Versionen der SQL-Treiber, die keine Verschlüsselung erzwingen:

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

SQL Server-Updates

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

• SQL Server-Datenbank-Engine-Instanzen, 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

Standardmäßig arbeitet SQL in einer Mixed Mode-Authentifizierungskonfiguration. Allerdings verwendet der Operations Manager nur die Windows-Authentifizierung, um mit dem SQL Server zu kommunizieren. Wenn die Standardeinstellung beibehalten wird, funktioniert die SQL Mixed Mode-Authentifizierungseinstellung weiterhin, wenn kein lokales Konto die Rolle „db_owner“ hat. Lokale Konten mit der Rolle „db_owner“ sind dafür bekannt, Probleme mit dem Operations Manager zu verursachen.

Es wird dringend empfohlen, die Rolle db_owner von allen lokalen Konten zu entfernen, bevor Sie das Produkt installieren, und die Rolle db_owner nach der Installation keinem lokalen Konto hinzuzufügen.

Weitere Überlegungen

Andere Hardware- und Softwareüberlegungen sind in Ihrer Planungsphase zu berücksichtigen:

• Es wird empfohlen, SQL-Datenträger im NTFS-Dateiformat zu haben.
• Sie müssen mindestens 1 GB freien Speicherplatz für die Betriebs- und Data-Warehouse-Datenbank haben, dies wird bei der Erstellung der Datenbank erzwungen. Beachten Sie, dass die Festplattenauslastung der Datenbanken nach der Einrichtung erheblich zunimmt. Stellen Sie sicher, dass Sie ausreichend freien Speicherplatz über diesen Grundanforderungen hinaus haben.
• .NET Framework 4 ist erforderlich.
• .NET Framework 4.8 wird ab Operations Manager 2022 unterstützt.
• Der Berichtsserver wird auf Windows Server Core nicht unterstützt.
• Die SQL Server-Kollationseinstellung muss eine der unterstützten Typen sein, wie im Abschnitt beschrieben: SQL Server-Kollationseinstellung.
• SQL Server Volltextsuche ist für alle SQL Server-Datenbank-Engine-Instanzen erforderlich, die eine der Operations Manager-Datenbanken hosten.
• Die von den Operations Manager-Datenbankkomponenten unterstützten Windows Server-Installationsoptionen (Server Core, Server mit Desktopdarstellung und Nano Server) basieren darauf, welche Installationsoptionen von SQL Server unterstützt werden.

Weitere Informationen finden Sie im Abschnitt Hardware- & Softwareanforderungen in der SQL Server-Installations- und Planungsdokumentation hier: Eine SQL Server-Installation planen

SQL Server-Kollationseinstellung

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

SQL Server-Sortierung

• SQL_Latin1_General_CP1_CI_AS

Windows-Sortierung

• Latin1_General_100_CI_AS
• French_CI_AS
• Französisch_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinesisch_Vereinfacht_Pinyin_100_CI_AS
• Chinesisch_Traditionell_Strichanzahl_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanisch_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Ungarisch_100_CI_AS
• Polnisch_100_CI_AS
• Finnisch_Schwedisch_100_CI_AS

Wenn Ihre SQL Server-Instanz nicht mit einer der zuvor aufgeführten unterstützten Sortierungen konfiguriert ist, schlägt die neue Einrichtung von Operations Manager fehl. Ein In-Place-Upgrade wird jedoch erfolgreich abgeschlossen.

Firewallkonfiguration

Der Operations Manager ist auf SQL Server angewiesen, um seine Datenbanken zu hosten, und auf eine Berichtsplattform, um historische Betriebsdaten zu analysieren und darzustellen. Die Verwaltungsserver-, Operations- und Webkonsolenrollen müssen erfolgreich mit dem SQL Server kommunizieren können. Es ist wichtig, den Kommunikationspfad und die Ports zu verstehen, um Ihre Umgebung korrekt zu konfigurieren.

Wenn Sie eine verteilte Bereitstellung entwerfen, die SQL Always On-Verfügbarkeitsgruppen verwendet, müssen zusätzliche Firewall-Konfigurationseinstellungen in Ihre Firewall-Sicherheitsstrategie aufgenommen werden.

Die folgende Tabelle identifiziert die von SQL Server benötigten Firewall-Ports, damit Verwaltungsserver mit den Datenbanken kommunizieren können:

Für einen detaillierteren Überblick über die Firewall-Anforderungen für SQL Server, siehe Konfigurieren der Windows-Firewall für den SQL Server-Zugriff.

Kapazitäts- und Speicherüberlegungen

Operations-Manager-Datenbank

Die Operations Manager-Datenbank ist eine SQL Server-Datenbank, die alle Daten enthält, die der Operations Manager für die tägliche Überwachung benötigt. Die Dimensionierung und Konfiguration des Datenbankservers ist entscheidend für die Gesamtleistung der Verwaltungsgruppe. Die wichtigste Ressource, die von der Operations Manager-Datenbank verwendet wird, ist das Speichersubsystem, aber auch CPU und RAM sind bedeutend.

Faktoren, die die Last auf der Operations Manager-Datenbank beeinflussen, umfassen:

• Rate der Erfassung von Betriebsdaten
  • Die Rate der Erfassung von Betriebsdaten wird durch Faktoren wie die Anzahl der importierten Management Packs, die Anzahl der hinzugefügten Agents und die Art des überwachten Computers beeinflusst. Zum Beispiel sammelt ein Agent, der einen geschäftskritischen Desktop-Computer überwacht, weniger Daten im Vergleich zu einem Agenten, der einen Server mit SQL Server und mehreren Datenbanken überwacht.
• Rate der Instanzraumänderungen
  • Das Aktualisieren vorhandener Daten in der Operations Manager-Datenbank ist ressourcenintensiver im Vergleich zum Schreiben neuer Betriebsdaten. Außerdem müssen die Verwaltungsserver bei Änderungen der Instanzdaten mehr Abfragen an die Datenbank stellen, um Konfigurations- und Gruppenänderungen zu berechnen. Die Rate der Instanzraumänderungen erhöht sich, wenn neue Management Packs importiert oder neue Agents zur Managementgruppe hinzugefügt werden.
• Die Anzahl der gleichzeitig laufenden Operationskonsolen und anderer SDK-Verbindungen beeinflusst ebenfalls die Belastung der Datenbank.
  • Jede Operationskonsole liest Daten aus der Operations Manager-Datenbank. Das Abfragen dieser Daten verbraucht potenziell große Mengen an Speicher-I/O-Ressourcen, CPU-Zeit und RAM. Operationskonsolen, die große Mengen an Betriebsdaten in der Ereignisansicht, Zustandsansicht, Warnungsansicht und Leistungsdatenansicht anzeigen, neigen dazu, die größte Belastung auf die Datenbank zu verursachen.

Die Operations Manager-Datenbank ist eine einzelne Fehlerquelle für die Verwaltungsgruppe, daher kann sie durch unterstützte Failover-Konfigurationen wie SQL Server Always On-Verfügbarkeitsgruppen oder Failover-Clusterinstanzen hochverfügbar gemacht werden.

Aktivieren des SQL-Brokers in der Operations Manager-Datenbank

System Center Operations Manager hängt von SQL Server Service Broker ab, um alle Aufgabenoperationen auszuführen. Wenn der SQL Server Service Broker deaktiviert ist, sind alle Aufgabenoperationen betroffen. Das resultierende Verhalten kann je nach der initiierten Aufgabe variieren. Daher ist es wichtig, den Zustand des SQL Server Service Broker zu überprüfen, wann immer unerwartetes Verhalten bei einer Aufgabe im System Center Operations Manager beobachtet wird.

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

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

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

2. Wenn der Wert, der im Feld is_broker_enabled 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

System Center - Operations Manager fügt Daten nahezu in Echtzeit in das Data Warehouse ein. Es ist wichtig, dass dieser Server über ausreichende Kapazität verfügt, um das Schreiben aller gesammelten Daten in das Data Warehouse zu unterstützen. Wie bei der Operations Manager-Datenbank ist das kritischste Element im Data Warehouse das Speicher-I/O-Subsystem. In den meisten Systemen sind die Lasten auf dem Data Warehouse ähnlich wie bei der Operations Manager-Datenbank, können jedoch variieren. Darüber hinaus unterscheidet sich die Arbeitslast, die durch Berichterstellung auf das Data Warehouse gelegt wird, von der Last, die durch die Nutzung der Operations-Konsole auf die Operations Manager-Datenbank gelegt wird.

Faktoren, die die Last auf dem Data Warehouse beeinflussen, umfassen:

• Rate der Erfassung von Betriebsdaten
  • Das Data Warehouse führt Berechnungen durch und speichert aggregierte Daten sowie eine begrenzte Menge an Rohdaten, um effizientere Berichterstattung zu ermöglichen. Infolgedessen sind die Kosten für das Sammeln von Betriebsdaten in das Data Warehouse etwas höher im Vergleich zur Operations Manager-Datenbank. Diese Kosten werden jedoch durch die reduzierten Verarbeitungskosten von Discovery-Daten im Data Warehouse im Vergleich zur Operations Manager-Datenbank ausgeglichen.
• Anzahl gleichzeitiger Berichtsnutzer oder geplante Berichtserstellung
  • Jeder Berichtsnutzer kann eine erhebliche Belastung für das System darstellen, da Berichte häufig große Datenmengen zusammenfassen. Die Gesamtanforderungen an die Kapazität werden durch die Anzahl der gleichzeitig ausgeführten Berichte und die Art der Berichte beeinflusst. Berichte, die große Datumsbereiche oder eine große Anzahl von Objekten abfragen, erfordern zusätzliche Systemressourcen.

Basierend auf diesen Faktoren gibt es mehrere empfohlene Praktiken, die bei der Dimensionierung des Data Warehouse berücksichtigt werden sollten:

• Auswahl eines geeigneten Speichersubsystems
  • Da das Data Warehouse ein integraler Bestandteil des gesamten Datenflusses durch die Managementgruppe ist, ist die Wahl eines geeigneten Speichersubsystems für das 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 Data Warehouse dem Speichersubsystem für die Operations Manager-Datenbank ähneln, und die Richtlinien, 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.
  • Was die Operations Manager-Datenbank betrifft, ist es oft eine geeignete Wahl, SQL-Daten und Transaktionsprotokolle zu trennen, wenn Sie die Anzahl der Agents erhöhen. Wenn sich sowohl die Operations Manager-Datenbank als auch das Data Warehouse auf demselben Server befinden und Sie die Daten- und Transaktionsprotokolle trennen möchten, müssen Sie die Transaktionsprotokolle für die Operations Manager-Datenbank auf einem separaten physischen Volume und anderen Festplatten-Spindeln als das Data Warehouse platzieren, um einen Nutzen zu erzielen. Die Datendateien für die Operations Manager-Datenbank und das Data Warehouse können dasselbe physische Volume nutzen, solange das Volume ausreichende Kapazität bietet und die Festplatten-I/O-Leistung die Überwachungs- und Berichterstattungsfunktionen nicht negativ beeinflusst.
• Erwägen Sie, das Data Warehouse auf einem separaten Server von der Operations Manager-Datenbank zu platzieren.
  • Obwohl kleinere Bereitstellungen oft die Operations Manager-Datenbank und das Data Warehouse auf demselben Server konsolidieren können, ist es vorteilhaft, diese zu trennen, wenn Sie die Anzahl der Agents und das Volumen der eingehenden Betriebsdaten erhöhen. Wenn das Data Warehouse und der Reporting-Server auf einem separaten Server von der Operations Manager-Datenbank sind, erleben Sie eine bessere Berichtsleistung.

Die Operations Manager Data Warehouse-Datenbank ist eine einzelne Fehlerquelle für die Managementgruppe, daher kann sie mit unterstützten Failover-Konfigurationen wie SQL Server Always On-Verfügbarkeitsgruppen oder Failover-Clusterinstanzen hochverfügbar gemacht werden.

SQL Server Always On

SQL Server Always On-Verfügbarkeitsgruppen unterstützen Failover-Umgebungen für eine diskrete Gruppe von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jedes Set von Verfügbarkeitsdatenbanken wird auf einer Verfügbarkeitsreplik gehostet.

Mit System Center 2016 und später – Operations Manager, wird SQL Always On gegenüber Failover-Clustering bevorzugt, um hohe Verfügbarkeit für Datenbanken bereitzustellen. Alle Datenbanken, außer der native Mode Reporting Services-Installation, die zwei Datenbanken verwendet, um die dauerhafte Datenspeicherung von den temporären Speicheranforderungen zu trennen, können in einer AlwaysOn-Verfügbarkeitsgruppe gehostet werden.

Um eine Verfügbarkeitsgruppe einzurichten, stellen Sie einen Windows Server Failover Clustering (WSFC)-Cluster bereit, um die Verfügbarkeitsreplik zu hosten, und aktivieren Sie Always On auf den Clusterknoten. Sie können dann die Operations Manager SQL Server-Datenbank 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.

Multisubnetzzeichenfolge

Operations Manager unterstützt die Schlüsselwörter der Verbindungszeichenfolge („MultiSubnetFailover=True“) nicht. Da eine Verfügbarkeitsgruppe einen Listener-Namen (bekannt als Netzwerkname oder Clientzugriffspunkt im WSFC-Cluster-Manager) hat, der von mehreren IP-Adressen aus verschiedenen Subnetzen abhängt, wie es bei einer Bereitstellung in einer standortübergreifenden Failover-Konfiguration der Fall ist, werden Client-Verbindungsanfragen von Verwaltungsservern an den Listener der Verfügbarkeitsgruppe auf einen Verbindungs-Timeout stoßen.

Der empfohlene Ansatz, um diese Einschränkung bei bereitgestellten Verfügbarkeitsgruppen-Serverknoten in einer Multi-Subnetz-Umgebung zu umgehen, besteht darin:

1. Festlegen des Netzwerknamens Ihres Verfügbarkeitsgruppen-Listeners, um nur eine aktive IP-Adresse im DNS zu registrieren.
2. Konfigurieren Sie den Cluster so, dass er einen niedrigen TTL-Wert für den registrierten DNS-Eintrag verwendet.

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 erfolgt.

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 Listener-Namen verwenden, sollten Sie diese Konfigurationsänderungen auch am Listener vornehmen. Weitere Informationen zur Konfiguration eines Verfügbarkeitsgruppen-Listeners finden Sie in der Dokumentation hier: Verfügbarkeitsgruppen-Listener konfigurieren – SQL Server Always On.

Die folgenden PowerShell-Befehle können auf dem SQL-Knoten ausgeführt werden, der derzeit den Listener hostet, 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 SQL-Instanz im Cluster oder Always On für Hochverfügbarkeit verwendet wird, sollten Sie die automatische Wiederherstellungsfunktion auf Ihren Verwaltungsservern aktivieren, um zu vermeiden, dass der Operations Manager Data Access-Dienst bei einem 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 gegangen ist.

SQL Server optimieren

Support-Erfahrungen haben gezeigt, dass Leistungsprobleme in der Regel nicht durch eine hohe Ressourcenauslastung (also Prozessor oder Speicher) von SQL Server selbst verursacht werden; vielmehr hängt das Problem direkt mit der Konfiguration des Speichersubsystems zusammen. Leistungsengpässe werden häufig darauf zurückgeführt, dass die empfohlene Konfigurationsrichtlinie für den bereitgestellten Speicher der SQL Server-Datenbankinstanz nicht befolgt wird. Solche Beispiele sind:

• Unzureichende Zuweisung von Spindeln für die LUNs zur Unterstützung der IO-Anforderungen des Operations Manager.
• Speichern von Transaktionsprotokollen und Datenbankdateien auf demselben Volume Diese beiden Workloads haben unterschiedliche IO- und Latenzcharakteristiken.
• Die Konfiguration von TempDB ist in Bezug auf Platzierung, Größe usw. nicht korrekt.
• Fehlausrichtung der Datenträgerpartition von Volumes, die die Datenbank-Transaktionsprotokolle, Datenbankdateien und TempDB hosten
• Übersehen der grundlegenden SQL Server-Konfiguration wie die Verwendung von AUTOGROW für Datenbank- und Transaktionsprotokolldateien, die MAXDOP-Einstellung für Abfrageparallelität, das Erstellen mehrerer TempDB-Datendateien pro CPU-Kern und so weiter.

Die Speicher-Konfiguration ist eine der kritischen Komponenten für eine SQL Server-Bereitstellung für Operations Manager. Datenbankserver neigen dazu, stark I/O-gebunden zu sein, aufgrund der intensiven Lese- und Schreibaktivitäten der Datenbank sowie der Verarbeitung von Transaktionsprotokollen. Das I/O-Verhaltensmuster des Operations Manager besteht typischerweise zu 80 % aus Schreibvorgängen und zu 20 % aus Lesevorgängen. Infolgedessen kann eine unsachgemäße Konfiguration der I/O-Subsysteme zu einer schlechten Leistung und einem schlechten Betrieb der SQL Server-Systeme führen und wird im Operations Manager bemerkbar.

Es ist wichtig, das SQL Server-Design zu testen, indem Sie einen Durchsatztest des IO-Subsystems durchführen, bevor Sie SQL Server bereitstellen. Stellen Sie sicher, dass diese Tests Ihre IO-Anforderungen mit einer akzeptablen Latenz erfüllen können. Verwenden Sie das Diskspd-Dienstprogramm, um die I/O-Kapazität des das SQL Server unterstützenden Speichersubsystems zu bewerten. Der folgende Blogartikel, verfasst von einem Mitglied des File Server-Teams in der Produktgruppe, bietet detaillierte Anleitungen und Empfehlungen zur Durchführung von Stresstests mit diesem Tool – „DiskSpd, PowerShell und Speicherleistung: Messung von IOPs, Durchsatz und Latenz für sowohl lokale Festplatten als auch SMB-Dateifreigaben“.

NTFS-Zuordnungseinheitengröße

Volumenausrichtung, auch als Sektorausrichtung bezeichnet, sollte auf dem Dateisystem (NTFS) durchgeführt werden, wann immer ein Volume auf einem RAID-Gerät erstellt wird. Das Versäumnis, dies zu tun, kann zu einer erheblichen Verschlechterung der Leistung führen und ist meist das Ergebnis einer Fehlanpassung der Partition an die Grenzen der Stripe-Einheit. Es kann auch zu einer Fehlanpassung des Hardware-Caches führen, was zu einer ineffizienten Nutzung des Array-Caches führt.

Bei der Formatierung der Partition, die für SQL Server-Datendateien verwendet wird, wird empfohlen, eine Zuordnungseinheitengröße von 64 KB (das sind 65.536 Bytes) für Daten, Protokolle und TempDB zu verwenden. Seien Sie sich jedoch bewusst, dass die Verwendung von Zuordnungseinheitsgrößen, 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.

Speicher reservieren

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

SQL Server ermöglicht es Ihnen, den minimalen und maximalen Speicherbetrag zu konfigurieren, der für seinen Prozess reserviert und genutzt wird. Standardmäßig kann SQL Server seine Speicheranforderungen dynamisch basierend auf den verfügbaren Systemressourcen ändern. Die Standardeinstellung für Min. Serverarbeitsspeicher ist 0, die für Max. Serverarbeitsspeicher 2147483647 MB.

Leistungs- und speicherbezogene Probleme können auftreten, wenn Sie keinen geeigneten Wert für „maximalen Serverspeicher“ festlegen. Viele Faktoren beeinflussen, wie viel Speicher Sie dem SQL Server zuweisen müssen, um sicherzustellen, dass das Betriebssystem andere auf diesem System laufende Prozesse wie die HBA-Karte, Management-Agenten und die Echtzeit-Virensuche unterstützen kann. Wenn nicht genügend Speicher zugewiesen wird, wird das Betriebssystem und SQL auf die Festplatte auslagern. Dies kann dazu führen, dass die Festplatten-I/O zunimmt, was die Leistung weiter verringert und einen Welleneffekt erzeugt, der im Operations Manager bemerkbar wird.

Wir empfehlen, mindestens 4 GB RAM für „minimale Server-Speicher“ anzugeben. Dies sollte für jeden SQL-Knoten durchgeführt werden, der eine der Operations Manager-Datenbanken (operational, data warehouse, ACS) hostet.

Für „maximalen Serverspeicher“ empfehlen wir, dass Sie zunächst insgesamt reservieren:

• 1 GB RAM für das Betriebssystem
• 1 GB RAM pro 4 GB installierten RAM (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 „Memory\Available MBytes“ in Windows, um festzustellen, ob Sie den SQL Server verfügbaren Speicher erhöhen können. Windows signalisiert, dass der verfügbare physische Speicher bei 96 MB knapp wird. Idealerweise sollte der Zähler nicht unter etwa 200–300 MB fallen, um sicherzustellen, dass Sie einen Puffer haben. Für Server mit 256 GB RAM oder mehr stellen Sie sicher, dass er nicht unter 1 GB fällt.

Beachten Sie, dass diese Berechnungen davon ausgehen, dass Sie möchten, dass SQL Server den gesamten verfügbaren Speicher nutzen kann, es sei denn, Sie ändern sie, 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 Mehrseiten-Allocatoren. 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 den Thread-Stack „((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. Den Wert für die maximalen Arbeitsthreads finden Sie in der Spalte max_worker_count von sys.dm_os_sys_info.

Diese Überlegungen gelten auch für die Speicheranforderungen, damit SQL Server in einer virtuellen Maschine ausgeführt werden kann. Da SQL Server so konzipiert ist, dass er Daten im Pufferpool zwischenspeichert und so viel Speicher wie möglich nutzt, kann es schwierig sein, die ideale Menge an benötigtem RAM zu bestimmen. Wenn Sie den dem SQL Server-Instanz zugewiesenen Speicher reduzieren, können Sie einen Punkt erreichen, an dem eine geringere Speicherzuweisung gegen einen höheren Festplatten-I/O-Zugriff eingetauscht wird.

Um den Arbeitsspeicher von SQL Server in einer überprovisionierten Umgebung zu konfigurieren, beginnen Sie mit der Überwachung der Umgebung und der aktuellen Leistungskennzahlen, einschließlich des SQL Server-Puffermanagers „Seitenlebensdauer“ sowie „Seitenlesevorgänge/Sekunde“ und der Werte für „Festplattenlesevorgänge/Sekunde“ der physischen Festplatte. Wenn die Umgebung über überschüssigen Speicher verfügt, erhöht sich die Page Life Expectancy um einen Wert von eins pro Sekunde, ohne dass es unter der Arbeitslast zu einem Rückgang kommt, aufgrund des Cachings; der Wert der Page Reads/Sek. des SQL Server Buffer Managers wird niedrig sein, nachdem der Cache hochgefahren ist; und die Disk Reads/Sek. der physischen Festplatte werden ebenfalls niedrig bleiben.

Sobald Sie die Umgebungsbasislinie verstanden haben, können Sie die „maximale Serverspeicher“ um 1 GB reduzieren und dann beobachten, wie sich das auf Ihre Leistungsindikatoren auswirkt (nachdem das anfängliche Cache-Leeren abgeklungen ist). Wenn die Metriken akzeptabel bleiben, reduzieren Sie um weitere 1 GB und überwachen Sie erneut. Wiederholen Sie diesen Vorgang nach Bedarf, bis Sie eine ideale Konfiguration ermittelt haben.

Weitere Informationen finden Sie unter Server-Speicher-Konfigurationsoptionen.

Optimieren von TempDB

Die Größe und die physische Platzierung der TempDB-Datenbank können die Leistung des Operations Manager beeinflussen. Wenn die für TempDB definierte Größe beispielsweise zu klein ist, kann ein Teil der Systemverarbeitungslast damit verbraucht werden, TempDB bei jedem Neustart der SQL Server-Instanz auf die erforderliche Größe zu erweitern, um die Arbeitslast zu unterstützen. Um eine optimale Leistung von TempDB zu erreichen, empfehlen wir die folgende Konfiguration für TempDB in einer Produktionsumgebung:

• Setzen Sie das Wiederherstellungsmodell von TempDB auf SIMPLE.
  • Dieses Modell beansprucht automatisch Speicherplatz für Protokolle zurück, um die Speicheranforderungen gering 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 die Leistung beeinträchtigen kann. Die TempDB-Datenbank kann auf automatisches Wachstum eingestellt werden, aber dies sollte verwendet werden, um den 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 verringert die Speicherplatzkontention in TempDB und führt zu verbesserter Skalierbarkeit. Erstellen Sie jedoch nicht zu viele Dateien, da dies die Leistung verringern und den Verwaltungsaufwand erhöhen kann.
  • Als allgemeine Richtlinie erstellen Sie eine Datendatei für jeden logischen Prozessor auf dem Server (unter Berücksichtigung der Einstellungen der Affinitätsmaske) und passen Sie dann die Anzahl der Dateien nach Bedarf 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. Wenn die Konflikte weiterhin bestehen, erhöhen Sie die Anzahl der Datendateien in Vielfachen von 4 (bis zur Anzahl der logischen Prozessoren), bis die Konflikte auf ein akzeptables Niveau reduziert sind oder ändern Sie die Arbeitslast/den Code.
    • Wenn die Konkurrenz nicht verringert wird, müssen Sie möglicherweise die Anzahl der Datendateien weiter erhöhen.
• Machen Sie jede Datendatei gleich groß, um eine optimale Proportional-Fill-Leistung zu ermöglichen.
  • Die gleichmäßige Größe der Datendateien ist entscheidend, da der proportionale Füllalgorithmus auf der Größe der Dateien basiert. Wenn Daten-Dateien mit ungleichen Größen erstellt werden, versucht der proportionale Füllalgorithmus, 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 Daten-Dateien zunichte gemacht wird.
• Platzieren Sie die TempDB-Datenbank auf einem schnellen I/O-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ägern ab als denen, die von den Benutzerdatenbanken verwendet werden.

Um TempDB zu konfigurieren, können Sie die folgende Abfrage ausführen oder die Eigenschaften im 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 die Seitenzuweisungsengpässe für die TempDB-Datenbank zu erkennen. In der Systemtabelaussgabe kann die Warte-Ressource als „2:1:1“ (PFS-Seite) oder „2:1:3“ (Shared Global Allocation Map-Seite) erscheinen. Abhängig vom Grad der Konkurrenz kann diese Einstellung dazu führen, dass der SQL Server für kurze Zeiträume nicht reagiert. Ein weiterer Ansatz besteht darin, die Dynamic Management Views [sys.dm_exec_request oder sys.dm_os_waiting_tasks] zu untersuchen. Die Ergebnisse zeigen, dass diese Anfragen 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 Zuweisungskonflikte nicht signifikant reduzieren und die Konflikte auf SGAM-Seiten auftreten, implementieren Sie das Trace-Flag-T1118 in den Startparametern für SQL Server, damit das Trace-Flag auch nach einem Neustart von SQL Server wirksam bleibt. Unter diesem Trace-Flag weist SQL Server jedem Datenbankobjekt vollständige Extents zu, wodurch die Konkurrenz auf SGAM-Seiten beseitigt wird.

Maximale Parallelitätsgrad

Die Standardkonfiguration von SQL Server für kleine bis mittlere Bereitstellungen von Operations Manager ist für die meisten Anforderungen ausreichend. Wenn jedoch die Arbeitslast der Verwaltungsgruppe in Richtung eines Unternehmensszenarios skaliert (typischerweise 2.000+ agentenverwaltete Systeme und eine erweiterte Überwachungskonfiguration, die Service-Level-Überwachung mit erweiterten synthetischen Transaktionen, Netzwerkgeräteüberwachung, plattformübergreifend usw. umfasst), ist es notwendig, die Konfiguration von SQL Server zu optimieren, wie in diesem Abschnitt des Dokuments beschrieben. Eine Konfigurationsoption, die in den vorherigen Anleitungen nicht besprochen wurde, ist MAXDOP.

Die Konfigurationsoption „max degree of parallelism (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 Ausführungsplanoperatoren verwendet werden, die die Arbeit parallel ausführen. Je nachdem, ob SQL Server auf einem symmetrischen Multiprocessing-Computer (SMP), einem Computer mit nicht-uniformem Speicherzugriff (NUMA) oder Prozessoren mit Hyperthreading aktiviert ist, müssen Sie die Option für den maximalen Grad an Parallelität entsprechend konfigurieren.

Wenn SQL Server auf einem Computer mit mehr als einem Mikroprozessor oder CPU läuft, erkennt er den besten Grad an Parallelität, das heißt, die Anzahl der Prozessoren, die zur Ausführung einer einzelnen Anweisung verwendet werden, für jede parallele Plan-Ausführung. Standardmäßig ist der Wert für diese Option 0, was es SQL Server ermöglicht, den maximalen Grad der Parallelität zu bestimmen.

Die in Operations Manager vordefinierten gespeicherten Prozeduren und Abfragen in Bezug auf die Betriebs-, Data-Warehouse- und sogar Audit-Datenbank enthalten nicht die MAXDOP-Option, da es während der Installation keine Möglichkeit gibt, dynamisch abzufragen, wie viele Prozessoren dem Betriebssystem zur Verfügung stehen. Außerdem wird nicht versucht, den Wert für diese Einstellung fest zu kodieren, was negative Folgen haben könnte, wenn die Abfrage ausgeführt wird.

• Für Server, die mehr als acht Prozessoren verwenden, verwenden Sie die folgende Konfiguration: MAXDOP=8

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

  Tipp

  In dieser Konfiguration steht N für die Anzahl der Prozessoren.

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

• Für Server, bei denen Hyperthreading aktiviert ist, sollte der MAXDOP-Wert die Anzahl der physischen Prozessoren nicht überschreiten.

• Für Server, die mit NUMA konfiguriert sind und bei denen Hyperthreading aktiviert ist, 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 „select * from sys.dm_os_tasks“ abfragen.

In diesem Beispiel war die Hardwarekonfiguration des Servers ein HP Blade G6 mit 24-Kern-Prozessoren und 196 GB RAM. Die Instanz, die die Operations Manager-Datenbank hostet, hatte eine MAXMEM-Einstellung von 64 GB. Nach der Durchführung der in diesem Abschnitt vorgeschlagenen Optimierungen hat sich die Leistung verbessert. Allerdings bestand weiterhin ein Engpass bei der Abfrageparallelität. Nach dem Testen verschiedener Werte wurde die optimale Leistung durch das Setzen von MAXDOP=4 erreicht.

Erste Datenbankgrößenbestimmung

Der Versuch, das zukünftige Wachstum der Operations Manager-Datenbanken, insbesondere der Betriebs- und Data-Warehouse-Datenbanken, in den ersten Monaten nach der Bereitstellung abzuschätzen, ist keine einfache Übung. Während der Operations Manager Sizing Helper vernünftig bei der Schätzung des potenziellen Wachstums basierend auf der von der Produktgruppe aus ihren Labortests abgeleiteten Formel ist, berücksichtigt er nicht mehrere Faktoren, die das Wachstum kurzfristig im Vergleich zum langfristigen Wachstum beeinflussen können.

Die anfängliche Datenbankgröße, wie vom Sizing Helper vorgeschlagen, sollte auf eine vorhergesagte Größe zugewiesen werden, um Fragmentierung und entsprechenden Overhead zu reduzieren. Dies kann zum Zeitpunkt der Einrichtung für die Operational- und Data-Warehouse-Datenbanken angegeben werden. Wenn während der Einrichtung nicht genügend Speicherplatz verfügbar ist, können die Datenbanken später mit SQL Management Studio erweitert und anschließend neu indiziert werden, um sie entsprechend zu defragmentieren und zu optimieren. Diese Empfehlung gilt auch für die ACS-Datenbank.

Proaktive Überwachung des Wachstums der Betriebs- und Data-Warehouse-Datenbank sollte täglich oder wöchentlich durchgeführt werden. Dies ist notwendig, um unerwartete und signifikante Wachstumsschübe zu identifizieren und mit der Fehlersuche zu beginnen, um die Ursache zu bestimmen, sei es durch einen Fehler in einem Management Pack-Workflow (das heißt, Entdeckungsregel, Leistungs- oder Ereignissammlungsregel oder Überwachungs- oder Alarmregel) oder ein anderes Symptom mit einem Management Pack, das während der Test- und Qualitätssicherungsphase des Release-Management-Prozesses nicht identifiziert wurde.

Datenbank-Autowachstum

Wenn die reservierte Dateigröße der Datenbanken voll wird, kann SQL Server die Größe automatisch um einen Prozentsatz oder um einen festen Betrag erhöhen. Außerdem kann eine maximale Datenbankgröße konfiguriert werden, um zu verhindern, dass der gesamte auf der Festplatte verfügbare Speicherplatz belegt wird. Standardmäßig ist die Operations Manager-Datenbank nicht mit aktiviertem automatischen Wachstum konfiguriert; nur die Data Warehouse- und ACS-Datenbanken sind es.

Verlassen Sie sich nur auf Autogrow als Notfallmaßnahme für unerwartetes Wachstum. Autogrow führt zu einer Leistungseinbuße, die bei der Arbeit mit einer stark transaktionalen Datenbank berücksichtigt werden sollte. Leistungseinbußen umfassen:

• Wenn Sie keinen geeigneten Wachstumsinkrement bereitstellen, kann es zur Fragmentierung der Protokolldatei oder der Datenbank kommen.
• Wenn Sie eine Transaktion ausführen, die mehr Protokollspeicherplatz erfordert, als verfügbar ist, und das automatische Wachstum für das Transaktionsprotokoll dieser Datenbank aktiviert ist, umfasst die Zeit, die die Transaktion zum Abschluss benötigt, auch die Zeit, die das Transaktionsprotokoll benötigt, um um den konfigurierten Betrag zu wachsen.
• Wenn Sie eine große Transaktion ausführen, die ein Wachstum des Protokolls erfordert, müssen auch andere Transaktionen, die einen Schreibvorgang in das Transaktionsprotokoll erfordern, warten, bis der Wachstumsprozess abgeschlossen ist.

Wenn die Optionen "autogrow" und "autoshrink" kombiniert werden, kann dies zu unnötigem Overhead führen. Stellen Sie sicher, dass die Schwellenwerte, die die Wachstums- und Schrumpfungsoperationen auslösen, keine häufigen Größenänderungen verursachen. Zum Beispiel können Sie eine Transaktion ausführen, die dazu führt, dass das Transaktionsprotokoll bis zum Abschluss um 100 MB wächst; einige Zeit danach startet die automatische Verkleinerung und verkleinert das Transaktionsprotokoll um 100 MB. Dann führen Sie die gleiche Transaktion erneut aus, und das Transaktionsprotokoll wächst erneut um 100 MB. In diesem Beispiel erzeugen Sie unnötigen Overhead und möglicherweise eine Fragmentierung der Protokolldatei, was beides die Leistung negativ beeinflussen kann.

Konfigurieren Sie diese beiden Einstellungen sorgfältig. Die spezifische Konfiguration hängt wirklich von Ihrer Umgebung ab. Die allgemeine Empfehlung lautet, die Datenbankgröße um einen festen Betrag zu erhöhen, um die Fragmentierung der Festplatte zu reduzieren. Siehe zum Beispiel die folgende Abbildung, in der die Datenbank so konfiguriert ist, dass sie jedes Mal, wenn ein automatisches Wachstum erforderlich ist, um 1.024 MB wächst.

Cluster-Failover-Richtlinie

Windows Server-Failoverclustering ist eine Hochverfügbarkeitsplattform, die ständig die Netzwerkverbindungen und den Zustand der Knoten in einem Cluster überwacht. Wenn ein Knoten im Netzwerk nicht erreichbar ist, wird eine Wiederherstellungsaktion durchgeführt, um Anwendungen und Dienste auf einem anderen Knoten im Cluster wieder online zu bringen. Die Standardeinstellungen sind ab Werk für Ausfälle optimiert, bei denen es zu einem vollständigen Verlust eines Servers kommt, was als „schwerer“ Ausfall gilt. Dies wären nicht wiederherstellbare Fehlerszenarien wie der Ausfall von nicht redundanter Hardware oder Strom. In diesen Situationen geht der Server verloren, und das Ziel ist, dass das Failover-Clustering den Verlust des Servers schnell erkennt und rasch auf einem anderen Server im Cluster wiederherstellt. Um diese schnelle Wiederherstellung von schwerwiegenden Ausfällen zu erreichen, sind die Standardeinstellungen für die Überwachung der Cluster-Gesundheit 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; jedoch, wenn Cluster von wenigen Zentimetern auf möglicherweise mehrere Meilen auseinander gestreckt werden, kann der Cluster mehr und potenziell unzuverlässigen Netzwerkkomponenten zwischen den Knoten ausgesetzt werden. Ein weiterer Faktor ist, dass die Qualität von Commodity-Servern ständig steigt. In Kombination mit erhöhter Ausfallsicherheit durch redundante Komponenten (wie z. B. doppelte Stromversorgungen, NIC-Teaming und Multi-Path-I/O) kann die Anzahl nicht redundanter Hardwareausfälle potenziell recht selten sein. Da schwerwiegende Ausfälle möglicherweise seltener auftreten, möchten einige Kunden den Cluster für vorübergehende Ausfälle optimieren, bei denen der Cluster widerstandsfähiger gegenüber kurzen Netzwerkausfällen zwischen den Knoten ist. Indem Sie die standardmäßigen Fehlerschwellenwerte erhöhen, können Sie die Empfindlichkeit gegenüber kurzen Netzwerkproblemen, die nur eine kurze Zeit dauern, verringern.

Es ist wichtig zu verstehen, dass es hier keine richtige Antwort gibt und die optimierte Einstellung je nach Ihren spezifischen Geschäftsanforderungen und Service Level Agreements variieren kann.

Virtualisierung von SQL Server

In virtuellen Umgebungen wird aus Leistungsgründen empfohlen, die Betriebsdatenbank und die Data-Warehouse-Datenbank auf einem direkt angeschlossenen Speicher und nicht auf einer virtuellen Festplatte zu speichern. Sie können das Dienstprogramm Operations Manager Sizing Helper, das für Operations Manager 2012 veröffentlicht wurde, verwenden, um die erforderlichen IOPS abzuschätzen und Ihre Datenträger einem Stresstest zu unterziehen, um dies zu überprüfen. Die Speicherleistung kann mit dem Dienstprogramm „DiskSpd“ getestet werden. Siehe auch Operations Manager-Virtualisierungsunterstützung für zusätzliche Anleitungen zur virtualisierten Operations Manager-Umgebung.

Always On und Wiederherstellungsmodell

Obwohl es sich nicht strikt um eine Optimierung handelt, ist eine wichtige Überlegung in Bezug auf die Always On-Verfügbarkeitsgruppe die Tatsache, dass diese Funktion aufgrund ihres Designs erfordert, dass die Datenbanken im „vollständigen“ Wiederherstellungsmodell eingestellt werden. Das bedeutet, dass die Transaktionsprotokolle niemals verworfen werden, bis entweder eine vollständige Sicherung durchgeführt wird oder nur das Transaktionsprotokoll. Aus diesem Grund ist eine Backup-Strategie kein optionaler, sondern ein erforderlicher Bestandteil des AlwaysOn-Designs für Operations Manager-Datenbanken. Andernfalls füllen sich mit der Zeit die Datenträger mit Transaktionsprotokollen.

Eine Backup-Strategie muss die Details Ihrer Umgebung berücksichtigen. Ein typischer Sicherungszeitplan ist in der folgenden Tabelle angegeben.

Optimierung von SQL Server Reporting Services

Die Reporting Services-Instanz fungiert als Proxy für den Zugriff auf Daten in der Data Warehouse-Datenbank. Es generiert und zeigt Berichte basierend auf Vorlagen an, die in den Verwaltungspaketen gespeichert sind.

Die Operations Manager-Berichterstellungsrolle kann nicht parallel mit einer vorherigen Version der Berichterstellungsrolle installiert werden und muss ausschließlich im nativen Modus installiert werden (der SharePoint-Integrationsmodus wird nicht unterstützt).

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

Nächste Schritte

Um zu verstehen, wie das Hosting des (Reporting) Data Warehouse hinter einer Firewall konfiguriert wird, siehe Connect the (Reporting) Data Warehouse Across a Firewall.