Betriebsdatenbank und Data Warehouse sollen auf neue Hardware. Muss beides gleichzeitig passieren? Welche Reihenfolge ist sinnvoll? Ein Leitfaden für die Planung des Umzugs.
Die Betriebsdatenbank (OperationsManager) und das Data Warehouse (OperationsManagerDW) laufen gemeinsam auf einem SQL Server und sollen auf neue Hardware umziehen. Für beide Datenbanken gibt es bewährte Anleitungen – offen bleibt oft die Frage: Was zuerst? Und muss alles gleichzeitig passieren?
Die Antwort vorweg
Die beiden Datenbanken lassen sich unabhängig voneinander verschieben. Es spricht nichts dagegen, an einem Tag die Betriebsdatenbank und an einem anderen das Data Warehouse umzuziehen. Im Gegenteil: Getrennte Wartungsfenster verringern das Risiko und erleichtern die Fehlersuche.
Eine bewährte Reihenfolge:
- Zuerst das Data Warehouse. Fällt es kurz aus, puffern die Management Server die Daten und schreiben sie nach dem Umzug nach. Die Überwachung läuft weiter.
- Danach die Betriebsdatenbank. Während dieses Umzugs steht SCOM vollständig – dieser Teil sollte gut vorbereitet und kurz sein.
Der grundsätzliche Ablauf (je Datenbank)
- Vorbereiten: Neuer SQL Server mit gleicher oder unterstützter Version, passender Sortierung (Collation), aktivierter CLR-Integration (für die Betriebsdatenbank) und ausreichend Ressourcen.
- Dienste stoppen: Auf allen Management Servern die SCOM-Dienste stoppen (System Center Data Access Service, System Center Management Configuration, Microsoft Monitoring Agent).
- Sichern und wiederherstellen: Vollsicherung der Datenbank, Wiederherstellung auf dem neuen Server.
- Logins und Berechtigungen: SQL-Logins für die SCOM-Dienstkonten anlegen und den Datenbankbenutzern wieder zuordnen.
- Verweise aktualisieren: Auf allen Management Servern den Datenbankserver in der Registry anpassen und die in der Microsoft-Dokumentation genannten Tabellen in der Betriebsdatenbank bzw. im Data Warehouse aktualisieren, in denen der Servername gespeichert ist. Beim Data Warehouse zusätzlich die Konfiguration von Reporting Services anpassen.
- Service Broker prüfen: Für die Betriebsdatenbank muss der SQL Service Broker aktiviert sein.
- Dienste starten und prüfen: Ereignisprotokolle der Management Server auf Verbindungsfehler kontrollieren, Konsole und Berichte testen.
Achtung
Die genauen Registry-Pfade und Tabellen unterscheiden sich zwischen den SCOM-Versionen. Arbeiten Sie die offizielle Anleitung „How to move the Operations Manager databases“ für Ihre Version Schritt für Schritt ab und dokumentieren Sie jede Änderung.
Tipps aus der Praxis
- Alias statt Servername: Ein DNS- oder SQL-Alias für den Datenbankserver macht künftige Umzüge deutlich einfacher – dann ändert sich nur der Alias.
- Testlauf: Den Ablauf vorher in einer Testverwaltungsgruppe durchspielen.
- Rückfallplan: Den alten SQL Server erst abschalten, wenn alles einige Tage stabil läuft.
Heute
Der Ablauf gilt grundsätzlich für Operations Manager 2019, 2022 und 2025. Bei einem gleichzeitigen Upgrade von SQL Server prüfen Sie die unterstützten SQL-Versionen Ihrer SCOM-Version, bevor Sie den neuen Server aufsetzen.