Der SQL Server des Data Warehouse läuft plötzlich dauerhaft am Anschlag, alle paar Minuten erscheint Ereignis 31552. Die häufigsten Ursachen – von neuen Datasets bis zu gesperrten Konten.
Das Symptom aus einem Community-Fall: Auf dem SQL Server, der ausschließlich das Operations-Manager-Data-Warehouse hostet, steigt die CPU-Last von durchschnittlich 20 % plötzlich auf über 90 %. Im Aktivitätsmonitor laufen ständig Prozeduren wie StandardDatasetMaintenance, und im Ereignisprotokoll der Management Server erscheint minütlich das Ereignis 31552 (Fehler beim Speichern von Daten im Data Warehouse, häufig wegen Zeitüberschreitungen).
Was im Hintergrund passiert
Das Data Warehouse aggregiert Rohdaten regelmäßig zu stündlichen und täglichen Werten und räumt alte Daten auf. Diese Wartung erledigt die Prozedur StandardDatasetMaintenance für jedes Dataset – etwa Leistung, Status, Alarme, Ereignisse oder die Datasets einzelner Management Packs. Kommt eine Aggregation nicht rechtzeitig fertig, startet sie beim nächsten Durchlauf erneut. Es entsteht ein Rückstau, der sich selbst verstärkt.
Die häufigsten Ursachen
- Ein neues Management Pack mit eigenem Dataset: Im Community-Fall wies das Ereignis auf das Dataset
Microsoft.Exchange.2010.Reports.Dataset.Availabilityhin, das mit einem neu importierten Exchange-MP kam. Große Datenmengen beim ersten Aggregieren können den Server über Tage auslasten. - Gesperrte oder abgelaufene Konten: Die eigentliche Lösung im Community-Fall: Die Konten für Data Warehouse Read und Data Warehouse Write waren gesperrt. Workflows konnten keine Daten schreiben, Warteschlangen auf den Management Servern liefen voll, und der Reporting-Dienst funktionierte nicht mehr. Nach dem Entsperren normalisierte sich die Last schnell.
- Aggregationsrückstand nach Ausfall: War das Data Warehouse längere Zeit nicht erreichbar, holt es die Aggregationen nach – mit entsprechend hoher Last.
- Zu wenig Ressourcen oder fehlende Wartung (Indexpflege, Statistiken) auf dem SQL Server.
So gehen Sie vor
- Ereignisse lesen: Das Ereignis 31552 nennt den betroffenen Workflow und das Dataset. Damit wissen Sie, wo Sie ansetzen müssen.
- Konten prüfen: Sind die Run As-Konten für Lesen und Schreiben im Data Warehouse aktiv, nicht gesperrt und mit gültigem Kennwort hinterlegt?
- Rückstand messen: In der Data-Warehouse-Datenbank zeigt die Tabelle
StandardDatasetAggregationHistory, wie viele Aggregationen noch ausstehen (DirtyInd = 1). - Geduld oder gezielte Hilfe: Ein Rückstand baut sich oft von selbst ab. Bei großen Rückständen kann die Wartung für ein einzelnes Dataset gezielt manuell angestoßen werden – Microsoft und erfahrene SCOM-Blogger haben dazu bewährte Skripte veröffentlicht.
- Warteschlangen beobachten: Alarme zu vollen Warteschlangen auf Management Servern sind oft ein Folgesymptom, nicht die Ursache.
Tipp
Überwachen Sie die Run As-Konten aktiv – etwa mit einem Alarm bei Kontosperrung im Active Directory oder durch Verwendung von gMSA bzw. Konten ohne Kennwortablauf mit entsprechendem Schutz. Ein gesperrtes DW-Konto bleibt sonst oft tagelang unbemerkt.
Heute
Ereignis 31552 und StandardDatasetMaintenance gibt es auch in Operations Manager 2019, 2022 und 2025. Die beschriebenen Ursachen sind nach wie vor die häufigsten – insbesondere nach dem Import großer Management Packs.