SSMS 22 kann keine Wartungspläne mehr öffnen – und warum das eigentlich eine gute Nachricht ist

Von /

Kurzfassung: Wer mit SQL Server Management Studio 21 oder 22 Wartungspläne auf älteren SQL-Server-Instanzen (z. B. 2016/13.x) bearbeiten will, steht aktuell im Regen. Microsoft hat mit dem Umstieg auf Visual Studio 2022 die SSIS-Komponenten – und damit den Maintenance Plan Designer – zunächst komplett aus SSMS 21 entfernt. In SSMS 22 sind sie als optionaler Zusatz zurück, funktionieren aber bei vielen Installationen schlicht nicht. Der Workaround für den Moment: SSMS 20 parallel installieren. Die strategisch saubere Lösung: Weg von Wartungsplänen, hin zu Ola Hallengrens Maintenance Solution. Dieser Beitrag zeigt Dir beides – das Tooling-Problem und den Weg raus.

Das Problem: SSMS 21/22 und die verschwundenen Wartungspläne

Wer in den letzten Monaten SSMS 21 oder 22 installiert hat und anschließend einen bestehenden Wartungsplan öffnen wollte, kennt das Bild: Entweder ist der Menüpunkt gar nicht da, oder beim Öffnen erscheint ein wenig hilfreicher Dialog mit der Meldung „Value cannot be null“ und einem Stacktrace, der auf Microsoft.DataTransformationServices.VsIntegration.DtsDesignerService.OpenDesigner zeigt.

Das betrifft auch – und das ist für viele Bestandssysteme ärgerlich – Instanzen eines älteren SQL Server 2016 (Version 13.x). Der Server ist nicht das Problem. Das Problem sitzt in SSMS.

Was Microsoft mit SSMS 21 geändert hat

Mit SSMS 21 hat Microsoft das Management Studio auf Visual Studio 2022 als Shell umgestellt. Im Rahmen dieser Umstellung wurde Folgendes beschlossen: Die SSIS-Unterstützung (inklusive Import/Export-Wizard und Wartungspläne) wird beim ersten Release von SSMS 21 nicht mitgeliefert. Microsoft hat das selbst als bewusste Entscheidung kommuniziert – man wollte Qualität und Stabilität der SSIS-Integration nicht zum Release-Termin opfern und plante, die Komponente später nachzuliefern.

Der Haken: Wartungspläne sind unter der Haube SSIS-Pakete. Kein SSIS = keine Wartungspläne. Microsoft hat für diesen Fall empfohlen, SSMS 20 parallel zu SSMS 21 zu installieren.

Was in SSMS 22 passiert ist

In SSMS 22 ist die SSIS-Unterstützung zurück – aber als optionale Komponente. Ein simples Upgrade reicht also nicht, Du musst den Installer (vs_SSMS.exe) erneut ausführen, Modify wählen und die SSIS-Komponenten aktiv hinzuwählen. SSAS wird dabei automatisch mitinstalliert.

Und selbst wenn Du das machst, gibt es aktuell Berichte aus der Community und von den Microsoft-Q&A-Foren, dass der Designer trotzdem nicht sauber läuft. Manche Updates reparieren die Funktion, das darauf folgende Update bricht sie wieder. Der Fehler „Value cannot be null“ beim Öffnen eines bestehenden Plans ist der prominenteste Vertreter.

Die drei praktischen Optionen

Option 1: SSMS 20 parallel installieren (Sofortlösung)

Das ist die pragmatische Lösung für akute Fälle. SSMS 20 läuft problemlos neben SSMS 21/22 auf derselben Maschine, der Maintenance Plan Designer funktioniert dort verlässlich. Download über die offizielle Microsoft-Seite, Installation dauert ein paar Minuten, fertig.

Vorteil: Keinerlei Änderung an den Bestandssystemen der Kunden. Nachteil: Du hast jetzt drei SSMS-Versionen auf der Workstation.

Option 2: SSMS 22 mit nachinstallierten SSIS-Komponenten versuchen

  1. vs_SSMS.exe starten (entweder aus dem Download-Cache oder neu von Microsoft holen)
  2. Modify wählen
  3. Die SSIS-Komponente aktivieren, SSAS kommt automatisch mit
  4. Installation durchlaufen lassen und SSMS neu starten

Wenn es funktioniert: großartig. Wenn „Value cannot be null“ kommt: zurück zu Option 1 oder direkt zu Option 3.

Option 3: Wartungspläne ablösen

Das ist die Option, die ich meinen Kunden inzwischen konsequent empfehle. Begründung kommt gleich – erst einmal zur eigentlichen Frage: Womit ersetzt man Wartungspläne?

Warum Wartungspläne sowieso kein guter Plan sind

Wartungspläne wurden erfunden, als DBAs noch klicken sollten statt zu skripten. Sie haben ein paar strukturelle Nachteile, die unabhängig vom aktuellen SSMS-Drama sind:

  • Versteckte Komplexität: Ein Wartungsplan ist ein SSIS-Paket. Man sieht die GUI, aber was tatsächlich ausgeführt wird, ist nicht unmittelbar nachvollziehbar.
  • Grobe Steuerung beim Index-Rebuild: Die eingebaute „Index neu erstellen“-Task macht das für alle Indizes ab einem Fragmentierungswert – unabhängig von Größe, Typ oder tatsächlicher Notwendigkeit. Das kostet Wartungsfenster und Transaktionsprotokoll.
  • Keine vernünftige Logik bei „Full oder Diff?“: Wer jemals die Meldung „BACKUP LOG cannot be performed because there is no current database backup“ nach einem Recovery-Model-Wechsel gesehen hat, weiß, was ich meine.
  • Schlechte Versionierbarkeit: Wartungspläne lassen sich nicht sinnvoll in Git verwalten. Man hat sie oder man hat sie nicht.
  • Tooling-Abhängigkeit: Genau das, was wir gerade erleben. Microsoft zieht den Designer aus SSMS raus, und die Pläne sind nicht mehr bearbeitbar – ohne dass sich am Server irgendetwas geändert hätte.

Die Konsequenz: Wartungspläne sind für Bestandssysteme ein Risiko, das man bei nächster Gelegenheit abbaut. Die „nächste Gelegenheit“ ist typischerweise genau jetzt, wenn man sie sowieso nicht mehr editieren kann.

Die Alternative: Ola Hallengrens SQL Server Maintenance Solution

Ola Hallengren ist ein schwedischer DBA, der seit Jahren ein freies T-SQL-Skriptpaket pflegt, das als De-facto-Standard für Backups, Integritätschecks und Indexwartung in der SQL-Server-Welt gilt. Die Lösung läuft auf SQL Server 2008, 2008 R2, 2012, 2014, 2016, 2017, 2019, 2022, 2025 sowie Azure SQL Database und Azure SQL Managed Instance. Deckt also alles ab, was Du im SME-Bestand in Norddeutschland realistisch antriffst.

Sie besteht aus wenigen Stored Procedures in der master-Datenbank plus vorkonfigurierten SQL-Server-Agent-Jobs. Keine SSIS-Abhängigkeit, keine GUI, kein Designer-Drama. Nur T-SQL.

Die vier Bausteine

  • CommandExecute – interne Helper-Prozedur, die alle anderen nutzen. Führt Befehle aus und schreibt optional in die Log-Tabelle.
  • DatabaseBackup – kümmert sich um Full-, Differential- und Log-Backups.
  • DatabaseIntegrityCheck – führt DBCC CHECKDB mit konfigurierbaren Optionen aus.
  • IndexOptimize – kümmert sich um Index-Reorganisation/Rebuild und Statistik-Updates. Das Herzstück, weil es der Task ist, der bei Wartungsplänen am schlechtesten implementiert ist.

Dazu kommt die optionale Tabelle CommandLog, in die jede einzelne ausgeführte Aktion inklusive Laufzeit, Fehlernummer und Meldung protokolliert wird. Das ist Gold wert, wenn man hinterher analysieren will, warum der Wartungslauf über das Fenster hinausgegangen ist.

Installation in 5 Minuten

  1. Skript MaintenanceSolution.sql von ola.hallengren.com/downloads.html herunterladen
  2. In SSMS öffnen (mit welcher Version auch immer – das Skript hat keine SSIS-Abhängigkeit)
  3. Etwa in Zeile 27 die Variable @BackupDirectory auf das gewünschte Backup-Verzeichnis setzen
  4. Gegen die Zielinstanz ausführen
  5. Fertig. Die Prozeduren sind angelegt, und es stehen mehrere vorkonfigurierte SQL-Server-Agent-Jobs zur Verfügung.

Die Jobs, die das Setup-Skript anlegt, decken die typischen Standardfälle ab:

  • DatabaseBackup - SYSTEM_DATABASES - FULL
  • DatabaseBackup - USER_DATABASES - FULL
  • DatabaseBackup - USER_DATABASES - DIFF
  • DatabaseBackup - USER_DATABASES - LOG
  • DatabaseIntegrityCheck - SYSTEM_DATABASES
  • DatabaseIntegrityCheck - USER_DATABASES
  • IndexOptimize - USER_DATABASES
  • CommandLog Cleanup (räumt die Logtabelle auf)

Die Jobs sind angelegt, aber nicht geplant. Du musst ihnen selbst Schedules zuweisen, das ist Absicht – es gibt kein sinnvolles „one size fits all“.

IndexOptimize im Detail – der wichtigste Baustein

Wartungspläne scheitern in der Praxis meistens bei der Indexwartung. Genau deshalb lohnt es sich, diesen Teil besser zu verstehen.

Die Logik

IndexOptimize nutzt die dynamische Management-View sys.dm_db_index_physical_stats, um für jeden Index die durchschnittliche Fragmentierung und die Seitenanzahl zu bestimmen. Dann teilt es Indizes in drei Gruppen ein:

  • Low: unterhalb von @FragmentationLevel1 (Default: 5 Prozent)
  • Medium: zwischen @FragmentationLevel1 und @FragmentationLevel2 (Default: 5 bis 30 Prozent)
  • High: oberhalb von @FragmentationLevel2 (Default: über 30 Prozent)

Für jede Gruppe kannst Du mehrere Maßnahmen angeben, die in der angegebenen Reihenfolge probiert werden. Wenn die erste nicht geht (z. B. weil die Edition kein Online-Rebuild erlaubt oder der Index-Typ es nicht unterstützt), wird die nächste versucht.

Kleine Indizes werden per Default ignoriert: Alles mit weniger als 1.000 Pages wird übersprungen. Das ist beabsichtigt, weil Fragmentierung in kleinen Indizes meist nicht kontrollierbar ist – die liegen auf Mixed Extents, und dort bringt ein Rebuild schlicht nichts. Wer das ändern will, nutzt den Parameter @MinNumberOfPages.

Ein praxistauglicher IndexOptimize-Aufruf

So sieht ein Aufruf aus, den ich Kunden typischerweise in den Agent-Job schreibe:

EXECUTE master.dbo.IndexOptimize
    @Databases              = 'USER_DATABASES',
    @FragmentationLow       = NULL,
    @FragmentationMedium    = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
    @FragmentationHigh      = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
    @FragmentationLevel1    = 5,
    @FragmentationLevel2    = 30,
    @UpdateStatistics       = 'ALL',
    @OnlyModifiedStatistics = 'Y',
    @LogToTable             = 'Y';

Was hier passiert:

  • Low-Fragmentierung wird ignoriert (NULL). Keine Aktion, keine verschwendete I/O.
  • Medium-Fragmentierung wird erst reorganisiert (online, leichtgewichtig), wenn das nicht geht, wird online rebuilt, notfalls offline.
  • High-Fragmentierung springt direkt zum Rebuild, weil Reorganize bei stark fragmentierten Indizes meist nicht mehr sinnvoll ist.
  • Statistiken werden für alle Indizes aktualisiert, aber @OnlyModifiedStatistics = 'Y' sorgt dafür, dass nur die Statistiken angefasst werden, deren zugrundeliegende Daten sich seit dem letzten Update tatsächlich geändert haben. Das spart auf großen Datenbanken massiv Zeit.
  • @LogToTable = 'Y' schreibt jeden einzelnen Befehl in dbo.CommandLog in der master-Datenbank.

Hinweise aus der Praxis

  • Online-Rebuild setzt Enterprise Edition voraus. Auf Standard Edition fällt die Lösung automatisch auf Offline-Rebuild zurück, genau dafür ist die Liste der Operationen da. Bei Express gibt es keinen SQL Server Agent – dann musst Du mit Windows Task Scheduler und sqlcmd arbeiten.
  • @MaxDOP lässt sich pro IndexOptimize-Aufruf setzen, damit der Wartungslauf nicht die gesamte CPU belegt.
  • @SortInTempdb = 'Y' verschiebt die Sortieroperationen beim Rebuild ins tempdb. Macht auf Systemen mit schnellem tempdb-Storage und knappem User-DB-Storage Sinn.

DatabaseBackup – die interessantesten Parameter

Für Backups ist das Skript ebenso flexibel. Zwei Muster, die ich regelmäßig verwende:

Standard-Full-Backup mit Komprimierung und Checksum

EXECUTE master.dbo.DatabaseBackup
    @Databases   = 'USER_DATABASES',
    @Directory   = 'D:\SQLBackup',
    @BackupType  = 'FULL',
    @Compress    = 'Y',
    @Checksum    = 'Y',
    @CleanupTime = 168,
    @LogToTable  = 'Y';

@CleanupTime ist in Stunden angegeben – 168 bedeutet, dass Backups älter als sieben Tage automatisch gelöscht werden. Aber Vorsicht: Die Cleanup-Logik löscht nur Dateien in der vom Skript selbst angelegten Verzeichnisstruktur. Manuell verschobene Backups bleiben liegen.

„Smart Differential“ – dynamisch zwischen Diff und Full entscheiden

Ola hat das Skript irgendwann um eine nette Logik erweitert: Wenn mehr als ein konfigurierbarer Prozentsatz der Datenbank seit dem letzten Full geändert wurde, wird automatisch ein Full statt eines Diff gezogen. Hintergrund ist, dass Diffs jenseits eines gewissen Change-Anteils ihren Zweck (schnelle Recovery) verlieren.

EXECUTE master.dbo.DatabaseBackup
    @Databases        = 'USER_DATABASES',
    @Directory        = 'D:\SQLBackup',
    @BackupType       = 'DIFF',
    @ChangeBackupType = 'Y',
    @ModificationLevel = 50,
    @Compress         = 'Y',
    @Checksum         = 'Y',
    @LogToTable       = 'Y';

Ergebnis: Wenn mehr als 50 Prozent der Datenbank seit dem letzten Full modifiziert wurden, wird daraus automatisch ein Full. Sehr praktisch für Systeme, wo man nicht genau weiß, wie viel Schreibvolumen tatsächlich anfällt.

Datenbankauswahl – Keywords und Ausschlüsse

Die @Databases-Parameter akzeptieren Keywords (SYSTEM_DATABASES, USER_DATABASES, ALL_DATABASES, AVAILABILITY_GROUP_DATABASES), Wildcards mit % und Ausschlüsse mit -. Also zum Beispiel:

@Databases = 'USER_DATABASES, -ReportingArchive, -Temp%'

Sichert alle User-Datenbanken außer ReportingArchive und allem, was mit Temp anfängt. Bei Wartungsplänen musstest Du dafür klicken, klicken, klicken. Hier ist es eine Zeile.

DatabaseIntegrityCheck – die oft vernachlässigte Pflicht

DBCC CHECKDB ist die einzige verlässliche Möglichkeit, Datenbankkorruption zu entdecken, bevor der Kunde sie entdeckt. Bei Wartungsplänen wird das regelmäßig „weggeklickt“, weil es lange dauert. Ola macht es konfigurierbar:

EXECUTE master.dbo.DatabaseIntegrityCheck
    @Databases     = 'USER_DATABASES',
    @CheckCommands = 'CHECKDB',
    @LogToTable    = 'Y';

Für sehr große Datenbanken lässt sich der Check aufteilen – CHECKALLOC, CHECKTABLE, CHECKCATALOG können einzeln ausgeführt und über mehrere Wartungsfenster verteilt werden. Aber ehrlich: Für die typische KMU-Datenbank reicht der einfache CHECKDB-Aufruf einmal pro Woche.

CommandLog – Wartungslogs, die man tatsächlich auswerten kann

Der Parameter @LogToTable = 'Y' sollte bei allen Jobs gesetzt sein. Dann landet jede ausgeführte Aktion in master.dbo.CommandLog. Auswertung, um Fehler der letzten 24 Stunden zu sehen:

SELECT
    ID,
    DatabaseName,
    CommandType,
    StartTime,
    EndTime,
    DATEDIFF(SECOND, StartTime, EndTime) AS DauerSek,
    ErrorNumber,
    ErrorMessage
FROM master.dbo.CommandLog
WHERE StartTime > DATEADD(HOUR, -24, GETDATE())
  AND ErrorNumber <> 0
ORDER BY StartTime DESC;

Mit dieser einen Query weißt Du, ob in der vergangenen Nacht irgendwo etwas schiefgegangen ist. Das ist deutlich verlässlicher als Agent-Job-History-Dialoge.

Berechtigungen und Sicherheit

Ola Hallengrens Lösung verwendet kein xp_cmdshell. Das ist wichtig, weil viele Sicherheits-Audits in KMU die Aktivierung von xp_cmdshell als Finding markieren. Die Jobs laufen standardmäßig unter dem SQL Server Agent Dienstkonto, das sowieso sysadmin-Rechte braucht.

Wenn Du ad-hoc-Aufrufe durch Nicht-Admins erlauben willst, brauchen die Nutzer lediglich EXECUTE auf die jeweilige Prozedur, VIEW DEFINITION auf CommandExecute und CommandLog sowie VIEW SERVER STATE und db_owner auf den Zieldatenbanken – kein Serveradmin notwendig.

Migrationspfad: Vom Wartungsplan zu Hallengren

Wenn Du bei einem Bestandskunden einen bestehenden Wartungsplan ablösen willst, ist das Vorgehen simpel:

  1. Ist-Zustand dokumentieren: Notiere die Schedules der bestehenden Wartungspläne und die dort konfigurierten Aktionen (Backup-Ziel, Recovery-Modi, welche Datenbanken).
  2. Hallengren-Skript einspielen: MaintenanceSolution.sql mit angepasstem @BackupDirectory gegen die Instanz laufen lassen.
  3. Agent-Jobs konfigurieren: Den vorgenerierten Jobs sinnvolle Schedules geben. Typisches Muster: Full nachts, Diff alle sechs Stunden, Log alle 15 Minuten (bei Full Recovery), IntegrityCheck am Wochenende, IndexOptimize an den Werktagen nachts.
  4. Einen Lauf verifizieren: Über dbo.CommandLog prüfen, dass alles fehlerfrei durchgelaufen ist.
  5. Alte Wartungspläne deaktivieren (nicht sofort löschen). Eine Woche Parallelbetrieb gibt Sicherheit.
  6. Nach erfolgreicher Parallelphase die alten Wartungspläne entfernen. Dann ist der Server sauber – und das SSMS-Editor-Problem betrifft Dich nicht mehr.

Fazit

Der aktuelle SSMS-22-Bug mit Wartungsplänen ist ärgerlich – aber er ist auch ein guter Anlass, eine Technologie hinter sich zu lassen, die schon lange ihre beste Zeit hinter sich hat. Wartungspläne sind grafisch erstellte SSIS-Pakete, die in der Praxis schwer zu warten, schlecht zu versionieren und mittlerweile sogar schwer zu editieren sind. Die Alternative ist vier T-SQL-Skripte groß, kostet nichts und gibt Dir deutlich feinere Kontrolle.

Wer heute ein neues Produktivsystem aufsetzt und dort Wartungspläne konfiguriert, macht sich die eigene Zukunft unnötig schwer. Wer Bestandssysteme betreut, sollte die Migration beim nächsten Wartungsfenster mit einplanen – der Aufwand ist überschaubar, der Gewinn an Kontrolle und Stabilität erheblich.

Struktur vor KI. Und in diesem Fall: Struktur vor GUI.

Wenn Du im Norddeutschen Raum einen SQL-Server-Bestand betreibst und Dir bei der Ablösung von Wartungsplänen Unterstützung wünschst – von der Analyse der bestehenden Jobs bis zum sauberen Rollout der Hallengren-Lösung inklusive Monitoring –, melde Dich gern. Das ist in wenigen Stunden erledigt, und Du hast danach ein System, das Du die nächsten zehn Jahre nicht mehr anfassen musst.

Ähnliche Beiträge

Nach oben scrollen