Problembehandlung für graue Agent-Zustände in System Center Operations Manager

In diesem Artikel wird beschrieben, wie Sie Probleme beheben, bei denen ein Agent, ein Verwaltungsserver oder ein Gateway in System Center Operations Manager (OpsMgr) nicht verfügbar oder abgeblendet ist.

Ursprüngliche Produktversion: Microsoft System Center 2012 Operations Manager
Ursprüngliche KB-Nummer: 2288515

Ein Agent, ein Verwaltungsserver oder ein Gateway kann einen der folgenden Zustände aufweisen, wie durch die Farbe des Agentnamens und des Symbols im Bereich Überwachung angegeben.

Ursachen für einen grauen Zustand

Ein Agent, ein Verwaltungsserver oder ein Gateway kann aus einem der folgenden Gründe nicht verfügbar sein:

• Taktfehler
• Ungültige Konfiguration
• Fehler bei Systemworkflows
• Operations Manager-Datenbank- oder Data Warehouse-Leistungsprobleme
• Leistungsprobleme bei Verwaltungsservern oder Gatewayservern
• Netzwerk- oder Authentifizierungsprobleme
• Integritätsdienst wird nicht ausgeführt

Problembereich

Bevor Sie mit der Problembehandlung des abgeblendeten Agents beginnen, sollten Sie sich zunächst mit der Operations Manager-Topologie vertraut machen und dann den Umfang des Problems definieren. Die folgenden Fragen können Ihnen helfen, den Umfang des Problems zu definieren:

• Wie viele Agents sind betroffen?
• Tritt das Problem bei den Agents im selben Netzwerksegment auf?
• Melden die Agents demselben Verwaltungsserver?
• Wie oft treten die Agents in einen grauen Zustand ein und bleiben dort?
• Wie können Sie diese Situation in der Regel beheben (z. B. Neustart des Agent-Integritätsdiensts, Löschen des Caches, Automatische Wiederherstellung)?
• Werden die Taktfehlerwarnungen für diese Agents generiert?
• Tritt dieses Problem während einer bestimmten Tageszeit auf?
• Besteht dieses Problem weiterhin, wenn Sie ein Failover dieser Agents auf einen anderen Verwaltungsserver oder ein anderes Gateway ausführen?
• Wann hat dieses Problem begonnen?
• Wurden Änderungen an den Agents, den Verwaltungsservern oder dem Gateway oder der Verwaltungsgruppe vorgenommen?
• Handelt es sich bei den betroffenen Agents um Windows-Clustersysteme?
• Ist der Ordner Integritätsdienststatus von der Antivirenüberprüfung ausgeschlossen?

Problembehandlungsstrategie

Ihre Problembehandlungsstrategie hängt davon ab, welche Komponente inaktiv ist, wo diese Komponente in der Topologie liegt und wie weit das Problem verbreitet ist. Beachten Sie die folgenden Bedingungen:

• Wenn die Agents, die berichte an einen bestimmten Verwaltungsserver oder Gateway, nicht verfügbar sind, sollte die Problembehandlung auf Verwaltungsserver- oder Gatewayebene beginnen.
• Wenn die Gateways, die einen bestimmten Verwaltungsserver melden, nicht verfügbar sind, sollte die Problembehandlung auf Verwaltungsserverebene beginnen.
• Bei Systemen ohne Agent, für Netzwerkgeräte und für Unix- und Linux-Server sollte die Problembehandlung bei dem Agent, dem Verwaltungsserver oder dem Gateway beginnen, von dem diese Objekte überwacht werden.
• Die Problembehandlung beginnt in der Regel auf der Ebene unmittelbar über der nicht verfügbaren Komponente.

Szenario 1

Nur wenige Agents sind von dem Problem betroffen. Diese Agents melden verschiedene Verwaltungsserver. Agents sind in regelmäßigen Abständen nicht verfügbar. Obwohl Sie den Agent-Cache löschen können, um das Problem vorübergehend zu beheben, tritt das Problem nach einigen Tagen wieder auf.

Lösung für Szenario 1

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Wenden Sie den entsprechenden Hotfix auf die betroffenen Betriebssysteme an.
2. Schließen Sie den Agent-Cache von der Antivirenüberprüfung aus. Weitere Informationen finden Sie unter Empfehlungen für Antivirenausschlüsse, die sich auf Operations Manager beziehen.
3. Beenden Sie den Integritätsdienst.
4. Löschen Sie den Agent-Cache.
5. Starten Sie den Integritätsdienst.

Szenario 2

Nur wenige Agents sind von dem Problem betroffen. Diese Agents melden verschiedene Verwaltungsserver. Agents bleiben ständig inaktiv. Obwohl Sie den Agent-Cache löschen können, wird das Problem dadurch nicht behoben.

Lösung für Szenario 2

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Ermitteln Sie, ob der Integritätsdienst aktiviert ist und derzeit auf dem Verwaltungsserver oder Gateway ausgeführt wird. Wenn der Integritätsdienst nicht mehr reagiert, generieren Sie ein ADPlus-Speicherabbild in einem Diensthängermodus, um die Ursache des Problems zu ermitteln. Weitere Informationen finden Sie unter Verwenden von ADPlus.vbs zur Problembehandlung bei "Hängen" und "Abstürzen".

2. Überprüfen Sie das Operations Manager-Ereignisprotokoll auf dem Agent, um eines der folgenden Ereignisse zu finden:

   Ereignis-ID: 1102
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Regel/Monitor "%4", die für instance "%3" mit id:"%2" ausgeführt wird, kann nicht initialisiert werden und wird nicht geladen. Verwaltungsgruppe "%1"

   Ereignis-ID: 1103
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Zusammenfassung: %2-Regel(en)/Monitore sind fehlgeschlagen und wurden entladen, %3 von ihnen hat den Fehlergrenzwert erreicht, der das automatische Erneute Laden verhindert. Verwaltungsgruppe "%1". Dies ist nur ein Zusammenfassungsereignis. Weitere Informationen finden Sie unter Andere Ereignisse mit Beschreibungen von nicht geladenen Regeln/Monitoren.

   Ereignis-ID: 1104
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   RunAs-Profil im Workflow "%4", das für instance "%3" mit id:"%2" ausgeführt wird, kann nicht aufgelöst werden. Der Workflow wird nicht geladen. Verwaltungsgruppe "%1"

   Ereignis-ID: 1105
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Typkonflikt für das RunAs-Profil im Workflow "%4", der für instance "%3" mit id:"%2" ausgeführt wird. Der Workflow wird nicht geladen. Verwaltungsgruppe "%1"

   Ereignis-ID: 1106
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Auf das Nur-Text-RunAs-Profil im Workflow "%4" kann nicht zugegriffen werden, das für instance "%3" mit id:"%2" ausgeführt wird. Der Workflow wird nicht geladen. Verwaltungsgruppe "%1"

   Ereignis-ID: 1107
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Konto für das RunAs-Profil im Workflow "%4", das für instance "%3" mit id:"%2" ausgeführt wird, ist nicht definiert. Der Workflow wird nicht geladen. Ordnen Sie dem Profil ein Konto zu. Verwaltungsgruppe "%1"

   Ereignis-ID: 1108
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Ein im ausführenden Profil "%7" angegebenes Konto kann nicht aufgelöst werden. Insbesondere wird das Konto in der Außerkraftsetzung des sicheren Verweises "%6" verwendet. %n%n Diese Bedingung ist möglicherweise aufgetreten, weil das Konto nicht für die Verteilung an diesen Computer konfiguriert ist. Um dieses Problem zu beheben, müssen Sie das unten angegebene ausführende Profil öffnen, den Eintrag Konto suchen, wie durch die SSID angegeben, und entweder das Konto an diesen Computer verteilen, falls zutreffend, oder die Einstellung im Profil ändern, sodass das Zielobjekt nicht das angegebene Konto verwendet. %n%nVerwaltungsgruppe: %1 %nProfil ausführen: %7 %nSecureReferenceOverride name: %6 %nSecureReferenceOverride ID: %4 %nObjektname: %3 %nObjekt-ID: %2 %nKonto-SSID: %5

   Ereignis-ID: 4000
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Ein Überwachungshost reagiert nicht oder ist abgestürzt. Der status Code für den Hostfehler lautet %1.

   Ereignis-ID: 21016
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   OpsMgr konnte keinen Kommunikationskanal für %1 einrichten, und es gibt keine Failoverhosts. Die Kommunikation wird fortgesetzt, wenn %1 verfügbar ist und die Kommunikation von diesem Computer aus zulässig ist.

   Ereignis-ID: 21006
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Der OpsMgr-Connector konnte keine Verbindung mit %1:%2 herstellen. Der Fehlercode ist %3(%4). Vergewissern Sie sich, dass netzwerkkonnektivität vorhanden ist, der Server ausgeführt wird und seinen Lauschport registriert hat und keine Firewalls den Datenverkehr zum Ziel blockieren.

   Ereignis-ID: 20070
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Der OpsMgr-Connector ist mit %1 verbunden, aber die Verbindung wurde unmittelbar nach der Authentifizierung geschlossen. Die wahrscheinlichste Ursache für diesen Fehler ist, dass der Agent nicht zur Kommunikation mit dem Server autorisiert ist oder dass der Server keine Konfiguration empfangen hat. Überprüfen Sie das Ereignisprotokoll auf dem Server auf das Vorhandensein von 20000 Ereignissen, was darauf hinweist, dass Agents, die nicht genehmigt wurden, versuchen, eine Verbindung herzustellen.

   Ereignis-ID: 20051
   Ereignisquelle: OpsMgr Connector
   Ereignisbeschreibung:
   Das angegebene Zertifikat konnte nicht geladen werden, da das Zertifikat derzeit nicht gültig ist. Überprüfen Sie, ob die Systemzeit korrekt ist, und stellen Sie das Zertifikat ggf. erneut aus%n Gültige Startzeit des Zertifikats: %1%n Gültige Endzeit des Zertifikats : %2

   Ereignisquelle: ESE
   Ereigniskategorie: Transaktions-Manager
   Ereignis-ID: 623
   Beschreibung: HealthService (<PID>) Der Versionsspeicher für instance <instance>("<Name>") hat seine maximale Größe von <Mb> erreicht. Es ist wahrscheinlich, dass eine Transaktion mit langer Ausführungszeit die Bereinigung des Versionsspeichers verhindert und dessen Größe anwächst. Updates werden abgelehnt, bis für die Transaktion mit langer Ausführungszeit ein vollständiger Commit ausgeführt oder ein Rollback ausgeführt wurde. Mögliche Transaktion mit langer Ausführungsdauer:
   SessionId: <value>
   Sitzungskontext: <Wert>
   ThreadId im Sitzungskontext: <Wert>.
   Bereinigung: <Wert>

3. Wenn Sie die folgenden spezifischen Ereignisse finden, befolgen Sie diese Richtlinien:

   • Ereignisse 1102 und 1103: Diese Ereignisse deuten darauf hin, dass einige der Workflows nicht geladen werden konnten. Wenn dies die wichtigsten Systemworkflows sind, können diese Ereignisse das Problem verursachen. Konzentrieren Sie sich in diesem Fall auf das Auflösen dieser Ereignisse.

   • Ereignisse 1104, 1105, 1106, 1107 und 1108: Diese Ereignisse können zu Ereignissen 1102 und 1103 führen. In der Regel tritt dies aufgrund falsch konfigurierter ausführener Konten auf. Beispielsweise sind die ausführenden Konten so konfiguriert, dass sie mit der falschen Klasse verwendet werden oder nicht so konfiguriert sind, dass sie an den Agent verteilt werden.

   • Ereignis 4000: Dieses Ereignis gibt an, dass der Monitoringhost.exe Prozess abgestürzt ist. Wenn dieses Problem durch einen DLL-Konflikt oder fehlende Registrierungsschlüssel verursacht wird, können Sie das Problem möglicherweise beheben, indem Sie den Agent neu installieren. Wenn das Problem weiterhin besteht, versuchen Sie, es mit den folgenden Methoden zu beheben:

     • Führen Sie eine Prozessmonitorerfassung aus, bis der Prozess abstürzt. Weitere Informationen finden Sie unter Prozessmonitor v3.53.
     • Generieren Sie ein ADPlus-Speicherabbild im Absturzmodus. Weitere Informationen finden Sie unter Verwenden von ADPlus.vbs zur Problembehandlung bei "Hängen" und "Abstürzen".

   • Ereignis-ID 21006: Dieses Ereignis gibt an, dass Kommunikationsprobleme zwischen dem Agent und dem Verwaltungsserver bestehen. Wenn der Agent ein Zertifikat für die gegenseitige Authentifizierung verwendet, überprüfen Sie, ob das Zertifikat nicht abgelaufen ist und dass der Agent das richtige Zertifikat verwendet. Wenn Kerberos verwendet wird, überprüfen Sie, ob der Agent mit Active Directory kommunizieren kann. Wenn die Authentifizierung ordnungsgemäß funktioniert, kann dies bedeuten, dass die Pakete vom Agent den Verwaltungsserver oder das Gateway nicht erreichen. Versuchen Sie, ein Telnet zum Port 5723 vom Agent zum Verwaltungsserver einzurichten. Führen Sie außerdem eine gleichzeitige Netzwerkablaufverfolgung zwischen dem Agent und dem Verwaltungsserver aus, während Sie die Kommunikationsfehler reproduzieren. Dies kann Ihnen helfen zu bestimmen, ob die Pakete den Verwaltungsserver erreichen und ob ein Gerät zwischen den beiden Komponenten versucht, den Datenverkehr zu optimieren oder einige Pakete zu löschen. Weitere Informationen finden Sie unter Sammeln von Daten mithilfe des Netzwerkmonitors.

   • Ereignis-ID 623: Dieses Ereignis tritt in der Regel in einer großen Operations Manager-Umgebung auf, in der ein Verwaltungsserver oder ein Agent-Computer viele Workflows verwaltet. Weitere Informationen finden Sie unter Mindestens ein Verwaltungsserver und die zugehörigen verwalteten Geräte sind in der Operations Manager-Konsole abgeblendet.

Szenario 3

Alle Agents, die Berichte an einen bestimmten Verwaltungsserver oder gateway senden, sind nicht verfügbar.

Lösung für Szenario 3

Führen Sie die folgenden Schritte aus, um das Problem in diesem Szenario zu beheben:

1. Versuchen Sie, zu ermitteln, welche Art von Workloads der Verwaltungsserver oder das Gateway überwacht. Zu diesen Workloads können Netzwerkgeräte, plattformübergreifende Agents, synthetische Transaktionen, Windows-Agents und Computer ohne Agent gehören.

2. Bestimmen Sie, ob der Integritätsdienst auf dem Verwaltungsserver oder Gateway ausgeführt wird.

3. Bestimmen Sie, ob der Verwaltungsserver im Wartungsmodus ausgeführt wird. Entfernen Sie den Server bei Bedarf aus dem Wartungsmodus.

4. Überprüfen Sie das Operations Manager-Ereignisprotokoll auf dem Agent auf alle Ereignisse, die in Szenario 2 aufgeführt sind. Wenn die Ereignis-ID 21006 vorhanden ist, befolgen Sie die gleichen Richtlinien, die unter Lösung für Szenario 2 erwähnt werden. Darüber hinaus gibt dieses Ereignis in diesem Fall an, dass der Verwaltungsserver oder das Gateway nicht mit dem übergeordneten Server kommunizieren kann. Bei einem Gateway kann der übergeordnete Server ein beliebiger Verwaltungsserver sein. (Siehe Schritt 3 in der Lösung für Szenario 2.)

5. Untersuchen Sie das Operations Manager-Ereignisprotokoll auf die folgenden Ereignisse. Diese Ereignisse weisen in der Regel darauf hin, dass Leistungsprobleme auf dem Verwaltungsserver oder microsoft SQL Server bestehen, auf dem die OperationsManager Datenbank oder OperationsManagerDW gehostet wird:

   Ereignis-ID: 2115
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Eine Bindungsdatenquelle in der Verwaltungsgruppe %1 hat Elemente an den Workflow gesendet, aber in %5 Sekunden keine Antwort erhalten. Dies weist auf ein Leistungs- oder Funktionsproblem mit dem Workflow hin.%n Workflow-ID: %2%n Instanz: %3%n Instanz-ID: %4%n

   Ereignis-ID: 5300
   Ereignisquelle: HealthService
   Ereignisbeschreibung:
   Der lokale Integritätsdienst ist nicht fehlerfrei. Der Änderungsfluss des Entitätszustands wird mit ausstehender Bestätigung angehalten. %n%nManagementgruppe: %2 %nManagementgruppen-ID: %1

   Ereignis-ID: 4506
   Ereignisquelle: HealthService
   Ereignisbeschreibung: Operations Manager
   Daten wurden aufgrund zu vieler ausstehender Daten in der Regel "%2" gelöscht, die für instance "%3" mit id:"%4" in der Verwaltungsgruppe "%1" ausgeführt wurde.

   Ereignis-ID: 31551
   Ereignisquelle: Integritätsdienstmodule
   Ereignisbeschreibung:
   Fehler beim Speichern von Daten im Data Warehouse. Der Vorgang wird wiederholt.%rException '%5': %6 %n%nEin oder mehrere Workflows waren davon betroffen. %n%nArbeitsflussname: %2 %nInstancename: %3 %nInstance-ID: %4 %nVerwaltungsgruppe: %1

   Ereignis-ID: 31552
   Ereignisquelle: Integritätsdienstmodule
   Ereignisbeschreibung:
   Fehler beim Speichern von Daten im Data Warehouse.%rException '%5': %6 %n%nEin oder mehrere Workflows waren davon betroffen. %n%nArbeitsflussname: %2 %nInstancename: %3 %nInstance-ID: %4 %nVerwaltungsgruppe: %1

   Ereignis-ID: 31553
   Ereignisquelle: Integritätsdienstmodule
   Ereignisbeschreibung:
   Daten wurden in den Data Warehouse Stagingbereich geschrieben, aber bei einem der nachfolgenden Vorgänge ist bei der Verarbeitung ein Fehler aufgetreten.%rException '%5': %6 %n%nEin oder mehrere Workflows waren davon betroffen. %n%nArbeitsflussname: %2 %nInstancename: %3 %nInstance-ID: %4 %nVerwaltungsgruppe: %1

   Ereignis-ID: 31557
   Ereignisquelle: Integritätsdienstmodule
   Ereignisbeschreibung:
   Fehler beim Abrufen von Synchronisierungsprozessstatusinformationen aus Data Warehouse Datenbank. Der Vorgang wird wiederholt.%rException '%5': %6 %n%nEin oder mehrere Workflows waren davon betroffen. %n%nArbeitsflussname: %2 %nInstancename: %3 %nInstance-ID: %4 %nVerwaltungsgruppe: %1

6. Die Ereignis-ID 3155X kann auch aufgrund falscher Konfigurationen des ausführenden Kontos oder fehlender Berechtigungen für die ausführenden Konten protokolliert werden.

Szenarien 4

Alle Agents, die an einen bestimmten Verwaltungsserver berichten, wechseln zeitweilig zwischen fehlerfreien und grauen Zuständen. Oder alle Agents in der Umgebung wechseln zeitweilig zwischen fehlerfreien und grauen Zuständen.

Lösung für Szenario 4

Um das Problem zu beheben, ermitteln Sie zunächst die Ursache des Problems. Häufige Ursachen für die Nichtverfügbarkeit des temporären Servers sind die folgenden:

• Der übergeordnete Server der Agents ist vorübergehend offline.
• Agents überfluten den Verwaltungsserver mit Betriebsdaten wie Warnungen, Zuständen, Ermittlungen usw. Dies kann zu einer verstärkten Nutzung von Systemressourcen in der Operations Manager-Datenbank und auf den Operations Manager-Servern führen.
• Netzwerkausfälle führten zu einem vorübergehenden Kommunikationsfehler zwischen dem übergeordneten Server und den Agents.
• Es sind Änderungen an management pack (MP) aufgetreten. In der Operations Manager-Konsole erfordern diese Änderungen eine Operations Manager-Konfiguration und eine MP-Neuverteilung an die Agents. Wenn sich die Änderung auf eine größere Agent-Basis auswirkt, kann dies zu einer erhöhten Nutzung der Systemressourcen auf der Operations Manager-Datenbank und auf Operations Manager-Servern führen.

Der Schlüssel zur Problembehandlung in diesen Szenarien besteht darin, die Dauer der Nichtverfügbarkeit des Servers und die Tageszeit zu verstehen, zu der er aufgetreten ist. Dies hilft Ihnen, den Umfang des Problems schnell einzugrenzen.

Problembehandlung bei der Leistung von Verwaltungsservern und Gateways

Verwaltungsserver

Während eines Konfigurationsupdate-Bursts (der durch mp-Import und -Ermittlung verursacht wird) sind die typischen Engpässe zuerst die CPU und zweitens die Operations Manager-Installationsdatenträger-E/A. Der Verwaltungsserver ist für die Weiterleitung von Konfigurationsdateien an die Ziel-Agents verantwortlich.

Bei der Sammlung operativer Daten werden Engpässe in der Regel durch die CPU verursacht. Die Datenträger-E/A kann auch die maximale Kapazität aufweisen, aber dies ist nicht so wahrscheinlich. Der Verwaltungsserver ist für das Dekomprimieren und Entschlüsseln eingehender Betriebsdaten und das Einfügen in die Betriebsdatenbank verantwortlich. Es sendet auch Bestätigungen (ACKs) zurück an die Agents oder Gateways, nachdem betriebsbezogene Daten empfangen wurden, und verwendet Datenträgerwarteschlangen, um diese ausgehenden ACKs vorübergehend zu speichern.

Gateway

Das Gateway ist sowohl CPU-gebunden als auch E/A-gebunden. Wenn das Gateway eine große Datenmenge weitergibt, können sowohl die CPU- als auch die E/A-Vorgänge eine hohe Auslastung aufweisen. Der Großteil der CPU-Auslastung wird durch die Dekomprimierung, Komprimierung, Ver- und Entschlüsselung der eingehenden Daten sowie durch die Übertragung dieser Daten verursacht. Alle Daten, die vom Gateway und von den Agents empfangen werden, werden in einer persistenten Warteschlange auf dem Datenträger gespeichert, um vom Gatewayintegritätsdienst gelesen und an den Verwaltungsserver weitergeleitet zu werden. Dies kann zu einer hohen Datenträgerauslastung führen. Diese Nutzung kann erheblich sein, wenn das Gateway vorübergehend offline geschaltet wird und dann die gesammelten Agent-Daten verarbeiten muss, die die Agents generiert und zu senden versucht haben, als das Gateway noch offline war.

Um das Problem in dieser Situation zu beheben, sammeln Sie die folgenden Informationen für jeden betroffenen Verwaltungsserver oder gateway:

• Genaue Windows-Version, -Edition und -Buildnummer

• Anzahl der Prozessoren

• Ram-Menge

• Laufwerk, das den Ordner "Integritätsdienststatus" enthält

• Gibt an, ob die Antivirensoftware so konfiguriert ist, dass der Integritätsdienstspeicher ausgeschlossen wird.

  Hinweis

  Weitere Informationen finden Sie unter Empfehlungen für Antivirenausschlüsse, die sich auf Operations Manager beziehen.

• RAID-Ebene (0, 1, 0+15oder 1+0) für das Laufwerk, das vom Integritätsdienststatus verwendet wird

• Anzahl der datenträger, die für das RAID verwendet werden

• Gibt an, ob der akkugestützte Schreibcache auf dem Arraycontroller aktiviert ist.

Problembehandlung bei SQL Server Leistung

Betriebsdatenbank (OperationsManager)

Für die OperationsManager Datenbank ist der wahrscheinlichste Engpass das Datenträgerarray. Wenn das Datenträgerarray nicht die maximale E/A-Kapazität aufweist, ist der nächste wahrscheinlichste Engpass die CPU. Bei der Datenbank kommt es zu gelegentlichen Verlangsamungen und Stürmen bei operativen Daten (hohe Inzidenzen von Ereignissen, Warnungen und Leistungsdaten- oder Zustandsänderungen, die relativ lange andauern). Ein kurzer Burst führt in der Regel zu keiner signifikanten Verzögerung für einen längeren Zeitraum.

Während des Einfügens operativer Daten werden die Datenbankdatenträger hauptsächlich für Schreibvorgänge verwendet. Die CPU-Auslastung wird durch SQL Server Änderung verursacht. Dies kann auftreten, wenn Sie über große und komplexe Abfragen, umfangreiche Dateneinfügungen und die Bereinigung großer Tabellen (standardmäßig um Mitternacht) verfügen. In der Regel verbraucht die Bereinigung auch großer Ereignisse und Leistungsdatentabellen keine übermäßigen CPU- oder Datenträgerressourcen. Die Bereinigung der Warnungs- und Zustandsänderungstabellen kann jedoch für große Tabellen CPU-intensiv sein.

Die Datenbank ist auch CPU-gebunden, wenn sie Konfigurationsumverteilungsspitzen verarbeitet, die durch MP-Importe oder eine große instance Speicherplatzänderung verursacht werden. In diesen Fällen fragt der Konfigurationsdienst die Datenbank nach einer neuen Agent-Konfiguration ab. Dies führt in der Regel zu CPU-Spitzen in der Datenbank, bevor der Dienst die Konfigurationsupdates an die Agents sendet.

Data Warehouse (OperationsManagerDW)

Für die OperationsManagerDW Datenbank ist der wahrscheinlichste Engpass das Datenträgerarray. Dies tritt in der Regel aufgrund von umfangreichen operativen Dateneinfügungen auf. In diesen Fällen sind die Datenträger größtenteils mit Schreibvorgängen beschäftigt. In der Regel führen die Datenträger nur wenige Lesevorgänge durch, mit ausnahme der Verarbeitung manuell generierter Berichtsansichten, da diese Abfragen für das Data Warehouse ausführen.

Die CPU-Auslastung wird durch SQL Server Änderung verursacht. CPU-Spitzen können bei umfangreichen Partitionierungsaktivitäten (wenn Tabellen groß werden und dann partitioniert werden), der Generierung komplexer Berichte und großer Mengen von Warnungen in der Datenbank auftreten, mit denen das Data Warehouse ständig synchronisiert werden muss.

Allgemeine Tipps zur Problembehandlung

Um das Problem in dieser Situation zu beheben, sammeln Sie die folgenden Informationen für jeden betroffenen Verwaltungsserver oder gateway:

• Genaue Windows-Version, -Edition und -Buildnummer

• Anzahl der Prozessoren

• Ram-Menge

• Menge des Arbeitsspeichers, der SQL Server zugeordnet ist

• Ob SQL Server 32-Bit ist und AWE aktiviert ist

  Die meisten dieser Informationen finden Sie in SQL Server Management Studio oder in SQL Server Enterprise Manager. Öffnen Sie dazu das Fenster Eigenschaften des Servers, und wählen Sie dann die Registerkarten Allgemein und Arbeitsspeicher aus. Die Registerkarte Allgemein enthält die SQL Server Version, die Windows-Version, die Plattform, die Ram-Menge und die Anzahl der Prozessoren. Die Registerkarte Arbeitsspeicher enthält den Arbeitsspeicher, der SQL Server zugeordnet ist. In Microsoft SQL Server 2008 enthält die Registerkarte Arbeitsspeicher auch die Option AWE.

  Wenn das Betriebssystem eine 32-Bit-Version aufweist und der RAM mindestens 4 GB beträgt, überprüfen Sie, ob die /pae Schalter oder /3gb im Boot.ini vorhanden sind. Datei. Diese Optionen können falsch konfiguriert werden, wenn der Server ursprünglich mit maximal 4 GB RAM installiert wurde und der RAM später aktualisiert wurde.

  Bei 32-Bit-Servern mit 4 GB RAM erhöht der /3gb Switch in Boot.ini die Arbeitsspeichermenge, die SQL Server adressieren kann (von 2 GB auf 3 GB). Bei 32-Bit-Servern, die über mehr als 4 GB RAM verfügen, könnte der /3gb Switch in Boot.ini tatsächlich die Menge an Arbeitsspeicher begrenzen, die SQL Server adressieren kann. Fügen Sie für diese Systeme den /pae Switch zu Boot.ini hinzu, und aktivieren Sie dann AWE in SQL Server.

  Überprüfen Sie auf einem Mehrprozessorsystem die Einstellung Max. Grad an Parallelität (MAXDOP). In SQL Server 2008 befindet sich diese Option auf der Registerkarte Erweitert im Dialogfeld Eigenschaften für den Server.

  Der Standardwert ist 0, was bedeutet, dass alle verfügbaren Prozessoren verwendet werden. Die Einstellung 0 ist für Server mit acht oder weniger Prozessoren in Ordnung. Bei Servern mit mehr als acht Prozessoren kann die Zeit, die SQL Server benötigt, um die Verwendung aller Prozessoren zu koordinieren, kontraproduktiv sein. Daher sollten Sie für Server mit mehr als acht Prozessoren im Allgemeinen max. Grad an Parallelität auf den Wert 8 festlegen. Führen Sie dazu den folgenden Befehl in SQL Query Analyzer aus:

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• Laufwerkbuchstaben, die Data Warehouse-, Operations Manager-DB- und Tempdb-Dateien enthalten

• Gibt an, ob die Antivirensoftware so konfiguriert ist, dass SQL-Daten und Protokolldateien ausgeschlossen werden (das Scannen SQL Server Datenbankdateien mit Antivirensoftware kann die Leistung beeinträchtigen.)

• Menge des freien Speicherplatzes auf Laufwerken, die Data Warehouse-, Operations Manager-DB- und Tempdb-Dateien enthalten

• Speichertyp (SAN oder lokal)

• RAID-Ebene (0, 1, 5, 0+1 oder 1+0) für Laufwerke, die von SQL Server

• Wenn SAN-Speicher verwendet wird: Anzahl der Spindeln auf jeder LUN, die von SQL Server verwendet wird

• Wenn das konvertierte Exchange 2007-Management Pack verwendet wird oder jemals verwendet wurde: Anzahl der Zeilen in der Tabelle in der LocalizedText Operations Manager-Datenbank und in der EventPublisher Tabelle in der Data Warehouse-Datenbank

  Führen Sie die folgenden Befehle aus, um die Zeilenbeträge zu bestimmen:

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

Leistungsindikatoren zum Identifizieren der Arbeitsspeicherauslastung

Leistungsindikatoren zum Identifizieren des Datenträgerdrucks

Erfassen Sie diese physischen Datenträgerzähler für alle Laufwerke, die SQL-Daten oder Protokolldateien enthalten:

• % Leerlaufzeit: Gibt an, wie viel Leerlaufzeit des Datenträgers gemeldet wird. Alles, was unter 50 Prozent liegt, kann auf einen Datenträgerengpass hinweisen.

• Durchschn. Länge der Datenträgerwarteschlange: Dieser Wert sollte die doppelte Anzahl von Spindeln auf einer LUN nicht überschreiten. Wenn eine LUN beispielsweise 25 Spindeln hat, ist ein Wert von 50 akzeptabel. Wenn eine LUN jedoch über 10 Spindeln verfügt, ist der Wert 25 zu hoch. Sie können die folgenden Formeln basierend auf der RAID-Ebene und der Anzahl der Datenträger in der RAID-Konfiguration verwenden:

  • RAID 0: Alle Datenträger arbeiten in einem RAID 0-Satz

  • Durchschnittliche Länge< der Datenträgerwarteschlange= # (Datenträger im Array) *2

  • RAID 1: Die Hälfte der Datenträger macht Arbeit; Daher kann nur die Hälfte von ihnen auf die Datenträgerwarteschlange gezählt werden.

  • Durchschnittliche Länge< der Datenträgerwarteschlange= # (Datenträger im Array/2) *2

  • RAID 10: Die Hälfte der Datenträger "macht Arbeit"; Daher kann nur die Hälfte von ihnen auf die Datenträgerwarteschlange gezählt werden.

  • Durchschnittliche Länge< der Datenträgerwarteschlange= # (Datenträger im Array/2) *2

  • RAID 5: Alle Datenträger arbeiten in einem RAID 5-Satz

  • Durchschnittliche Länge< der Datenträgerwarteschlange= # Datenträger im Array *2

  • Durchschn. Datenträgersekunden/Übertragung: Die Anzahl der Sekunden, die zum Abschließen einer Datenträger-E/A benötigt werden

  • Durchschn. Datenträgersekunden/Lesevorgang: Die durchschnittliche Zeit zum Lesen von Daten vom Datenträger in Sekunden

  • Durchschn. Datenträgersekunden/Schreibvorgänge: Die durchschnittliche Zeit zum Schreiben von Daten auf den Datenträger in Sekunden

    Die letzten drei Leistungsindikatoren in dieser Liste sollten konsistent Werte von etwa 0,020 (20 ms) oder niedriger aufweisen und dürfen niemals 0,050 (50 ms) überschreiten. Im Folgenden finden Sie die Schwellenwerte, die im SQL Server Leitfaden zur Problembehandlung bei der Leistung dokumentiert sind:

    • Weniger als 10 ms: sehr gut
    • Zwischen 10 und 20 ms: okay
    • Zwischen 20 und 50 ms: langsam, erfordert Aufmerksamkeit
    • Größer als 50 ms: schwerwiegender E/A-Engpass

  • Datenträgerbytes/s: Die Anzahl der Bytes, die pro Sekunde auf oder vom Datenträger übertragen werden.

  • Datenträgerübertragungen/Sekunde: Die Anzahl der Eingabe- und Ausgabevorgänge pro Sekunde (IOPS)

  Wenn die Leerlaufzeit in Prozent niedrig ist (10 Prozent oder weniger), bedeutet dies, dass der Datenträger vollständig ausgelastet ist. In diesem Fall geben die letzten beiden Leistungsindikatoren in dieser Liste (Datenträgerbytes/s und Datenträgerübertragungen/Sekunde) einen guten Hinweis auf den maximalen Durchsatz des Laufwerks in Bytes bzw. in IOPS. Der Durchsatz eines SAN-Laufwerks ist stark variabel, abhängig von der Anzahl der Spindeln, der Geschwindigkeit der Laufwerke und der Geschwindigkeit des Kanals. Wenden Sie sich am besten an den SAN-Anbieter, um herauszufinden, wie viele Bytes und IOPS das Laufwerk unterstützen soll. Wenn die Leerlaufzeit in % niedrig ist und die Werte für diese beiden Leistungsindikatoren den erwarteten Durchsatz des Laufwerks nicht erfüllen, bitten Sie den SAN-Anbieter, die Problembehandlung durchzuführen.

SQL Server Leitfaden zur Problembehandlung bei der Leistung bietet tiefere Einblicke in die Problembehandlung SQL Server Leistung.

Operations Manager-Leistungsindikatoren

In den folgenden Abschnitten werden die Leistungsindikatoren beschrieben, mit denen Sie die Leistung von Operations Manager überwachen und behandeln können.

Gatewayserverrolle

Leistungsindikatoren insgesamt

Diese Leistungsindikatoren geben die Gesamtleistung des Gateways an:

Generische Leistungsindikatoren für Operations Manager-Prozesse

Diese Leistungsindikatoren geben die Gesamtleistung von Operations Manager-Prozessen auf dem Gateway an:

Operations Manager-spezifische Leistungsindikatoren

Bei diesen Leistungsindikatoren handelt es sich um Operations Manager-spezifische Leistungsindikatoren, die die Leistung bestimmter Aspekte von Operations Manager auf dem Gateway angeben:

Verwaltungsserverrolle

Leistungsindikatoren insgesamt

Diese Leistungsindikatoren geben die Gesamtleistung des Verwaltungsservers an:

Generische Leistungsindikatoren für Operations Manager-Prozesse

Diese Leistungsindikatoren geben die Gesamtleistung von Operations Manager-Prozessen auf dem Verwaltungsserver an:

Operations Manager-spezifische Leistungsindikatoren

Bei diesen Leistungsindikatoren handelt es sich um Operations Manager-spezifische Leistungsindikatoren, die die Leistung bestimmter Aspekte von Operations Manager auf dem Verwaltungsserver angeben: