Ein gängiges Szenario für das produktive Ausführen von SSIS-Paketen ist die Ausführung im SQL Server Agent.
Für Verwirrung sorgt dabei häufig eine Fehlermeldung, dass der Knoten aufgrund eines Verschlüsselungsfehlers nicht geöffnet werden kann. Falls ein Paket nicht ausgeführt werden konnte, führt das leicht auf eine falsche Fährte.
Dieser Fehler ist nämlich nicht Ursache dafür, dass das Paket auf einen Fehler gelaufen ist. Dieser Fehler tritt in folgender Situation auf:
- Das Paket wird durch einen User geöffnet, der das Paket nicht gespeichert hat.
- Das Paket enthält eine Verbindung, die ein Passwort gesetzt hat – auch wenn diese Verbindung gar nicht verwendet wird (weil die Verbindungsinformationen z.B. durch eine Konfigurationsdatei o.ä. überschrieben werden.)
- Die Einstellungen des Pakets (ProtectionLevel) stehen auf „encrypt sensitive with user key“
Dann versucht Integration Services nämlich alle sensitiven Daten – das ist vor allem das Password in einer Verbindung – mit dem aktuellen User zu entschlüsseln – und scheitert und protokolliert den Fehler. Integration Services bricht dann aber nicht die Verarbeitung ab, sondern verwendet dann ein leeres Passwort. In meinem Beispiel-Screenshot war der tatsächliche Fehler eine (bewusst herbeigeführte) Division durch Null. Diesen Fehler sieht man ganz am Ende.
Im produktiven Umfeld ist das im Normalfall kein Problem, da normalerweise Integrierte Sicherheit (also Anmeldung mit dem Windows-User) verwendet wird oder die Verbindungsinformationen (Server, Datenbank und eben auch User und Passwort) extern verwaltet werden (also in einem Config-File oder im SQL Server Agent etc.). Letzteres hat den Grund, dass man Pakete auf dem Produktivsystem ohne Veränderung (d.h. ohne Öffnen im Visual Studio) aus dem Testsystem installieren will.
Somit kann man einfach die Einstellung auf „Do not save sensitive“ stellen. Dann tritt der oben beschriebene Fehler nicht auf und die verwirrende Fehlermeldung in der Task History des SQL Server Agent taucht nicht auf. In meinem Beispiel erkennt man die Division durch 0 jetzt viel besser:
Um allerdings eine gute Grundlage für die Fehlersuche zu haben, reicht auch die Anzeige im SQL Server Agent nicht aus. Man sollte besser Logging aktivieren – (dazu vielleicht später mehr 🙂 )