none
SSIS SQL Server 2014 - Keine Programmausführung RRS feed

  • Frage

  • Hallo zusammen,
    ich habe einen SQL Server 2014 Standard in dem nachts ein SQL Server Job läuft, der ein SSIS-Packet startet. In diesem SSIS-Packet wird ein Zip-File von einem FTP Server in ein Verzeichnis runtergeladen und sollen danach entpackt werden. Das SSIS-Packet ist ein SQL Server 2008 SSIS Packet, das seither ohne Probleme funktioniert hat.

    Das herunterladen des Files funktioniert auch mit dem SQL 2014 einwandfrei. Lediglich das Entpacken des Files funktioniert nicht. Es gibt keine Fehlermeldung und auch in der Jobhistorie wird der Job als "erfolgreich gelaufen" angezeigt. Allerdings fehlen die entpackten Dateien in dem Verzeichnis. Eine Umwandlung des SSIS-Pakets in ein 2014er SSIS-Packet brachte leider keine Besserung.

    Lasse ich das SSIS-Packet isoliert (wird also nicht vom Job angestoßen) laufen, funktioniert sowohl das Runterladen als auch das Entpacken einwandfrei.

    Als Besonderheit muss ich noch anmerken, dass das SSIS-Package auf einem zweiten Server liegt. Das war allerdings schon immer so.

    @Edit: Achja, es wird mit Hilfe des Programms 7za entpackt, das mit den entsprechenden Parametern vom SSIS-Paket aus aufgerufen wird.

    Ich bin für Lösungen, Tipps, Tricks und zwischenzeitlich sogar für Vermutungen dankbar.


    Viele Grüße Holger M. Rößler


    Dienstag, 13. Oktober 2015 12:19

Antworten

Alle Antworten

  • Hallo Holger,

    wenn es so geht, aber nicht als SQL Agent Job, dann liegt es gerne mal an den Berechtigungen des Agent Service Accounts. Leg mal einen Agent Proxy Account an, z.B. mit Deinen Windows Anmeldedaten und lass den Job dann mit dem Proxy laufen; wenn es dann immer noch nicht geht, liegt es schon mal nicht an den Berechtigungen; siehe Erstellen eines Proxys für den SQL Server-Agent 


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 13. Oktober 2015 12:46
  • Hallo Olaf,
    vielen Dank für deine Antwort und deinen Vorschlag.

    Hat aber leider nicht funktioniert. Gleiche Auswirkungen!

    Der SQL Server Agent Account läuft schon bereits mit den Berechtigungen eines AD-Users, der auf beiden Servern über Admin-Rechte verfügt. Zudem führe ich das SSIS Paket isoliert mit dem gleichen Benutzer aus.


    Viele Grüße Holger M. Rößler



    Dienstag, 13. Oktober 2015 13:11
  • Hallo Holger,

    wie schaut es mit der Laufzeitumgebung aus?  Ich bin mal über eine Geschichte gestolpert, wo das manuelle Ausführen in 32bit Modus erfolgte, der Aufruf via Agent dann aber über 64 bit. Vielleicht liegt da irgendwo "der Hund begraben".  Bzw.  32 oder 64 bit Version von 7zip.   Guck mal in den Job Einstellungen im Tab Execution Options was da bzgl. der Runtime eingestellt ist und experimentiere da mal mit.

    Anonsten hab ich auch keine Idee mehr. 

    EDIT:  Oder ggf . mal gucken, was CozyRock gebaut hat: http://www.cozyroc.com/ssis/zip-task  oder dieses Codeplex Projekt betrachten:  http://taskunzip.codeplex.com/ 


    May you never suffer the sentiment of spending a day without any purpose


    • Bearbeitet Dirk Hondong Donnerstag, 15. Oktober 2015 19:27
    Donnerstag, 15. Oktober 2015 19:21
  • Hallo Holger,

    um dem Problem auf die Spur zu kommen, solltest Du mal die Ausführung des Packages ausführlich mit protokollieren lassen, um zu sehen, wann was getan oder eben nicht getan wird; siehe
    Implementing Logging in Packages
    Integration Services (SSIS) Logging
    Enable Logging for Package Execution on the SSIS Server


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 16. Oktober 2015 06:43
  • Hi Holger,

    hab auch noch zwei Punkte:

    Wie wird 7zip denn aufgerufen? Direkt aus dem ExecuteTask oder gewrapped in einer CommandShell?

    Thema Working Directory: ich hatte schon mal den Effekt (keine Ahnung warum) das es mit einem abschließenden Backslash ging, ohne jedoch nicht.

    Auf jeden Fall, wie Olaf erwähnt hat, Logging aktivieren.


    May you never suffer the sentiment of spending a day without any purpose

    Freitag, 16. Oktober 2015 07:05
  • Hallo zusammen,
    hier sind ja wirklich einige richtig gute Ideen zusammengekommen. Vielen Dank dafür an Euch :)

    Ich habe die Fehlerursache gefunden: Das SSIS Packet holt sich einige seiner Konfigurationeinstellungen per PackageConfigurations. In einer dieser Configurations war ein ConnectionString mit einem veralteten Provider (SQL Server 2008). Kaum hatte ich den ConnectionString aktuallisiert, hat das Entpacken wieder funktioniert.

    Hier stelle ich mir die Frage, warum ich keinen Fehler erhalten habe, sondern überall sogar "grün" war.  Und vor allem...wieso verhindert ein nicht aktueller ConnectionString das ausführen eines Programmes, das damit null komma nichts zu tun hat... :-/

    Nochmals vielen Dank an Euch alle für eure Hilfe.


    Viele Grüße Holger M. Rößler

    Freitag, 16. Oktober 2015 11:46
  • Hallo Holger,
    die Antworten solltest Du erfahren, wenn Du die Protokollierung aktiviert hast. Von hierher ist es schwierig den Ablauf des Pakets zu sehen.

    Vielleicht auch interessant für die Protokollierung:
    http://www.insidesql.org/blogs/cmu/sql_server/task-prozess-ausfuehren-mit-ereignishandler
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Montag, 19. Oktober 2015 12:37
    Beantworter
  • Hallo Christoph,
    vielen Dank für dein Feedback.

    Durch die Protokollierung (siehe Vorschlag von Olaf) ist es mir auch aufgefallen. Aber wenn etwas nicht funktioniert, erwarte ich eigentlich ein Fehler vom Package und kein "Stillschweigen". Es kann einfach nicht sein, dass ich da unmengen an Logs durchsehen muss bzw. nicht einmal auf einen Fehler hingewiesen werde.


    Viele Grüße Holger M. Rößler

    Dienstag, 20. Oktober 2015 09:09
  • Das kann ich verstehen.
    Nur wenn Du das fehlerhafte Paket nochmal mit der Protokollierung laufen lässt, wirst Du verstehen, warum der Fehler nicht so gravierend war, dass das gesamte Paket mit Fehler beendet wurde.

    Vielleicht werden ja Fehler an einer Stelle im Paket toleriert?

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 20. Oktober 2015 09:52
    Beantworter
  • Ich habe die Fehlerursache gefunden: Das SSIS Packet holt sich einige seiner Konfigurationeinstellungen per PackageConfigurations. In einer dieser Configurations war ein ConnectionString mit einem veralteten Provider (SQL Server 2008).

    Ich musste gerade grinsen. Ausgerechnet heute hatte ich auch so einen Fall.  Schau mal nach, ob nicht ein einzelner Task so konfiguriert ist, dass hier ein höherer Fehlercount möglich ist oder so.


    May you never suffer the sentiment of spending a day without any purpose

    Freitag, 23. Oktober 2015 18:10