Mark Aslan Kuschels Blog

SQL, Business Intelligence, Microsoft, .Net

Integration Services Fehler -1073741819

Neulich bin ich bei einem Kunden (SQL Server 2008 SP2) auf einen scheinbar nicht erklärbaren Fehler gestoßen.
Im Log des SQL Server Agents fand sich beim Versuch ein ETL-Paket auszuführen folgende Fehlermeldung:

Executed as user: DOMAIN\sqluser. The step did not generate any output.
The return value was unknown. The process exit code was -1073741819. The step failed.

Die SSIS Logs zeigen gar keine Einträge, sodass nicht mal ein Versuch gestartet worden ist, das Paket auszuführen. Allerdings funktionierte lokal im Visual Studio alles einwandfrei.
Einer Recherche nach steht der Fehlercode -1073741819 im Windows Betriebssystem für den ungültigen Zugriff eines Prozesses auf einen Bereich außerhalb des ihm zugeordneten Speicherbereiches.

Die Lösung war eine durchgeführte Änderung an der SSIS Konfigurationstabelle. Ein Entwickler hatte eines der Felder, in denen die Paketkonfiguration gespeichert wird, auf nvarchar(MAX) gesetzt. Ich nehme daher an, dass die Ausführung des ETL-Paketes auf dem Server den Speicher anders allokiert, als es bei der Ausführung lokal im Visual Studio der Fall ist.
Der dtutil-Prozess hat somit versucht Daten in die zu klein definierte Variable zu speichern und wurde daran gehindert. Anders als bei Datenquellen unterliegt die Konfigurationstabelle auch keiner Validierung vor dem eigentlichen Start des ETL-Paketes, sodass der Fehler dem Administrator nicht transparent gemacht.

Wem über diesen Fehlercode stolpern sollte empfehle ich daher eine genaue Prüfung der Metadaten aller im Paket verwendeten Tabellen, insbesondere der Paketkonfiguration und des Loggings.

Eine weitere mögliche Ursache kann das verwenden derselben Query in mehreren Lookups sein, sodass der Prozess (scheinbar anhand eines Hashes) nicht in der Lage ist die Speicherbereiche zu trennen. Hier ist die Lösung das Einfügen von Kommentaren in den Code, um eine Unterscheidung herzustellen.

Dieser Beitrag ist auch im PTSGroup BI Blog unter http://biblog.ptsgroup.de/allgemein/integration-services-fehler-1073741819/ abrufbar

Stolpersteine bei der Installation von Master Data Services

Seit dem SQL Server 2008 R2 liefert Microsoft in der Enterprise Edition des SQL Servers ein oft unbekanntes, aber mächtiges Tool mit: Die Master Data Services, kurz MDS!

In der aktuellen Version, dem SQL Server 2012, hat Microsoft die Oberfläche gepimpt und auf Silverlight-Basis mit einer deutlich erhöhten Bedienbarkeit ausgestattet. Silverlight ist in diesem Fall ein Segen, aber wie so oft auch ein Fluch. Da Silverlight keine direkte Konnektivität zu einer Datenbank mitbringt müssen sämtliche Zugriffe über Webdienste gekapselt werden, und wenn dort etwas schief geht steckt der Teufel oft im Detail.

Wer versucht Master Data Services unter Windows 8 bzw. Windows Server 2012 zu verwenden kann genau in diese Falle laufen und bekommt nur eine Meldung mit dem wenig hilfreichen Hinweis HttpWebRequest_WebException_RemoteServer Argumente: NotFound angezeigt (siehe folgende Abbildung).

Fehler1

Wenn man Fiddler2 versucht etwas über diesen Fehler in Erfahrung zu bringen zeigt sich tatsächlich ein HTTP 404 Fehler – ein Blick das MDS Verzeichnis verrät aber, dass der Webservice vorhanden ist.

Die Lösung zu dem Problem ist ein kleines Häkchen, in den Windows-Features (ehemals Windows-Funktionen unter Windows 7, zu erreichen in der Systemsteuerung über Programme und Funktionen) befindet sich im .Net Framework 4.5 Advanced Services im Bereich WCF-Dienste ein kleines Häkchen mit dem Namen “HTTP-Aktivierung”.

Bei der Installation von Master Data Services wird dies leider nicht geprüft, so wird man zwar darauf hingewiesen wenn das .Net Framework gänzlich fehlt, aber der Hinweis, dass hier noch eine zusätzliche Funktion von Nöten ist fehlt zumindest im Installer.

Fehler3

Nun ja, wenn man es weiß ist es schnell gemacht und schwupps läuft auch die Weboberfläche.

Und nun wünsche ich viel Freude beim Aufbauen des Stammdatenmodells.

Dieser Artikel ist auch verfügbar im PTSGroup BI Blog: http://biblog.ptsgroup.de/allgemein/stolpersteine-bei-der-installation-von-master-data-services/