In diesem Beitrag möchte ich eine Möglichkeit erläutern, die so simpel ist, dass der ein oder andere vielleicht gar nicht erst daran gedacht hat – frei nach dem Motto: „Ich seh‘ den Wald vor lauter Bäumen nicht“.

Nehmen wir an, es handelt sich bei unserer Zahl um einen Prozentwert, dessen Anzahl der Nachkommastellen wir auf 5 begrenzen und im Falle der Überschreitung einen Fehler ausgeben lassen wollen (z.B. wenn die Zielspalte in der Datenbank nicht mehr als 5 zulässt). Dies würde sich zwar mit einfachen Mitteln realisieren lassen, jedoch unter Umständen nicht immer zum gewünschten Ergebnis führen.

Angenommen es handelt sich um den Wert 12,1234500 – so würden die beiden letzten Nachkommastellen nach „Schema-F“ abgeschnitten und ein Fehler erzeugt werden. Da es sich in diesem Falle aber um das Abschneiden von lediglich zwei nullen handelt und somit der numerische Wert trotzdem unverändert und somit gültig bleibt, muss hier eine andere Lösung her.

Wie? Ganz einfach! Man vergleiche die Zahl mit sich selbst – und zwar konvertiert in einen Gleitkommawert mit 5, sowie mit 6 Nachkommastellen. Das ganze könnte dann z.B. so aussehen:

(DT_NUMERIC, 10, 5)Wert == (DT_NUMERIC, 10, 6)Wert

Die folgende Abbildung sollte das Prinzip noch einmal veranschaulichen und weitere Erläuterungen überflüssig machen

Es gibt Bugs, die sind, wenn man sie denn kennt und zu umschiffen weiß, eher amüsant als ärgerlich. Zumeist sind sie längst bekannt und zaubern ein Lächeln ins Gesicht des Eingeweihten, wenn er diesem beim Entwickeln einmal mehr begegnet. Und doch kann es passieren, dass sich ein solcher Bug eben doch nicht überall herumgesprochen hat, was dann oftmals zu Unmut und Verwirrung führt.

Ein Klassiker dieser Art ist der Suche-Task der Integration Services 2005 in deutscher Sprachversion. Dieser birgt nämlich einen gemeinen Fallstrick, der oft zu wirren ETL-Paketen führt, wenn man auch nur einen einzigen Mausklick vergisst. Der Sachverhalt ist folgender: Nach erfolgter Definition der Spalten-Zuordnungen für die Übereinstimmungsbedingungen und Auswahl der entsprechenden Spalten in der Verweistabelle vergisst der Task anscheinend seine Konfiguration der Spalten, nachdem man die Einstellungen mit OK bestätigt und sich der Dialog schließt. Konkret könnte das Ganze ungefähr so ausschauen:

Nach dem Bestätigen verschwindet aber die eben neu hinzugefügte Spalten wie von Geisterhand wieder:

Auch nach erneutem Öffnen des Konfigurationsdialogs hat es den Anschein, als wäre hier niemals etwas eingestellt worden. Die eingangs erwähnten wirren ETL-Pakete entstehen nun durch den Workaround, dass man eine oder mehrere Spalten vorher angelegt, etwas durch den Abgeleitete Spalte-Task, und in der Suche diese mit dem nachgeschlagenen Wert überschreibt. Dies funktioniert nämlich anstandslos.

Dabei gibt es einen viel effektiveren Weg, an seine Nachschlage-Spalten zu kommen: ein Mausklick an der richtigen Stelle im Konfigurationsdialog. Der entscheidende Punkt ist nämlich die Dropdown-Box „Suchvorgang“. Der aufmerksame Entwickler sieht den Unterschied: Hier gibt es die Option „Als neue Spalte hinzufügen“ mit einem großen A an erster Stelle. Die Standard-Auswahl beginnt mit einem kleinen A:

Und dies ist auch schon des Rätsels Lösung: wenn man sich nun die einzig auswählbare Option entscheidet, klappt es mit der neuen Spalte ohne Probleme. Offensichtlich haben die Integration Services hier Probleme mit den angebotenen Optionen dieses Dialogs und der erlaubten Auswahl. Ein Blick auf die Metadaten beweist: die neue Spalte ist tatsächlich vorhanden:

Wohlgemerkt betrifft dies unseres Wissens nur SSIS 2005 in deutscher Sprache und könnte durch den ein oder anderen Patch in einigen Versionen auch behoben worden sein. Nichtsdestotrotz begegnen wir immernoch regelmäßig der kritischen Version und auch unter den Entwicklern hat sich das vorgestellte vorgehen noch nicht bis in die hintersten Ecken herumgesprochen.

Das Problem begegnet uns immer dann, wenn in der Datenbank Werte in einer anderen Granularität gespeichert werden (in diesem Fall monatsgenau) als diese von der darauf aufsetzenden Anwendung geliefert werden (diese erlaubt nur jahresgenaue Werte). Für spätere Auswertungen oder Änderungen möchten wir monatsgenaue Werte speichern, ohne den korrekten Jahreswert (die Summe der 12 Monate) zu verlieren.

Auch hier führen wieder viele Wege nach Rom, daher zeige ich im ersten Teil neben der eigentlichen Problemstellung und dem Kern der Lösung eine von vier (!) Möglichkeiten die ich gefunden habe um die Aufgabe zu lösen.

Zunächst einmal überlege ich mir geeignete Ausdrücke um die oben genannte Anforderung innerhalb eines SSIS-Datenfluss’ umsetzen zu können. Für die Monate 1 bis 11 genügt folgender Ausdruck:

(DT_NUMERIC,6,2)(Value / 12)

Der Monat 12 erfordert eine Sonderbehandlung, welche durch folgenden Ausdruck gewährleistet wird:

(DT_NUMERIC,6,2)(Value – (DT_NUMERIC,6,2)(11 * (DT_NUMERIC,6,2)(Value / 12)))

Im Grunde ermittelt dieser Ausdruck die Differenz zwischen dem Jahreswert und der Summe der 11 Monatswerte um den Wert für Monat 12 zu berechnen. Beachten Sie dabei, dass es egal ist ob bei der Ermittlung der Monatswerte ab- oder aufgerundet oder gar abgeschnitten wird (was hier der Fall ist), der Wert für Monat 12 wird stets korrekt ermittelt.

Einer der naheliegendsten Wege um diese Logik umzusetzen ist die Nutzung eines Cross Joins zwischen dem Jahreswert und 12 Monaten. Damit wird der Jahreswert von einer Zeile auf 12 Zeilen verteilt. Anschließend kann in einem “Abgeleitete Spalte”-Task der Wert mit Hilfe der oben beschriebenen Ausdrücke manipuliert werden.

Folgender Screenshot zeigt den Datenfluss und zwei Data Viewer: einen nach dem Cross Join und einem nach dem Anwenden der Ausdrücke. Beachten Sie, dass sich der Wert für Monat 12 von allen anderen unterscheidet um einen korrekten Jahreswert zu gewährleisten.

Im zweiten Teil zeige ich drei (!) weitere Vorgehensweisen, sowie die Ergebnisse eines Performancetests um zu ermitteln, wie sich die unterschiedlichen Wege im produktiven Einsatz bewähren könnten.

Die Datenbank

Zunächst sollte Klarheit darüber herrschen, welche Datenbankobjekte übertragen werden müssen. Vorbildliche Naturen können diese Frage mit einem Blick in die Historie ihrer professionellen Versionsverwaltung (natürlich inklusive Application LifeCycle Management) sogar des Nächtens im Halbschlaf beanworten (vielleicht haben sie auch mit Zettel und Stift mitgeschrieben), aber auch wenn diese Professionalität des Vorgehens nicht erreicht werden kann oder soll, gibt es es nützliche Hilfsmittel, die uns auf unter die Arme greifen helfen. Das OpenSource-Tool OpenDBDiff bietet die Möglichkeit, zwei Datenbank-Stände miteinander zu vergleichen. Es entsteht dabei ein SQL-Skript, dass ausgeführt auf der Zieldatenbank die ausgewählten Objekte synchronisiert. Dabei sei angemerkt, dass hierbei eigentlich nur Tabellenobjekte kritisch sind, da sich alle anderen, wie Views, Stored Procedures und User-Defined Functions, auch durch Löschen und Neu-Anlegen auf den gleichen Stand bringen lassen. Aber wenn wir OpenDBDiff ohnehin gestartet haben, sparen wir uns die Mühe.

Der zweite Schritt besteht im Abgleich von Steuerdaten, die zumeist in Konfigurationstabellen schlummern. Dazu kann uns das Tool TableDiff dienen, mit dessen Hilfe Unterschiede in Tabellendaten abgeglichen werden, indem auch hier SQL-Skripte generiert werden. Das Tool ist Bestandteil der SQL Server Installation und lässt sich zumeist unter C:\Program Files\Microsoft SQL Server\100\COM finden und aufrufen, wobei der Pfad je nach SQL Server Version und dessen Installationsverzeichnis varieren kann. TableDiff geht dabei tabellenweise vor, weshalb es sich anbietet, eine Batchdatei zu programmieren, die den Aufruf pro Tabelle automatisiert.

rem Server festlegen

set sserver=localhost

set dserver=localhost

rem Datenbanken festlegen

set sdb=AdventureWorksDW

set ddb=AdventureWorksDW2008

rem Pfade definieren

set exepath=”C:\Program Files\Microsoft SQL Server\100\COM\tablediff.exe”

set destfolder=D:\SQL

rem Schema festlegen

set schema=dbo

for %%t in (dimCurrency dimScenario) do (

%exepath% /sourceserver %sserver% /sourcedatabase %sdb% /sourceschema %schema%  /sourcetable %%t /destinationserver %dserver% /destinationdatabase %ddb% /destinationschema %schema% /destinationtable %%t -f “%destFolder%\changeScript(%schema%_%%t).sql”

)

Wir haben nun eine Reihe von SQL-Skripten, die nur noch auf der Zieldaten ausgeführt werden müssen, um die Datenbankstruktur in einen identischen Zustand zu bringen.

SSIS-Pakete und Cube-Defintionen

Es gilt nun, sowohl SSIS-Pakete und Cube-Definitionen zu übertragen. Dies ist etwas einfacher, da sowohl für SSIS- als für SSAS-Projekte einen Deployment-Wizard existiert, der uns das Bereitstellen auf dem Zielsystem (fast) vollständig abnimmt. Im Falle von SSIS-Paketen besteht weiterhin die Möglichkeit, auf das Kommandozeilenwerkzeug dtutil zurückzugreifen, das, eingebettet in eine Batch-Datei, das Bereitstellen der Pakete nach einem Doppelklick automatisch übernehmen kann. Da wir selbst in kleineren Projekten intensiven Gebrauch von der SSIS-Paketkonfiguration machen, haben wir auch wenig Mühe damit, Informationen wie Server- oder Datenbanknamen zu aktualisieren. SSAS-Cubes  müssen nur noch verarbeitet werden und sind damit direkt bereit zum Einsatz. Aber auch hier gilt es, eine gewisse Vorsicht an den Tag zu legen, da doch der ein oder andere Fallstrick lauert. Einer dieser Fallstricke sind Cube-Rollen, die ohne weitere Konfiguration auf dem Zielserver überschrieben werden. Doch auch wenn wir dies explizit verhindern wollen (die entsprechende Option im Deployment Wizard heißt Retain Roles und Members), ist leider nicht immer gewährleistet, dass die bestehende Konfiguration erhalten bleibt. Hier hat sich der Workaround etabliert, die Rollendefinition auf dem Produktivserver zu sichern (Zu finden im entsprechenden Bereich in der XMLA-Datei, also der Datenbankdefinition, auf der SSAS-Datenbank) und nach dem Deployment zurückzuspielen.

Die Berichte

Für SSRS-Berichte hat sich ein ein Werkzeug bewährt, dass es uns ermöglicht, Berichte direkt vom (Test)Berichtsserver herunterzuladen und auf den (Produktiv)Berichtsserver zu übertragen. Dazu wird neben den Berichtsdefinitionen in Form von .rdl-Dateien eine Batchdatei generiert, in der nur noch die URL des Zielsystems hinterlegt werden muss. Nach einem Doppelklick können wir und zurücklehnen und die Deployment-Show genießen.

Fazit

Mit dem vorgestellen Vorgehen und Werkzeugen ist es uns, ein recht elegantes Deployment unserer BI-Solution auf entfernte Umgebungen vorzunehmen. Großer Vorteil dabei ist die Möglichkeit, weite Teile durch Batch-Dateien und Konfigurationen zu automatisieren und damit den Aufwand mehrmaliger Deployments zu merklich reduzieren.

Das CASE WHEN Statement  wird in zwei Typen unterteilt:

A) “Simple” CASE:

CASE [MyValue]
  WHEN 100 THEN „Small“
  WHEN 1000 THEN “Middle”
  WHEN 10000 THEN “Large”
ELSE “Micro” END

B) “Searched” CASE:

CASE
  WHEN [MyValue] = 100 THEN „Small“
  WHEN [MyValue] = 1000 THEN “Middle”
  WHEN [MyValue] = 10000 THEN “Large”
ELSE “Micro”
END

Wie Chris Webb in seinem BI-Blog mitteilt, ist die Verwendung von Simple CASE performanter als Searched CASE, allerdings kann in der SQL Server Version 2005 die Verwendung von Simple CASE unter gewissen Umständen fehlerhafte Ergebnisse im ELSE Zweig erzeugen.

Voraussetzung dafür ist, dass in irgendeinem der Zweige ein anderes, berechnetes Measure benutzt wird, welches wiederum aus einem Tupel mit mindestens einer Dimensionsreferenz bestehen muss. Bsp:

CREATE MEMBER CURRENTCUBE.[Measures].TestCalc AS

([Date].[Calendar Year].&[2003],[Measures].[Sales Amount]),

Visible=1,FORMAT_STRING=“#,###0.00″;

Folgend die Definition eines berechneten Elements mit einer SIMPLE CASE Entscheidung auf Basis der AdventureWorks DW 2005 OLAP Datenbank:
(Ich bitte den Sinn der angeführten Berechnungen in den Hintergrund zu stellen …

CREATE MEMBER CURRENTCUBE.[Measures].SimpleCase AS

CASE [Date].[Calendar Year].CURRENTMEMBER

    WHEN [Date].[Calendar Year].&[2002] THEN

      ([Product].[Product Line].&[S],[Measures].TestCalc)

    + ([Product].[Product Line].&[],[Measures].TestCalc)

    WHEN [Date].[Calendar Year].&[2003] THEN

      ([Product].[Product Line].&[],[Measures].[Sales Amount])

    + ([Product].[Product Line].&[S],[Measures].[Sales Amount])

    ELSE   – “Any other year – Product line MOUNTAIN

      ([Product].[Product Line].&[M],[Measures].[Sales Amount])

END,

Visible=1,FORMAT_STRING=“#,###0.00″;

Das Measure summiert die Produktlinien „Accessorys“ und „Components“ in den Pfaden 2002 und 2003, benutzt im Pfad für das Jahr 2002 das Measure „TestCalc“ und zeigt im ELSE Zweig den Sales Amount der Produktinie „Mountain“ an. 

Ein berechnetes Element mit Verwendung der Searched CASE Variante würde dann wie folgt definiert werden müssen:

CREATE MEMBER CURRENTCUBE.[Measures].SearchedCase AS

CASE

    WHEN [Date].[Calendar Year].CURRENTMEMBER

     IS [Date].[Calendar Year].&[2002] THEN

     ([Product].[Product Line].&[S],[Measures].TestCalc)

   + ([Product].[Product Line].&[],[Measures].TestCalc)

    WHEN [Date].[Calendar Year].CURRENTMEMBER

      IS [Date].[Calendar Year].&[2003] THEN

      ([Product].[Product Line].&[S],[Measures].[Sales Amount])

    + ([Product].[Product Line].&[],[Measures].[Sales Amount])

    ELSE   – “Any other year – Product line MOUNTAIN

     ([Product].[Product Line].&[M],[Measures].[Sales Amount])

    END,

Visible=1,FORMAT_STRING=“#,###0.00″;

Das Ergebnis ist verblüffend, zieht man beide berechneten Member in die Abfrage eines Cubebrowsers:

Zeilen   : Dimension Promotion, Attribut Promotion
Filter    : Date.Calendar Year = 2004; Product.Product Line = Mountain

Wie man sieht, wird die Gesamtsumme in beiden Membern korrekt angezeigt, im Simple CASE Measure werden jedoch die Ergebnisse für die unteren beiden Zeilen NICHT angezeigt. Das Phänomen / Bug tritt NUR im SQL Server 2005 auf und NUR bei Verwendung eines berechneten Measures mit o.g. Bedingungen in irgendeinem der CASE Zweige.

Gefährlich bleibt es trotzdem, kontrolliert man nämlich nur die Gesamtsummen (was der eine oder andere Developer aus Zeitgründen sicher schon mal getan hat), fällt der Fehler eben NICHT auf.

Deswegen:

Checkt Eure CASE WHEN Member! Vor allem darauf ob Ihr Euch die Verwendung nicht ganz sparen wollt/könnt

 Ich möchte hier kurz beschreiben, wie es möglich ist, unter Verwendung der ReportServer Datenbank, die Ausführung der Abonnements einfach zu verwalten.

Die Grundidee

Die Reporting Services speichern ihre Abonnements in der zugehörigen DB(Standardname: ReportServer). Die Tabelle in der alle Abonnements aufgeführt sind nennt sich dbo.Subscriptions:

In dieser Tabelle gibt es eine Spalte mit dem Namen InactiveFlags. Bei einem aktiven Abo ist dieser Wert auf 0 gesetzt. Um das Abo zu deaktivieren muss dieser Wert auf 1 geändert werden.

Die Umsetzung

Zunächst benötigen wir noch einige Tabellen, um die Lesbarkeit zu erhöhen, indem wir die IDs durch die zugehörigen Namen für Bericht, Abonnement und Benutzer ersetzen:

 

Mit dem nachfolgendem SQL-Statement können wir die passenden Informationen auslesen:

SELECT
     s.[SubscriptionID]
     ,s.[Description]
             ,u.UserName
             ,c.Name as ReportName
             ,[InactiveFlags]
             ,rs.ScheduleID AS JobName
             ,rs.ReportAction
             ,[ExtensionSettings]
             ,[Locale]
             ,s.[ModifiedByID]
             ,s.[ModifiedDate]
             ,[LastStatus]
             ,[EventType]
             ,[MatchData]
             ,[LastRunTime]
             ,[Parameters]
             ,[DataSettings]
             ,[DeliveryExtension]
             ,[Version]
             ,[ReportZone]
             ,[OwnerID]
             ,[Report_OID]
FROM [ReportServer].[dbo].[Subscriptions] s
             inner join dbo.Users u on u.UserID = OwnerID
             inner join [dbo].[Catalog] c on s.Report_OID = c.ItemID
             inner join [dbo].[ReportSchedule] rs on s.SubscriptionID = rs.SubscriptionID

Abhängig von den Abonnements sollte die Abfrage in etwa das folgende Ergebnis liefern:

 

Mit den oben stehenden Informationen können wir jetzt einzelne Abonnements aktivieren bzw. deaktivieren.

Für die Deaktivierung kann folgende Query verwendet werden:

UPDATE Subscriptions set
[InactiveFlags] = 1
where
[SubscriptionID] = ‘929CDEE8-…’
END

Für die Aktivierung kann das gleiche Update-Statement verwendet werden, der Wert InactiveFlags muss jetzt nur auf 0 gesetzt werden.

Ausführung von Abonnements

Gelegentlich kommt es vor, dass ein Abonnement außerhalb der geplanten Zeiten durchgeführt werden soll.

Da die Ausführung der Abonnements über den SQL Server Agent gesteuert wird, haben wir die Möglichkeit die passenden Jobs von Hand zu starten. Dies kann im SQL Server Management Studio erfolgen.

Oder es können vordefinierte gespeicherte Prozeduren aus der msdb Datenbank verwendet werden.

EXEC msdb.dbo.sp_start_job ‚251601B4…’


Die IDs der für die angelegten Jobs und die IDs für die zugehörigen Abos sind in der [dbo].[ReportSchedule] Tabelle der ReportServer DB hinterlegt. Wenn man diese Tabelle noch mit der dbo.Subscriptions verbindet:

SELECT
   [ScheduleID]
  ,[ReportID]
  ,rs.[SubscriptionID]
  ,s.Description
  ,[ReportAction]
FROM [dbo].[ReportSchedule] rs
INNER JOIN dbo.Subscriptions s ON rs.SubscriptionID = s.SubscriptionID

können die JobIDs den zugehörigen Abos zugeordnet werden.

Der passende Bericht

Nachdem die Grundlagen für die Deaktivierung bzw. Aktivierung der Abonnements geklärt sind, kann ein einfacher Bericht erstellt werden, mit dem die Ausführung und der Status des Abos gesteuert werden kann.

Für den Bericht muss eine Datenquelle für die ReportServer Datenbank erstellt werden und die folgenden Parameter werden benötigt, um die zugehörigen Funktionalitäten zu gewährleisten:

Des Weiteren brauchen wir ein Dataset, das zum einen die Informationen, wie vorhandene Abos, Berichtsnamen, etc. ermittelt, um sie im Bericht anzuzeigen, zum anderen aber auch Abos aktiviert und deaktiviert, sowie einzelne Jobs ausführt. Die Steuerung der Ausführung wird durch die einzelnen Parameter vollzogen und einzelne Teile der Abfrage übergangen oder ausgeführt:

if @SetActiv = 1
BEGIN
UPDATE Subscriptions set [InactiveFlags] = @InactiveFlags
where
    [SubscriptionID] = @id
END

if @Execute = 1
BEGIN
EXEC msdb.dbo.sp_start_job @JobName
WAITFOR
delay ‘00:00:05′
END

SELECT s.SubscriptionID, rs.ScheduleID AS JobName, s.OwnerID, u.UserName, s.Report_OID, c.Name AS Reportname, s.Description AS SubDesc, s.InactiveFlags AS Active, s.ExtensionSettings, s.Locale, s.ModifiedByID, s.ModifiedDate, s.LastStatus, s.EventType, s.MatchData, s.LastRunTime, s.Parameters, s.DataSettings, s.DeliveryExtension, s.Version, s.ReportZone
FROM Subscriptions AS s
   INNER JOIN Users AS u ON u.UserID = s.OwnerID
   INNER JOIN Catalog AS c ON s.Report_OID = c.ItemID
   INNER JOIN ReportSchedule AS rs ON s.SubscriptionID = rs.SubscriptionID


Im unteren Teil der Abfrage werden die Informationen ermittelt, im oberen Teil wird zunächst der Status des Abos aktualisiert oder der ausgewählte Job gestartet. Dadurch, dass das Statusänderungen und Jobausführungen über die Links in der Tabelle gesteuert werden, ist immer nur einer der beiden Parameter @SetActiv und @Execute eins und es wird immer nur eine der beiden Aktionen ausgeführt.

Um die Daten anzuzeigen erstellen wir eine einfache Tabelle:


Für das Feld Aktiv wird die folgende Expression: =iif(Fields!Active.Value = 0,“Aktiv”,“Deaktiviert”) verwendet und die folgende Aktion, für die Änderung des Status, definiert:


Zum Schluss muss noch das Ausführen des Jobs ermöglicht werden. Hierfür definieren wir eine Aktion für das Textfeld Execute:

Jetzt ist der Bericht soweit fertig, dass der Status und das Ausführen der Abos verwaltet werden kann, birgt aber noch die ein oder andere Gefahr in sich. So wird z.B. ein Abo erneut ausgeführt, wenn man den Bericht nach einem Execute aktualisiert. Für eine erste Demonstration sollte er aber reichen.

Aber beginnen wir von vorne: immer wenn die Bearbeitung mehrere gleichartiger Dateien mittels SSIS gefragt ist, kommt früher oder später der ForEach-Loop-Container zum Einsatz. Damit lässt sich z.B. recht komfortabel über Dateien mit einer bestimmten Namensstruktur innerhalb eines Ordners iterieren. So könnte ein mögliches Importszenario vorsehen, dass mehrere Exceldateien in einem Ordner ausgelesen werden sollen – den ForEach-Loop-Container könnte man dann wie folgt konfigurieren:

Soweit so gut, der Rest des Paketes könnte dann wie folgt aussehen. Innerhalb des Loops wird eine Variable mit dem aktuellen Dateipfad ausgelesen um alle gefundenen Dateien nach Beendigung des Containers in einer MessageBox anzuzeigen:



Ich habe bisher den Inhalt des betroffenen Ordners unterschlagen, hier ist er:



Und siehe da: unser Paket findet zwei Exceldateien – wunderbar! Oder doch nicht? Störend an dieser Stelle könnte die Excel-Datei sein, die im neuen 2007er Format gespeichert wurde. Diese hat die Endung .xlsx! Eigentlich ganz praktisch, denn die beiden Exceltypen unterscheiden sich grundlegend und erfordern ggf. eine differenzierte Behandlung innerhalb der SSIS. Weitere prüfende Blicke in die Konfiguration des ForEach-Loops lassen letztlich nur einen Schluss zu: egal wie man es dreht und wendet, der Ausdruck im “Files”-Feld des Editors lässt sich nicht dahingehend ändern dass er nur .xls Dateien erwischt (was man eigentlich erwarten würde) – der Ausdruck verhält sich also wie *.xls*!

An dieser Stelle wirken die Books Online einmal mehr erhellend und decken auf, dass es sich quasi um erwünschtes Verhalten handelt – der Ausdruck verhält sich nämlich wie beim dir-Befehl in Windows (siehe: http://msdn.microsoft.com/en-us/library/ms187670.aspx). Dieser wiederum ist aus Kompatibilitätsgründen so gestrickt, dass er nur drei Zeichen der Dateinamenerweiterung betrachtet – die gute alte 8.3-Dateinamenbeschränkung aus MS-DOS Zeiten schlägt hier also wieder einmal zu!

Eine Differenzierung nach Dateierweiterung muss also später geschehen, die könnte dann z.B. so aussehen: innerhalb des ForEach-Loop-Containers fügen wir eine Rangfolgeeinschränkung (zu deutsch: einen Pfeil) ein und binden daran eine SSIS-Expression. Diese prüft, ob die letzten drei Buchstaben des ausgelesenen Dateinamens auch tatsächlich x, l und s sind:





So modifiziert, verrichtet das Paket ordnungsgemäß seinen Dienst und findet tatsächlich nur eine Excel-Datei:



Da kann man sich natürlich schon fragen ob es sich um ein Bug oder ein Feature handelt, aber genau wegen diesen Ecken und Kanten lieben wir die Integration Services so sehr – man entdeckt eben immer wieder etwas Neues!

Doch mit steigender Komplexität der Pakete (Verbindungsmanager, Paketvariablen) und ausgiebiger Nutzung der Paketkonfiguration gelangt man mit den SSIS-Bordmitteln einmal mehr an die Grenzen des Wartbaren. Die Integration Services bieten von Haus aus die Möglichkeit, andere SSIS Pakete aufzurufen, doch die Übergabe von Variablen und Verbindungsmanagern an das “Kindpaket” gestaltet sich sehr aufwändig (viel Expression-Hacking). Die Möglichkeit, Rückgabewerte vom Kindpaket zu empfangen fehlt gar gänzlich.

In diese Nische stürzt sich ein Codeplex-Projekt, welches ich im Folgenden kurz vorstellen möchte: der “Enhanced SSIS Execute Package Task”. Unter http://ssisexec.codeplex.com/ ist das noch recht unbekannte Projekt zu finden (derzeit für SSIS 2005 und SSIS 2008 R2 – siehe “Downloads”). Hilfreich bei der Installation (es wird eine dll und ein schmales readme geliefert) ist folgender Eintrag in den Books Online: http://msdn.microsoft.com/en-us/library/ms403356.aspx Hat man die Komponente erfolgreich installiert lässt sie sich über einen Rechtsklick in die Toolbox -> Choose Items in die Liste der Kontrollfluss Tasks aufnehmen.



Die Komponente bietet eine grafische Oberfläche zum Mappen der Variablen bzw. Verbindungsmanagern zwischen den Paketen. Diese können entweder im Dateisystem oder in der MSDB serverseitig gespeichert sein. Somit lassen sich recht schnell und komfortabel Konfigurationen zwischen Paketen übergeben. Wie das aussehen könnte sieht man in folgendem screenshot: Hier wird von einem Steuerpaket, welches den Pfad zu einer Exceldatei via Paketkonfiguration erhält, ein Kindpaket aufgerufen wobei der Verbindungsmanager zwischen den Paketen übergeben wird.



Hinweis: Das Projekt hat derzeit noch den Alpha-Status – vom Einsatz in einer Produktivumgebung rate ich also dringend ab! Laut Aussage des Authors scheint es aber stabil zu laufen und dieser freut sich mit Sicherheit über ausgiebiges feedback in Form von Kommentaren oder Anmerkungen. In diesem Sinne: happy testing!

Abhilfe schafft hier ein kleiner Trick, der in den screenshots unten zu sehen ist. Mittels des Tasks “Abgeleitete Spalte” erstellt man eine neue Textspalte, deren Inhalt die Spalte mit den führenden Nullen eingebettet in Hochkommata und ein vorangestelltes Gleichheitszeichen ist (Escape-Sequenz beachten!).





Als Resultat interpretiert Excel fortan den Wert in der Spalte als Formel und die führende Null wird korrekt dargestellt.

Aber wer kommt denn auf die Idee, dass dieses Zitat wortwörtlich zu nehmen ist?

Ich sah mich mit einer Kundendimension von 172.000 Kunden konfrontiert, die etwa 200 Vertretern zugeordnet waren. Ergebnis der Abfrage sollten die Kunden sein, die in einem gewissen Monat keine Umsätze, dafür aber im Rest des Jahres Umsätze erzielt hatten.

 Übersetzt in den AdventureWorks Cube, wobei der Vertreter hier durch die Dimension “Produkt” ersetzt wird, sah die Abfrage zuerst so aus:

WITH

MEMBER
UmsatzDezember03
AS

(

    [Measures].[Internet Sales Amount]

    ,STRTOMEMBER(‘[Date].[Calendar].[Month].&[2003]&[12]‘, CONSTRAINED)

)

SET Kunden AS

EXCEPT(EXISTS

(NONEMPTY([Customer].[Customer].[Customer].MEMBERS

        ,[Measures].[Internet Sales Amount])

        ,[Product].[Product Categories].[Category].&[1])

,NONEMPTY([Customer].[Customer].[Customer].MEMBERS

    ,UmsatzDezember03))

SELECT

{

    [Measures].[Internet Sales Amount]

} ON 0,

{

    Kunden

} ON 1 FROM [Adventure Works]

WHERE [Date].[Calendar].[Calendar Year].&[2003]


Um der besseren Lesbarkeit willen erstellte ich das berechnete MEMBER UmsatzDezember03 um das – zugegeben etwas komplizierte – Kundenset zu filtern.

Die ursprüngliche Abfrage (nicht das Beispiel hier) benötigte 45 Sekunden, was bei einer so kleinen Dimension von 172.000 Membern nicht akzeptabel war. Query-Tuning war also unumgänglich.

Nehmen wir uns des Beispiels oben an: Diese Abfrage – mit “MDX Studio” auf dem AdventureWorks Cube ausgeführt – berechnete 44.240 Zellen und benötigte 2,6 Sekunden für die Ausführung.

Mosha’s Befehl zur Sparsamkeit gehorchend, verzichtete ich auf das Hilfsmember und brachte den Ausdruck für UmsatzDezember03 direkt in das Kundenset.

WITH

SET Customers AS

EXCEPT(

    EXISTS(NONEMPTY([Customer].[Customer].[Customer].MEMBERS

                ,[Measures].[Internet Sales Amount])

        ,[Product].[Product Categories].[Category].&[1])

,NONEMPTY([Customer].[Customer].[Customer].MEMBERS

    ,(

    [Measures].[Internet Sales Amount]

    ,STRTOMEMBER(‘[Date].[Calendar].[Month].&[2003]&[12]‘, CONSTRAINED)

)))

SELECT

{

    [Measures].[Internet Sales Amount]

} ON 0,

{

    Customers

} ON 1 FROM [Adventure Works]

WHERE [Date].[Calendar].[Calendar Year].&[2003]

Dies führte zu einer Berechnung von nur 7.272 Zellen, benötigte aber immer noch 2,6 Sekunden für die Ausführung. Nachdem ich mir auch das CONSTRAINED Flag in der STRTOMEMBER Funktion erspart hatte, lag die Ausführungszeit bei 0,6 Sekunden.

Was war passiert? Offensichtlich führte das Einfügen des berechneten Members UmsatzDezember03 dazu, das die Berechnung für den Term NONEMPTY([Customer].[Customer].[Customer].MEMBERS,UmsatzDezember03) für jedes einzelne Member der Kundendimension ausgeführt wurde – d.h. je mehr Member in der Dimension enthalten sind, desto langsamer wird die Abfrage.

Darüber hinaus ist festzustellen, dass das CONSTRAINED Flag die Query ebenfalls verlangsamt – was uns zu dem Schluss führt, das Mosha’s Zitat tatsächlich wortwörtlich zu nehmen ist. Allein das Einsparen der Worte “MEMBER, AS, STRTOMEMBER und CONSTRAINED” führt in obigem Beispiel zu einer Beschleunigung der Abfrage von 500% und zu einer 86%-igen Reduktion der berechneten Zellen.


In den Analysis Services 2008 tritt dieses Problem nicht mehr auf. “Hilfsmember” können hier ohne Scham verwendet werden. Beide auf einem SQL Server 2008 ausgeführten Abfragen berechneten nur die nötigen 7.272 Zellen.