Im zweiten Teil dieser Serie über die Migration von SQL Server 2005 Business Intelligence Anwendungen schauen wir uns an, wie Integration Services Pakete nach SSIS 2008 migriert werden können.

Microsoft selbst liefert ein detailliertes Dokument zur Migration nach SQL Server 2008, jedoch möchte ich in diesem Artikel weitere praktische Erfahrungen einfließen lassen.

Beim Öffnen eines Integration Services 2005 Projektes mit Visual Studio 2008 startet der Upgrade Wizard ganz automatisch und führt die Umwandlung in das neue Projekt- und Paket-Format durch. Im Hintergrund passiert jedoch viel mehr: Die verwendeten nativen Microsoft Komponentenreferenzen (Data Flow Task, Data Source u.a.) werden in Referenzen auf die neuen 2008er DLLs überführt. So weit, so gut. Doch was ist mit den selbst entwickelten Komponenten, den Custom Components?

Gerade hier leistet der Upgrade Wizard wertvolle Dienste. Damit dieser erkennt, welche neuen Komponenten den alten entsprechen, werden Mapping-Dateien ausgewertet, die diesen Zusammenhang definieren. Für jede Komponente stellt der Entwickler eine Datei beliebigen Namens zum Zeitpunkt der Migration bereit. Mapping-Dateien haben folgenden Aufbau:

   1: <?xml version="1.0" ?>

   2: <Mappings xmlns="http://www.microsoft.com/SqlServer/Dts/UpgradeMapping.xsd">

   3:     <ExtensionMapping

   4:         tag="$$Short Description$$"

   5:         

   6:         oldAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=1.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   7:         

   8:         newAssemblyStrongName="$$AssemblyName.ClassName$$, $$AssemblyName$$, Version=2.0.0.0, Culture=neutral, PublicKeyToken=$$Token$$"

   9:     />

  10: </Mappings>

Die mit $$ umschlossenen Identifier müssen individuell angepasst werden. Befinden sich entsprechende Dateien im neuen SQL Server Unterverzeichnis DTSUpgrade Mappings, so versucht der Upgrade Wizard alle Referenzen der alten Komponente (“oldAssemblyStrongName”) im SSIS Paket auf die neue zu aktualisieren. Und schon ist das Paket mit der neuen Komponente einsatzbereit. Ach ja: Die neue Komponente sollte natürlich auf dem Rechner vorhanden sein!

Ganz so komfortabel ist die Migration von Script Tasks manchmal jedoch nicht. Der Upgrade Wizard überführt den Script Code zwar in die neue Entwicklungsumgebung, kann jedoch inhaltlichen Anpassungsbedarf nicht erkennen. Dazu gehört beispielsweise die textuelle Verwendung des SQL Providernamens (neu SQLNCLI10) sowie Referenzen auf alte Libraries in Strings. Deshalb ist schon noch etwas Aufmerksamkeit gefragt um diese Probleme zu erkennen.

Gute Dienste leistet hierbei der Upgrade Advisor. Dieses Tool untersucht alle Pakete in einem ausgewählten Verzeichnis und zeigt als Analyseergebnis u.a. die verwendeten Script Tasks an. Diese Ergebnisliste ist manuell abzuarbeiten und damit jedes Skript auf mögliche Probleme zu untersuchen.

Abschließend noch ein Tipp: Verwenden Sie keine SSIS-Pakete mit Punkten im Dateinamen. Der Upgrade Advisor schneidet nämlich den Namen des Ergebnispaketes sofort nach dem ersten Punkt ab. Pakete mit gleichem Namensraum-Benennungsschema würden sich gegenseitig überschreiben und das Ergebnis der Migration unbrauchbar machen.

Beherzigen Sie jedoch die erwähnten Hinweise, sollte einer erfolgreichen Paketmigration nichts mehr im Wege stehen.