Wer seine ETL-Projekte in die Azure-Cloud migrieren, aber nicht auf die erprobten „old-school“ SSIS-Pakete verzichten möchte, hat bekanntlich die Möglichkeit, SSIS auf Azure zu benutzen. Azure besteht hierbei – ganz wie gewohnt – auf eine Datenbank für die SSISDB, und auf die Paketbereitstellung in einen gleichnamigen Integration-Services-Katalog.
Dieser Katalog hat zwei ganz wesentliche Eigenschaften, mit denen letztlich die Datenmenge kontrolliert wird:
Maximale Anzahl der Versionen pro Projekt – wie viele alte Projektversionen soll sich die SSISDB merken, wenn ich mein Projekt weiterentwickle und neu bereitstelle?
Beibehaltungsdauer (Tage) – wie lange soll die Historie meiner Paketausführungen gespeichert werden, damit ich mir die entsprechenden Logging-Daten, z.B. im Ausführungsbericht, anschauen kann?
Damit einhergehend gibt es noch die Eigenschaften Alte Versionen regelmäßig entfernen resp. Protokolle regelmäßig bereinigen, die auf True stehen sollten, damit die oben genannten Eigenschaften angewandt werden.
Alles klar, das geht ganz einfach im Management Studio über das Kontextmenü (oder T-SQL), schnell erledigt, Freude kommt auf.
Doch nach einigen Tagen/Wochen/Monaten (je nach Workload) der Schock: die SSISDB wächst und wächst und wächst und… Was ist denn da los?
Nun ja, auf einem klassischen System wird automatisch ein SSIS Maintenance Job angelegt, der anhand der eingestellten Eigenschaften gespeicherte System-Prozeduren nächtlich aufruft und die Daten bereinigt – quasi ein vollautomatischer Saugroboter. Doch auf Azure gibt es ja leider keinen SQL Agent, somit keine Jobs, und somit auch keine automatische Maintenance.
Wir müssen also selbst Hand anlegen und den Wischmopp rausholen – mit einer Azure Data Factory Pipeline (genau genommen organisieren wir also eine Putzfrau, die den Wischmopp für uns zu einer vereinbarten Zeit schwingt).
Zum Glück ist es relativ einfach: Wir benötigen genau zwei gespeicherte Prozeduren und müssen diese nacheinander aus der Pipeline aufrufen. Die Prozeduren heißen
- [internal].[cleanup_server_retention_window] (für die Bereinigung der alten Logging-Daten)
- [internal].[cleanup_server_project_version] (für die Bereinigung der alten Projektversionen)
Um die Prozeduren aufzurufen, ziehen wir ganz einfach zweimal den Task „Stored Procedure“ unter dem Punkt „General“ in die Pipeline, der wir z.B. den Namen „SSISDB Maintenance“ geben. Die beiden Tasks wiederum können am besten sprechend benannt werden, z.B. „Clean SSISDB Log“ und „Clean SSISDB Versions“.
Im Reiter General der Tasks werden jeweils die üblichen Retry-Bedingungen konfiguriert, unter „SQL Account“ wird als Linked Service der Verweis auf die SSISDB eingestellt. „User properties“ sind hier irrelevant, interessant ist natürlich vor allem der Reiter „Stored Procedure“. Zum Glück ist es ganz simpel: einfach in beide Tasks an dieser Stelle jeweils den oben genannten Namen der Prozedur eintragen – fertig!
Damit die Putzfrau auch kommt, wird am besten noch ein Trigger konfiguriert, der zu einer Zeit läuft, zu der die SSISDB möglichst wenig belastet wird. Somit funktioniert dann die SSISDB wieder so, wie wir es aus den guten alten Zeiten gewohnt sind.