2009-03-11 4 views
0

Wir haben eine sehr große Anzahl von SSIS-Jobs, die jeden Abend/frühen Morgen hintereinander ausgeführt werden. Diese Jobs füllen und aktualisieren große Datenmengen für unsere Produktionssysteme. Kürzlich haben wir zu verschiedenen Zeiten eine Fehlermeldung zu verschiedenen Jobs erhalten. Bisher war es unmöglich, auf eine einheitliche Grundlage zu reproduzieren:SSIS SQL Native Client Fehler - kann nicht diagnostizieren Ursache

 
    Code: 0xC0202009  
    Source: [Job Name] Connection manager "[Connection.Manager.Name]" 
    Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. 
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure". 
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Named Pipes Provider: No process is on the other end of the pipe. ". 
End Error 
Error: 2009-03-10 05:19:51.09 
    Code: 0xC00291EC  Source: Update record status Execute SQL Task 
    Description: Failed to acquire connection "[Connection.Manager.Name]". Connection may not be configured correctly or you may not have the right permissions on this connect... The package execution fa... The step failed. 

Die Verbindung auf jeden Fall richtig konfiguriert ist, und wir laufen sie als Benutzer mit den entsprechenden Berechtigungen. Seit über einem Jahr hatten diese Jobs einwandfrei funktioniert. Bei Google-Suchanfragen werden Ergebnisse angezeigt, die von möglichen Verbindungsproblemen bis hin zu Datenintegritätsproblemen reichen. Wir haben versucht, dies vom Ende der Datenquelle aus als Konnektivitätsproblem und von der SQL Server-Datenbank und der Server-Box zu versuchen, indem wir die Ereignisprotokolle überprüfen. Nichts scheint sich anzuordnen. Hier ist unser Setup:

  • Wir haben einen Server 2003-Box mit SQL Server 2005 gewidmet nur Gehäuse und Laufe SSIS Jobs
  • Wir haben eine engagierte Server 2003-Box nur mit der SQL Server-Datenbank auf es, dass unsere Häusern Daten und serviert auch Reporting Services-Berichte
  • die meisten unserer Arbeitsplätze verbinden über ODBC auf eine Sybase DB-Daten aus unserem System von Rekord zu bekommen und bringen sie für das Reporting und Datenmanipulation an den SQL-Server herunter

Hat jemand läuft über diese Ausnahme in einem ähnlichen Mann ner? Auch hier haben wir versucht, die SQL Server-DBs und die Sybase-Verbindung ohne Probleme zu beheben.

Antwort

1

Wenn OLE DB zu Ihnen lügt, dann könnte das alles sein. Wenn nicht, dann gibt es vielleicht keinen Prozess am anderen Ende der Leitung. Sie sollten in den Ereignisprotokollen usw. nachsehen, ob der andere Prozess möglicherweise abgestorben ist.

Auch Prozesse, die seit Jahren in der Produktion laufen, können ihr Verhalten ändern, wenn sich etwas anderes ändert. Beispielsweise dauert eine Sicherung oder ein anderer automatisierter Job möglicherweise länger und länger und kollidiert jetzt mit dem vorhandenen Zeitplan Ihrer SSIS-Pakete. So etwas könnte offene Verbindungen erzwingen und "keinen Prozess am anderen Ende der Leitung" verursachen.

+0

Wir haben lokale Ereignisprotokolle in beiden Feldern sowie SQL Server-Ereignisprotokolle in beiden Feldern überprüft. In den SSIS-Protokollen, die die oben gemeldete Fehlermeldung anzeigen, gibt es nichts Bemerkenswertes. Deshalb sind wir mit diesem Thema so verblüfft. –

+0

Die Tatsache, dass der Fehler um Zeitfenster und zwischen Jobs herumspringt, hilft auch nicht. Irgendwann bekommen wir keine Fehler. In anderen Nächten passiert es immer wieder. –

+0

Zum einen könnte es ein Support-Vorfall mit MS wert sein, um zu sehen, ob etwas anderes als der Färbeprozess diesen Fehler verursachen kann. Zweitens: Aktivieren Sie die Überwachung für die Prozessbeendigung, und prüfen Sie, ob eine Korrelation besteht. Letzter Ausweg: procmon von sysinternals auf technet. Große Ausgabe, großes Detail. –

2

In unserem Fall war es Ressourcenkonflikte. Deadlocks traten aufgrund von Sperren auf Tabellenebene von anderen Jobs auf. Der Native-Client-Fehler war nicht beschreibend genug, um uns mitzuteilen, was ursprünglich falsch war. Wir mussten SQL Server Profiler auf der Datenbank ausführen und nach Deadlock-Fehlern filtern. This Artikel hat uns sehr geholfen, in die richtige Richtung zu weisen.

Hoffe, dass hilft !!

Verwandte Themen