none
SSIS (Status KILLED/ROLLBACK) Paket beenden RRS feed

  • Frage

  • Hallo Community,

    ich sitze hier vor einer SQL Server 2008 R2 (SP2) - 10.50.4339.0 Instanz.

    Das Problem hier ist ein Prozess im Status "KILLED/ROLLBACK". Dieser Prozess ist nach dem was mir gesagt wurde schon seit 24 Januar in diesem Zustand. Das SSIS Paket wurde wohl auch schon beendet.

    Welche Möglichkeiten habe ich denn diesen Prozess doch noch zu beenden?

    Vielen Dank
    Gruß
    Andreas

    Donnerstag, 9. Februar 2017 08:58

Antworten

  • Der Wait-Type 0x006D steht für OLEDB. Das wiederum wird von verschiedenen Systemen verwendet.

    Für den lokalen SQL Server ist das ähnlich wie ein Preemptive Wait außerhalb der Kontrolle.

    Bzw bei Dir steht es ja direkt dabei: SSIS ist der Auslöser. Da Dein Paket also längst beendet sein soll, kannst Du da nicht mehr tun - außer dass ich nochmal prüfen würde, ob wirklich kein dazugehöriger Prozess in Windows mehr aktiv ist.

    Wenn nicht, musst Du tatsächlich den Server neu starten, um die Stabilität zu gewährleisten.

    viel Erfolg

    Andreas


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com


    • Bearbeitet Andreas.WolterMicrosoft employee Donnerstag, 9. Februar 2017 10:00 korrigiert, bzw abgekürzte Lösung, da SSIS ja direkt dabei steht als Auslöser
    • Als Antwort markiert ABurger Montag, 6. März 2017 10:25
    Donnerstag, 9. Februar 2017 09:54

Alle Antworten

  • Der Wait-Type 0x006D steht für OLEDB. Das wiederum wird von verschiedenen Systemen verwendet.

    Für den lokalen SQL Server ist das ähnlich wie ein Preemptive Wait außerhalb der Kontrolle.

    Bzw bei Dir steht es ja direkt dabei: SSIS ist der Auslöser. Da Dein Paket also längst beendet sein soll, kannst Du da nicht mehr tun - außer dass ich nochmal prüfen würde, ob wirklich kein dazugehöriger Prozess in Windows mehr aktiv ist.

    Wenn nicht, musst Du tatsächlich den Server neu starten, um die Stabilität zu gewährleisten.

    viel Erfolg

    Andreas


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com


    • Bearbeitet Andreas.WolterMicrosoft employee Donnerstag, 9. Februar 2017 10:00 korrigiert, bzw abgekürzte Lösung, da SSIS ja direkt dabei steht als Auslöser
    • Als Antwort markiert ABurger Montag, 6. März 2017 10:25
    Donnerstag, 9. Februar 2017 09:54
  • Ich kenne das Problem leider auch von unseren Systemen her in Verbindung mit einem Linked Server.

    Falls der Name der waitresource auf den Treiber hindeutet, dann verwenden wir den gleichen Treiber. Gelegentlich kam es vor, dass der Treiber einen Fehler erzeugte und der SQL Server einen Dump dazu geschrieben hat. Schau mal im Log-Verzeichnis des Servers nach.

    Auf dem Zielsystem war keine Session zu sehen und alle weiteren Versuche diesen Linked Server zu verwenden schlugen fehl. Da half bei uns nur ein Serverneustart.

    Was der Treiber nicht abkonnte war die Verwendung der vierteiligen Syntax <linked Server>.<machine>.<library>.<object>! Ich habe dann alles umgestellt auf openquery.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 9. Februar 2017 10:02
    Beantworter
  • ...

    Falls der Name der waitresource auf den Treiber hindeutet, dann verwenden wir den gleichen Treiber. ...

    Der genaue Treiber wird nicht im Wait-Type manifestiert. 0x006D steht wirklich schlicht für OLEDB. Er könnte aber an der Connection stehen. Könnte.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Donnerstag, 9. Februar 2017 10:09
  • Hallo zusammen,

    wenn es ggf. mit einer linked Server Verbindung zu tun hat, dann kann die waitresource in dem Fall der Ziel-Server sein. Ich hab auch gerade mal ein wenig quer gelesen und schließe mich im Moment Andreas und Christoph an. SQL Server Dienst muss wohl oder übel einmal durchgestartet werden.

    Vielleicht kann noch die entsprechende TCP Verbindung zu dem linked Server Ziel gekillt werden. Aber das ist jetzt ohne Gewähr.  Siehe: http://www.jaygeiger.com/index.php/2015/03/03/how-to-kill-a-frozen-linked-sql-server-connection/

    Gruß

    Dirk


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


    Donnerstag, 9. Februar 2017 10:14
  • Danke für eure schnellen Antworten.

    Das Paket kam nicht über einen Linked Server und einen zugehörigen Prozess in Windows kann ich jetzt nicht ausmachen. Aus diesem Grund wurde mit der Fachabteilung ein Neustart am Wochenende vereinbart.

    Grüße

    Donnerstag, 9. Februar 2017 10:52
  • Hallo Andreas,

    mein Gedanke ist ein anderer. Ggf hat das SSIS Paket irgendwo einen SQL Task intern definiert, wo möglicherweise auf eine linked Server Verbindung zugegriffen wird. Oder es erfolgt eine Datenmanipulation, die dann einen Trigger initiiert, der wiederum auf eine linked Server Verbindung zugreift.  Da gibt es nun viele Möglichkeiten. 

    Der entsprechende Prozess jedenfalls  war oder ist auf dem xxxDELTA1 zu suchen. Gibt es da vielleicht auch noch einen Hinweis in den Eventlogs oder dergleichen? 

    Ich gehe mit meinen Gedanken halt schon einen Schritt weiter: Was ist eventuell zu tun, um das zukünftig zu vermeiden? Es kann ja wieder vorkommen und dann will man nicht noch mal den SQL Server neu starten. Dann lieber im Vorfeld schauen, was da die linked Server Verbindung nutzt und versuchen das umzubauen.

    Gruß Dirk


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



    Donnerstag, 9. Februar 2017 11:39
  • ...Ggf hat das SSIS Paket irgendwo einen SQL Task intern definiert, wo möglicherweise auf eine linked Server Verbindung zugegriffen wird. Oder es erfolgt eine Datenmanipulation, die dann einen Trigger initiiert, der wiederum auf eine linked Server Verbindung zugreift.  Da gibt es nun viele Möglichkeiten.  ...
    Ja, das könnte in der Tat sein. Quasi die doppelte Verwendung von OLEDB, und doch die offene Verbindung zum Remote Server. Mit Glück kann man das letzte Kommando identifizieren. Das ergibt sich alls nicht aus den Screenshots. Aber ganz klar sollte man hir nochmal genauer hinsehen.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Donnerstag, 9. Februar 2017 11:50