Mark Aslan Kuschels Blog

SQL, Business Intelligence, Microsoft, .Net

PASS Regionalgruppe in Bremen/Oldenburg

In Bremen haben sich in den letzten Jahren erfolgreich eine SharePoint und eine Agile Usergroup etabliert – nun soll auch eine SQL Server Usergroup dazu bekommen.
Die Gruppe wird von mir und Julio Cerezo organisiert.

Zusammen mit dem Verein PASS werden vorerst drei Treffen organisiert:

Mittwoch, 08.04. bei der Firma HEC (Bremen-Überseestadt)
Dienstag, 19.05.
Mittwoch, 10.06.

Am 08.04. haben wir Christoph Seck aus der PASS Gruppe Hannover/Göttingen zu Gast und wird einen Vortrag zum Thema Dimension Security in OLAP und Tabular halten.

Wer noch Interesse hat zu kommen, kann sich gerne anmelden.

Kerberos und SharePoint: Anleitung für die Trennung von Datenbank und Frontend mit Reporting Services und Performance Point Services

Vor Längerer Zeit habe ich diesen Beitrag im PTS Group Blog veröffentlicht. Passend zu meinem Vortrag morgen, möchte ich diesen Artikel nun auch in meinem Blog veröffentlichen.

In einem früheren Beitrag wurde im PTS Blog bereits über die Installation eines SharePoint 2010 Foundation Servers  berichtet. Wer sich für für einen SharePoint 2010 Enterprise Server entscheidet, tut dies meistens um einen oder mehrere der zahlreichen dort enthaltenen Dienste zu nutzen. Wird die Installation etwas größer und eine Trennung der Dienste erforderlich, kann dem Administrator bei der Konfiguration der Sicherheit doch schon mal schnell der Kopf rauchen, denn Kerberos hat es in sich.

Das Szenario

Im Folgenden beschreibe ich wie die Netzwerksicherheit mit Kerberos in einer Umgebung einzurichten ist, in der folgende Server und Dienste existieren:

Server 1: SQL Server
- Datenbankdienste mit SQL Server Agent
- Analysis Services mit SQL Server Browser Dienst

Server 2: SharePoint Server
- Reporting Services im SharePoint integrierten Modus
- SharePoint 2010 Server
- Performance Point Services aktiviert
- Excel Services aktiviert

Wird entweder der SharePoint Server oder der SQL Server - oder gar Beides – nicht richtig für die Verteilung konfiguriert, wird die Verbindung zwischen den Systemen nicht immer einwandfrei funktionieren. Im “normalen” SharePoint Alltag, d.h. dem Umgang mit Listen, Verwalten von Dateien, Listeneinträgen, etc. fällt dies zunächst nicht auf. Wird jedoch eine Datenquelle in Reporting Services angelegt und versucht auf den SQL Server zuzugreifen, erhält man diese Meldung:

rsErrorOpeningConnection: An existing connection was forcibly closed by the remote host.
image
Hat man im SharePoint sogar schon eine Webpart Seite angelegt und versucht dort den Bericht aufzurufen gibt es die gleiche Meldung, direkt von ASP.Net (links) oder anders von Performance Point (rechts).
imageimage

Schuld daran sind jedoch nicht fehlende Berechtigungen des Benutzers auf die Datenbank, oder eine Fehlende Netzwerkverbindung, sondern die Authentifizierung im Netzwerk. Damit diese auch mitmacht muss Kerberos konfiguriert werden.

Über Kerberos

Kerberos ist ein Authentifizierungsprotokoll, dass es erlaubt sich im Windows-Netzwerk über mehrere Server hinweg an Diensten zu authentifizieren – und das auch noch vollkommen sicher. Damit dies korrekt funktioniert, muss Ordnung im Netzwerk herrschen, denn standardmäßig vertrauen sich Server nicht gegenseitig und verweigern die Kommunikation wenn es um Kerberos geht. Um dies zu ändern, muss im Active Directory für jeden Server und jedes Dienstkonto ein Secure Principal Name (SPN) hinterlegt werden, und dann wiederrum ist es möglich einzustellen wem dieser Dienst vertraut (bzw. an wen er Kerberos delegieren darf).

Das klingt ja erst mal gar nicht so schwer, oder?
In der Praxis steckt der Teufel bei Kerberos im Detail, denn der kleinste Fehler führt dazu, dass nichts funktioniert.
Ebenso führt die Verwendung von Kerberos eine Beschränkung ein: Je Hostname darf künftig nur noch ein Dienst verwendet werden. D.h. laufen auf Ihrem SharePoint Server z.B. Reporting Services im integrierten Modus und der SharePoint Dienst, erreicht der Nutzer beides über die Webadresse der SiteCollection. Wenn jetzt aber beide Dienste verschiedene Dienstkonten haben, müssten beide Dienstkonsten auf die Adresse der SiteCollection einen SPN haben – und das geht leider nicht.

Schauen wir uns einfach mal, wie Kerberos im oben genannten Szenario für Reporting Services konfiguriert werden muss

Kerberos Konfiguration: Datenbankserver

Als erstes müssen die Dienste für ihren SQL Server SPNs bekommen. Dazu müssen Sie wissen, unter welchem Dienstkonto die Dienste laufen. Unter welchem Benutzer die Dienste laufen verrät einem der SQL Server Configuration Manager, wie hier:
image
Wichtig: Für den Zugriff über Kerberos darf der SQL Server nicht unter dem lokalen Systemkonto oder dem Netzwerkdienst laufen. Es muss schon ein Active Directory Benutzerkonto sein.

Angenommen, sowohl der Datenbankdienst, als auch Analysis Services, laufen unter einem Dienstkonto mit dem Namen sqlsrv, können Sie wie folgt feststellen, ob das Dienstkonto bereits über SPNs verfügt:

  • Über die Eingabe des folgenden Befehls in die Konsole:
    setspn –l DOMAIN\sqlsrv
  • Aufrufen des in der Verwaltungskonsole für Benutzer und Computer und prüfen, ob das Tab Delegierung vorhanden ist
    image

Ist alles bereits richtig konfiguriert, müssten folgende SPNs für dem Benutzer sqlsrv hinterlegt sein, unter der Annahme, dass der Server MeinSQLServer heißt und in der Domäne dev.local Mitglied ist:

MSSQLSvc/MeinSQLServer:1433
MSSQLSvc/MeinSQLServer.dev.local:1433
MSOLAPDisco.3/MeinSQLServer
MSOLAPSvc.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer
MSOLAPDisco.3/MeinSQLServer.dev.local
MSOLAPSvc.3/MeinSQLServer.dev.local:1433
MSOLAPSvc.3/MeinSQLServer:1433

Fehlen diese Werte, lassens ich diese über den Kommandozeilenbefehl SetSPN –U –A setzen, also:

setspn –U –a MSSQLSvc/MeinSQLServer:1433 DEV\sqlsrv
setspn –U –a MSSQLSvc/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer DEV\sqlsrv
setspn –U –a MSOLAPDisco.3/MeinSQLServer.domain.local DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer.domain.local:1433 DEV\sqlsrv
setspn –U –a MSOLAPSvc.3/MeinSQLServer:1433 DEV\sqlsrv

Das wär es für den Datenbankserver. Gehen wir nun zum SharePoint Server über

Kerberos Konfiguration: SharePoint Server

Bevor wir, wie beim SQL Server, die SPNs registrieren, müssen eine ganze Reihe von Voraussetzungen im SharePoint und in Reporting Services geschaffen werden. Als erstes muss sichergestellt werden, dass die Anwendungspools und der Reportserver mit dem selben Dienstkonto betrieben werden. Da in unserem Szenario Reporting Services und SharePoint auf dem selben Server liegen, würde eine andere Konfiguration sonst zu doppelten, und somit widersprüchlichen, SPNs führen.

Den Benutzer des Reporting Services Dienstes erfahren Sie, wie oben, über den SQL Server Configuration Manager. Die Dienstkonten der SharePoint Dienste müssen Sie in der Zentraladministration unter folgendem Pfad überprüfen:
Central Administration > Security > Configure Service Accounts.
Stellen Sie hier sicher, dass die Dienste und die Web Applikation über das selbe Konto, wie Reporting Services verwenden.
image

Fehlt das Benutzerkonto, klicken Sie unten auf "Register new managed account”

Damit wäre eine der Voraussetzungen erfüllt, es geht jedoch noch weiter.

Claims to Windows Token Service

Für Reporting Services reicht die aktuelle Einstellung bereits aus. Excel Services und Performance Point Services brauchen zur Weitergabe von Kerberos Tokens allerdings auch den Claims to Windows Token Service (C2WTS). Dieser Dienst kann basierend vertrauenswürdigen Anfragen, Sicherheitstokens generieren – somit kann der Dienst für Operationen die Identität des Benutzers annehmen und mit seinen Berechtigungen arbeiten.
Damit es gelingt, muss dieser Dienst seinen Zielen, wo das Token hingeschickt wird, aber auch vertrauen können. Das wird mittels SPNs und Delegierungen festgelegt.

Stellen Sie als erstes sicher, dass dieser Dienst unter einem Domänenbenutzerkonto arbeitet. Dies kann auch über die SharePoint-Maske Configure Service Accounts (siehe oben) erledigt werden. Nun sind da jedoch ein paar Berechtigungen mehr, die dieser Benutzer erfordert. Diese lassen sich in der Verwaltung der Systemsteuerung über die Lokale Sicherheitsrichtlinie einstellen:

  • Er muss Mitglied der lokalen Administratorengruppe sein
  • Er muss in der Lokalen Sicherheitsrichtlinie folgende Rechte haben:
    • Einsetzen als Teil des Betriebssystems (Act as part of the operating system)
    • Als Dienst anmelden (Logon as a service)
    • Annehmen der Clientidentität nach Authentifizierung (Impersonate a client after authorization)

image

Soweit, so gut, jetzt sind die meisten Hürden geschafft und es kann an das Erstellen der SPNs und Delegierungen

SharePoint SPNs und Delegierungen

Angenommen, der Claims to Windows Token Service läuft unter einem Benutzer DEV\SPC2WTS, können wir folgenden SPN anlegen. Der Text SP/C2WTS kann beliebig sein, da auf den Dienst von außen nicht zugegriffen wird. Der SPN wird nur für die Delegierung benötigt.

SetSPN –U –A SP/C2WTS DEV\SPC2WTS

Nun die SPNs für das Konto des Anwendungspools:

SetSPN –U –A http/MeinSharePointServer DEV\SPXAPD
SetSPN –U –A http/intranet DEV\SPXAPD
SetSPN –U –A http/intranet.domain.local DEV\SPXAPD

Und jetzt kommt der wichtigste Teil, damit die Kerberos Tickets auch weitereicht werden dürfen: Die Delegierung.
Öffnen Sie dazu auf Ihrem Domänencontroller die Eigenschaften des Benutzers SPC2WTS, dort wird das Tab Delegierung angezeigt. Dort müssen “Benutzer bei Delegierungen angegebener Dienste vertrauen”, “Beliebiges Authentifizierungsprotokoll verwenden” aktiviert sein, dann können Sie auf “Hinzufügen…” klicken.
Es öffnet sich ein neues Fenster, dort gibt es den Button “Benutzer oder Computer”, dort suchen Sie jetzt nach ihrem SharePoint Anwendungspool Benutzer, wenn alles richtig gelaufen ist, erhalten sie dann folgende Anzeigen:

imageimage

Nun vertrat der User DEV\SPC2WTS dem Benutzer DEV\SPAPD im Kontext des Protokolls http auf dem Server MeinSharePointServer. D.h. SPC2WTS delegiert Kerberos Tokens an http/MeinSharePointServer für den Benutzer SPAPD.
Das wiederholen Sie nun für den Datenbankserver.

Der Benutzer SPAPD muss nämlich das Token weiter delegieren können an den Dienst MSSQLSvc, MSSQLOlapDisco.3 und MSSQLOlapSvc.3 auf dem Datenbankserver.

Weitere Links und Literatur

Wenn Sie diese Einstellungen vorgenommen, sollten Sie Performance Point und Excel Services mit einer erfolgreichen Verbindung belohnen. Ist dies nicht der Fall, prüfen Sie noch die allgemeine Konfiguration dieser Dienste, dazu empfehle ich die folgende Literatur und Links:

Buch: SharePoint 2010 Performance Point Services unleashed
MSDN: Configure Performance Point Services
MSDN: Übersicht über den Claims to Windows Token Service

SSDs vs. SAS Festplatten – Ein Performancevergleich

Beim Betreiben eines SQL Servers spielt die Hardware eine entscheidende Rolle für die Performance des Systems. Microsoft bietet zusammen mit Hardware-Partnern zwar Fast-Track-Server an, in vielen Fällen ist es jedoch nicht möglich eine solche Konfiguration einzusetzen.

Wer sich seinen Server selbst zusammenstellt wird heutzutage immer wieder die Frage gestellt, ob es sich lohnt SSDs einzusetzen oder ob ein älteres System durch den Einsatz von SSDs beschleunigt werden kann. In diesem Performancevergleich habe ich SSDs gegen SAS Platten antreten lassen.

Das Setup

Zum Einsatz kam schon ein älterer Server: HP ProLiant DL 380 G5 mit einem SmartArray P400 Controller. Dieser Controller unterstützt nur einen maximalen Durchsatz von 300 MB/s, weshalb in der Messung auch nicht der maximale Durchsatz der SSD erreicht wurde. Das spielt bei SQL Server Workloads jedoch meist nur eine untergeordnete Rolle.

Ansonsten:
Arbeitsspeicher: 14 GB
SAS Controller Cache: 512 MB
Erster Plattenstapel: 2x146GB 10k SAS Platten im RAID-1
Zweiter Plattenstapel: 2x72GB 10k SAS Platten im RAID-1
Dritter Plattenstapel: 2x500 GB Samsung EVO 840 im RAID-1
SQL Server 2014 Enterprise mit CU4
Windows Server 2012 R2 Standard

Gemessen habe ich mit dem SQLIO-Tool die IOs/sek, Datendurchsatz in MB/sek sowie durchschnittliche Zugriffszeit verschiedener Laststufen.

Messergebnisse

IOs/sek

image image

Die SSDs zeichnen sich im Bereich der IOs besonders bei zufälligen Lesezugriffen mit teilweise 10x höherer Performance gegenüber den Festplatten aus (8k Zugriffe). Dies verwundert nicht, denn Festplatten müssen bei zufälligen Zugriffen immer eine Umdrehung abwarten, bevor Daten gelesen werden können. Mit wachsender Größe der gelesenen / geschriebenen Datenmenge schmilzt der Vorteil dahin. Bei 256 KB ist der Performancegewinn noch im Faktor 1,6 bzw. 2,2 gegenüber den 146GB bzw. 72GB SAS Festplatten.

Dass die Unterschiede im Bereich des Schreibens nicht so groß ausfallen ist auf die Verwendung des Cache Moduls im RAID Controller zurück zu führen.

MB/sek

imageimage

Bei der Betrachtung der Transferraten wird weiter deutlich, dass die SSD ihre Stärken bei zufälligen Lesen und Schreiben ausspielen kann. Beim zufälligen Lesen erreichen die SSDs sogar die 300MB Grenze des Controllers, sodass davon ausgegangen werden kann, dass bei Verwendung eines neueren Controllers noch höhere Werte erzielt würden. Die hier beobachteten Unterschiede fallen jedoch nicht so stark aus, wie unter beim Vergleich der IOs pro Sekunde.

Durchschnittliche Zugriffszeit in Millisekunden

imageimage

Der Vollständigkeit halber füge ich auch noch die Zugriffszeit in Millisekunden ein, auch wenn diese Werte für den Betrieb eines SQL-Servers nicht so relevant sind. Auch hier ist – wenig Überraschend – die SSD mit deutlich kürzeren Zugriffszeiten vertreten. Im Bereich der 8 KB großen Pakete war die Zugriffszeit so gering, dass sie nicht ermittelt werden konnte.

Betrachtung

Die Messergebnisse lassen bereits nach einer schnellen Betrachtung folgende Rückschlüsse zu:

  • Die höhere Datendichte der 146 GB SAS Festplatten ermöglichen höhere Transferraten und kürzere Zugriffszeiten, insbesondere bei großen Datenblöcken, gegenüber den kleineren 72 GB SAS Festplatten
  • Die SSDs haben die Leistung der Festplatten in sämtlichen Disziplinen in den Schatten gestellt. Ihre Stärken haben die SSDs insbesondere im Bereich der kleinen Blöcke und bei zufälligen Lese/Schreibvorgängen

Heißt dies nun, man sollte in jedem Fall auf SSDs setzen? Folgende weitere Eigenschaften sollte man auch noch in Betracht ziehen:

  • SSDs verfügen bei intensiver Nutzung über eine deutlich Kürzere Lebensdauer, als Festplatten. Das häufigere Austauschen von Laufwerken verursacht Kosten
  • Ebenfalls sind SSDs in der Anschaffung teurer, als Festplatten
    Die hier im Test verwendeten SSDs sind zwar relativ günstig, jedoch auch nur auf Belastungen in handelsüblichen PCs und Laptops ausgelegt. Preise für Enterprise SSDs liegen nochmal deutlich höher

Es stellt sich darüber hinaus auch die Frage, welche Art Workload ihr SQL Server verarbeiten muss. Wird eine OLTP Anwendung mit vielen kleinen Schreib- und Lesezugriffen betrieben oder handelt es sich um eine Datawarehouse-Lösung?

Im Bereich der OLTP-Anwendungen werden eher kleinere Datenblöcke gelesen und geschrieben, weshalb die Performancesteigerung sehr hoch sein dürfte. OLTP Anwendungen sind aber auch besonders auf Datenintegrität angewiesen. Verlorene Datensätze in der Buchhaltung oder einem Warenwirtschaftssystem können ein ganzes Unternehmen ruinieren.
Daher müsste bei einem Umstieg auf SSDs in jedem Fall, sofern noch nicht vorhanden, eine Backup-Lösung eingesetzt werden, welche einfaches Page-Restoring ermöglicht und möglichst viele Sicherungen am Tag durchführt.

In Datewarehouse-Umgebungen sind Lese- und Schreibvorgänge eher sequentiell, da oft große Datenmengen am Stück gelesen werden. Der Performancegewinn einer SSD ist somit nicht so signifikant, wie bei einer OLTP Anwendung, und rechtfertig die zusätzlichen Kosten wahrscheinlich nicht.

Anders sieht dies wiederrum für die Cube-Aufbereitung von Analysis Services aus. Die Analysis Services legen Dimensionen, Attribute und Measuregruppen in vielen einzelnen Dateien ab, wodurch auch viele kleine Zugriffe auf das Dateisystem erfolgen. Bei sehr großen Analysis Services Datenbanken kann der Einsatz einer SSD die Aufbereitungszeiten signifikant verkürzen.

Fazit

Gegenüber 10k SAS-Festplatten haben selbst handelsübliche SSDs deutlich messbare Performancevorteile.

Je nach Einsatzszenario rechtfertigt dies allein jedoch nicht den Einsatz von SSDs, da die höheren Kosten und kürzere Austauschintervalle ebenfalls eine Rolle spielen.

Interessant wäre es sicher auch diesen Vergleich für 15k SAS Platten durchzuführen, da diese nochmal über deutlich kürzere Zugriffszeiten verfügen, in der Anschaffung aber auch deutlich teurer, als 10k Festplatten, sind.

WinInet Fehler bei FTP Zugriff in Visual Studio 2012 + 2013 beheben

In Visual Studio gibt es bereits seit vielen Versionen die Möglichkeit FTP-Webseiten direkt zu bearbeiten. Doch seit Visual Studio 2012 gibt es einen Bug, welcher diese Funktion stören kann.

In meinem Szenario habe ich einen Windows Server 2012 R2 Webserver mit IIS sowie aktivierten FTP nur auf Port 21. Die Verbindung muss daher im aktiven Modus betrieben werden.

In FileZilla lässt sich die Verbindung problemlos herstellen, so jedoch nicht in Visual Studio. Dort erscheint diese Fehlermeldung:

FTPVisualStudio1

Des Rätsels Lösung ist eine fehlende Firewall-Regel. In der Windows Firewall muss eine neue eingehende Regel für Visual Studio erstellt werden. Dazu ist eine Regel vom Typ Programm für devenv.exe zu erstellen.

FTPVisualStudio2FTPVisualStudio3

Die Änderungen werden sofort aktiv, danach glückt gleich der nächste Versuch.

Das Verhalten habe ich bei Microsoft Connect gemeldet.

Windows 8.1 Update 1: UMTS/LTE HotSpot erstellen

Vor kurzem hat Microsoft das Windows 8.1 Update 1 veröffentlicht, im Rampenlicht stehen neben der offensichtlichsten Neuerung Modern Style Apps in der Taskbar nun Nutzen zu können auch diverse Kleinigkeiten, welche die Bediendung der Modern-Welt mit der Maus deutlich erleichtern.

Mein persönliches Highlight habe ich gestern Abend beim Zug fahren entdeckt:
Im Charms-Bereich für Netzwerke gibt es nun eine Option, um Verbindungeinstellungen anzuzeigen.
image
In der nun folgenden Anzeige muss die Modemverbindung ausgewählt werden, das ist in meinem Beispiel die Mobile Breitbandverbindung über das Telekom-Netzwerk
image

Jetzt muss bloß noch der Schieberegler auf Ein gesetzt werden und es wird eine WLAN Verbindung erstellt (Voraussetzung ist, dass WLAN aktiviert ist), mit der sich weitere Geräte verbinden können. Das Passwort lässt sich natürlich beliebig ändern.

image

In diesem Sinne:  viel Spaß beim Surfen. Smiley

Folien zum PASS Vortrag über Extended Events in Analysis Services

Vergangene Woche habe ich am Dienstag bei der Regionalgruppe der PASS in Hamburg sowie am Freitag bei der Regionalgruppe der PASS Hannover/Göttingen einen Vortrag zu meinem letzten Artikel Ermitteln der Measurenutzung in SQL Server Analysis Services gehalten.

Angehängt an diesen Post findet ihr die Folien zum Download ebenso wie die Code-Beispiele. Das SSIS Paket ist nun auch verbessert, sodass es für jede Abfrage nun mehrere Zeilen mit allen Measures ausgibt (Danke an Sascha für den Hinweis).

Ebenso möchte ich mich noch für den Tipp bedanken, dass nun die neuen SQL Server Data Tools Business Intelligence für Visual Studio 2012 verfügbar sind, denn der Fly-To-The-Moon-Bug ist tatsächlich behoben worden.

Zum Schluss noch der Link zum Buch SQL Server Internals von Kalen Delaney, das mir als Wertvolle Quelle für die Abläufe im SQL Server dient: http://www.amazon.de/gp/product/0735658560/ref=as_li_ss_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=0735658560&linkCode=as2&tag=irgenddasvisu-21 

Download Folien & Code: PASS_XE_SSAS.zip (1,3MB)

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

T-SQL und .NET Debugging in SQL Server 2012

Bis SQL Server 2008 R2 war es üblich das Debuggen von .NET Code im SQL-Server sowie T-SQL-Abfragen mit der Premium Edition von Visual Studio durchzuführen. Wer versucht ein Datenbankprojekt in Visual Studio 2010 zu erstellen und es mit einer SQL Server 2012 Datenbank zu verbinden, erhält nur eine Fehlermeldung. Auch sucht man Datenbankprojekte in Visual Studio 2012 vergeblich, denn nun gibt es die SQL Server Data Tools, die übrigens auch für Visual Studio 2010 erhältlich sind.

Microsoft ist damit einen großen Schritt auf die SQL Server Entwicklergemeinde zugegangen, denn bisher war es immer erforderlich eine recht teure MSDN Premium Lizenz zu erwerben, wenn man die Datenbankprojekte nutzen wollte. Die SQL Server Datatools sind kostenfrei verfügbar und lassen sich auch mit der Visual Studio 2010 oder 2012 Shell benutzen, somit reicht es also aus eine Developer Edition des SQL Servers zu erwerben.
Es gibt nur einige Funktionen, die erst ab einer Professional Edition von Visual Studio verfügbar sind, wie das Unit Testen.

Nach der Installation steht einem auch in Visual Studio 2012 im Bereich SQL-Server wieder ein Datenbankprojekt zur Verfügung! Es wird bei den Projekten nun auch nicht mehr unterschieden, ob es sich um ein SQL Server Projekt für .NET Assemblies oder um ein Datenbankprojekt für Datenbankobjekte handelt. Nun findet sich beides im Datenbankprojekt!

Erstellen einer Assembly

Ein Datenbankprojekt wird um eine Assembly ergänzt sobald ein .NET Element dem Projekt hinzugefügt wird. Diese Objekte befinden sich beim Hinzufügen eines neuen Objektes im Abschnitt SQL CLR C#.
image

Um nun eine Assembly in einem Datenbankprojekt zu erzeugen muss nach dem Hinzufügen eines Elementes das Projekt kompiliert werden. Nehmen wir zum Beispiel die gute alte Hello World-Funktion:
image

Debuggen des Codes

Um .NET Code im SQL Server debuggen zu können ist es nicht länger erforderlich sich an den Prozess einer laufendenden Instanz anzuhängen. Alles was man braucht ist ein Skript, das nicht in den Build-Prozess integriert ist (siehe unten).
image

Mit diesem Skript lassen sich beliebige Abfragen ausführen und dann auch Debuggen. Doch wogegen wird denn ausgeführt, wenn es nicht ein laufender Prozess einer SQL Server Instanz ist? Die Data Tools bringen eine SQL Server 2012 LocalDB Instanz mit, diese wird zur Laufzeit instanziiert, wenn im Menü Debuggen der Menüpunkt Starten ausgewählt wird. Das erste Kompilieren kann je nach Geschwindigkeit des verwendeten Gerätes und Komplexität des Datenmodells durchaus einige Zeit dauern. Ist das Erstellen fertig gestellt, haben die Data Tools eine DACPAC Datei ausgegeben, deren Pfad in der Ausgabe zu sehen ist. In dem gleichen Pfad befindet sich dann auch die Assembly, hier im Beispiel Database1.dll.
image

Um nun ein Skript zu Debuggen bietet es sich an ein Skript zu öffnen, das außerhalb des Builds liegt, um es dann mit dem Debugger auszuführen, mit der Maus íst dabei neben dem Start-Knopf ein kleiner Pfeil zu betätigen um das Kontextmenü zu öffnen, alternativ tut es aber auch die Tastenkombination ALT+F5:
image

Mit dem Debugger lässt sich nun ein Einzelschritt (F11) durchführen, sodass der Cursor zu unserer Hello-World-Funktion springt. Hier ist es nun möglich, wie es findige C#-Entwickler von Visual Studio gewohnt sind, Variablenwerte einzusehen und das Ablaufen des Codes genauestens nachzuvollziehen. Und nun wünsche ich viel Spaß beim Debuggen :-)

image

Weiterführende Literatur und Links

Kapitel 4 des Buches Microsoft SQL Server 2012 - Überblick über Konfiguration, Administration, Programmierung.
Video2Brain Training zu Neues in SQL Server 2012
SQL Server Data Tools (SSDT) für Visual Studio 2010
SQL Server Data Tools (SSDT) für Visual Studio 2012

Original Blogpost im PTSGroup BI Blog und der Ceteris AG