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

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#.

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:

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).

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.

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:

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 :-)

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

dreht sich bei Microsoft sehr viel um Windows 8, die neue Oberfläche sogt gleichermaßen für Bewunderung und Begeisterung, aber auch für Hohn und Aufruhr. Wie so oft gerät dabei schon fast in Vergessenheit, dass der neue Windows Kern auch in das Server Betriebssystem Einzug findet und zur Veröffentlichung von Windows Server 2012 führt. Und auch hier wird es Kacheln geben, wenn auch etwas anders, denn das Serversystem wird überwiegend über den Server Manager gesteuert, dessen Kacheln nunmehr an ein Dashboard erinnern. Meistens ist die Veröffentlichung eines neuen Server Betriebssystems für den SQL Server eher unspektakulär, außer dass mehr Kerne und mehr RAM unterstützt werden – dieses Mal jedoch wird es etwas anders sein.

Windows 8 UI

Ob hübsch oder nicht, dieses Urteil kann sich jeder selber bilden. Fest steht, wer einen Windows Server 2012 administrieren möchte, muss zwar das neue Startmenü nicht unbedingt benutzen, da sich Alles wichtige mit dem Server Manager erreichen lässt, jedoch ist auch dieser nun gekachelt. Der Server Manager präsentiert sich nun zum Start immer mit einem Dashboard, das darstellt in welchen Kategorien oder Servern verschiedene Ereignisse aufgetreten sind. Verglichen zum Windows Server 2008 R2 Server Manager wirkt es übersichtlicher und aufgeräumter. Da das hier ein SQL Server Artikel ist, möchte ich nicht zu viel darüber schreiben.

 
Links: Windows Server 2008 R2 Server Manager, Rechts: Windows Server 2012 Dashboard

SMB 3.0 Server Message Block

Server Message Block, kurz SMB, ist das Protokoll mit dem Windows Dateien über Netzwerkfreigaben austauscht. SMB kann man für seine Einfachheit lieben und für seine Macken hassen. Die meisten kennen SMB über die Windows-Freigabe zwischen Computern und Servern zum Austausch von Dateien oder dem gemeinsamen Nutzen von Druckern. Mit den letzten Windows Server Releases wurden von Microsoft Erweiterungen für SMB eingeführt, die neue Möglichkeiten erschlossen haben, wie z.B. der BranchCache in Windows Server 2008 R2. Für die meisten Nutzer hatte sich aber nicht wirklich etwas geändert. Wer zuverlässige Verbindungen zwischen Systemen braucht hat sich jedoch bisher selten auf SMB verlassen und andere, teilweise sehr teure, Lösungen eingeführt. In SMB 3.0 hat Microsoft eine ganze Reihe von Neuerungen, die SMB einen Schub in Zuverlässig und Performance geben werden. Schauen wir kurz in die wichtigsten rein

SMB Direct (SMB über Remote Direct Memory Access (RDMA))

SMB in seiner bisherigen Variante dient als Übersetzer zwischen der Speicher-Architektur zweier Systeme um so Daten austauschen zu können, ohne dass die jeweils andere Seite über Kenntnisse dessen Speicher-Architektur verfügen muss. Das bedeutet einerseits, dass der Zugriff einfach möglich ist, ohne dass außer Zugriffsrechten sonstige technische Vorkehrungen nötig sind, jedoch auch, dass SMB einen Overhead erzeugt.
Wer größere Dateien im Netzwerk kopiert hat kann davon ein Lied singen. Der Arbeitsspeicherverbrauch des Explorers ist immens und wenn dem System der Arbeitsspeicher ausgeht leidet die Geschwindigkeit des Kopiervorgangs massiv, auch wenn das Netzwerk sowie Ziel- und Quelldatenträger eigentlich noch deutlich mehr hergeben.

Erinnert Sie das an etwas? Lange ist es her, da gab es eine ähnliche Situation beim Zugriff auf lokale Laufwerke, als der PIO-Modus noch Standard war. Eine Erweiterung des IDE-Protokolls, namentlich Direct Memory Access (DMA), schaffte hier Abhilfe, denn mit DMA kann das Betriebssystem direkt auf den Speicher des Controllers zugreifen und kann sich somit den Umweg über Prozessor und System-Arbeitsspeicher sparen. Ein damals viel gebräuchlicher Trick war es unter Windows 98 genau dieses Feature im Geräte Manager auf dem jeweiligen Datenträger zu aktivieren um seinen PC schneller zu machen. Dieses einfache wie auch geniale Konzept überträgt Microsoft mit SMB 3.0 nun auf das Netzwerkprotokoll!
Vorausgesetzt Sender und Empfänger sprechen beide SMB 3.0, sprich sind entweder Windows Server 2012 oder Windows 8 Geräte und die Hardware spielt mit, lässt sich über das Netzwerk eine direkte Verbindung mit dem Speichercontroller des Datenträgers auf der Gegenseite herstellen und somit die Daten direkt hinein pumpen.
Dadurch sind nicht nur die Belastung auf beider Systeme, sondern auch es sind auch höhere Datendurchsätze möglich. SMB wird somit plötzlich interessant, wenn es darum geht große Dateien, die vielen Änderungen unterliegen, über das Windows-Netzwerk bereitzustellen.

SMB Multichannel und Transparentes Failover

Über SMB Multichannel lassen sich nun mehrere Netzwerkkarten nutzen um den Datenverkehr einer Netzwerkfreigabe zu bewältigen. Dies bringt neben einer höheren Datendurchsatzrate auch den Vorteil den Datenverkehr auf verschiedene Netzwerke aufteilen zu können, um so bei Ausfall eines Netzwerkes den Server ohne Unterbrechung weiter erreichbar zu halten.
Darüber hinaus trägt auch die Funktion des transparenten Failovers nun in einem Cluster zu einer verbesserten Verfügbarkeit von Netzwerkfreigaben bei. Im Falle von Wartungsarbeiten oder eines Hardware- bzw. Softwarefehlers kann nun der aktive Knoten der Netzwerkfreigabe geändert werden, ohne dass dies einen Einfluss auf geöffnete Dateien oder laufende Datentransfers hat, lediglich ein kurzes Zucken bei der Performance dürfte sich bemerkbar machen.

Viele weitere Neuerungen

Was natürlich nicht fehlen darf ist, dass Windows Server 2012 nun wieder deutlich größere Hardware unterstützt. Die größten Verbesserungen gibt es dabei im Bereich der Virtualisierung. Mit Hyper-V gehostete virtuelle Maschinen können nun bis zu 64 CPU Kerne zugeordnet werden, virtuelle Disks dürfen bis 32 TB wachsen und einer VM kann bis zu 1TB Arbeitsspeicher zugeordnet werden. Damit wird Hyper-V nun auch zum Hosten für Rechen- und Speicherintensive Anwendungen, wie einem Enterprise Datawarehouse, interessant.

Daneben stehen natürlich eine Vielzahl weiterer Neuerungen des Windows Server 2012, die hier nicht alle behandelt werden können, wie z.B. eine integrierte Funktion zur Datendeduplizierung, Neuerungen in RemoteFX unter anderem zur Unterstützung mehrerer Client-Monitore, die neue virtuelle Switch-Architektur in Hyper-V und und und!

Und wie ist das jetzt mit dem SQL Server?

Dass die erhöhte Hardwareunterstützung ein Vorteil für große SQL-Server-Installationen ist und zu Konsolidierungszwecken genutzt werden kann, dürfte auf der Hand liegen. Auch bei der möglichen größeren Ausstattung von VMs ist Ähnliches möglich, doch die wirklich spannenden Verbesserungen bringen die oben angesprochenen SMB 3.0 Features mit sich.

Um bei einem SQL-Server eine hohe Transaktionsperformance erreichen zu können wird bis Windows Server 2008 R2 meistens auf Fibre-Channel-Anbindung von SANs gesetzt, ein recht teures Unterfangen. Die Preise in Rechenzentren belaufen sich je nach Geschwindigkeit des Fibre-Channel-Adapters zwischen 1,5 € und 3,0 € pro GB pro Monat.
Nach Angaben von Microsoft (basierend auf der Hewlett Packard Preisliste Mai 2012) sollen sich durch die Nutzung von SMB via Infiniband oder 1GbE Netzwerkkarten ein bis zu 90% geringerer Preis ermöglichen lassen.
Bei einem vergleich von mehreren zusammen geschalteten 1Gbit Ethernet-Netzwerkkarten mit SMB+ gegen 4Gbit Fibre-Channel zeigte sich gerade mal ein Verlust von 2% bei 4300 SQL-Transaktionen pro Sekunde.

Für den SQL Server Administrator ändert sich dadurch nicht viel. Während bisher ein per Fibre-Channel angebundenes SAN als Windows-Laufwerk auf dem Host oder der virtuellen Maschine bereit gestellt worden ist, kann nun einfach ein Netzwerkpfad als Speicherort für Datenbankdateien und Transaktionsprotokolle angegeben werden.
Der SQL Server 2008 R2 unterstützt diese Konfiguration jedoch nur eingeschränkt, so ist es beispielsweise nicht möglich die Systemdatenbanken (master, msdb, model) auf einer Netzwerkfreigabe abzulegen oder Netzwerkfreigaben im SQL Server Cluster zu nutzen.

Von großem Nutzen sind aber auch die Verbesserungen in Hyper-V. SQL-Server-Installationen werden immer öfter virtualisiert, was oft nicht gerade zur Freude von Datenbankadministratoren geschehen ist. Oftmals waren die Beschränkungen in Sachen CPU-Kern und RAM-Unterstützung ein Hindernis, aber gerade in kleinen Umgebungen, die nicht über eine SAN Verfügen, waren Offlinezeiten beim Verschieben einer virtuellen Maschine ein Ärgernis. Durch die Unterstützung von VHDx-Dateien auf SMB 3.0 Dateifreigaben und die Shared-Nothing-Livemigration sind diese Probleme nun auch gelöst und können Datenbankadministratoren ruhiger schlafen lassen, wenn ihr Server virtualisiert worden ist.

Zu guter Letzt möchte ich noch auf eine Neuerung hinweisen, die Performance für SQL-Server mit hoher I/O-Last bringt. In Windows Server 2012 werden Laufwerke 4K-Sektorgrößen nun nativ unterstützt. Seit 2009 stellt die Industrie von Speichermedien schrittweise auf 4K (statt bisher 512bytes) Sektoren, da bei fortschreitender Miniaturisierung die kleinen Startblöcke vor dem Sektor und Prüfblöcke nach dem Sektor immer schwieriger anzusteuern sind. Somit bietet es sich an die Sektoren zu vergrößern und damit auch einen größeren Start-und Prüfblock auf dem Speichermedium anzulegen.
Da jedoch die Betriebssysteme weiterhin von einem 512byte-Sektor ausgehen müssen die Laufwerke einen Emulationsmodus bereitstellen. Dies bedeutet auch, dass wenn das Betriebssystem eigentlich nur einen 512byte Sektor schreiben möchte, muss das Laufwerk acht Sektoren schreiben, womit das Betriebssystem jedoch nicht rechnet. Somit sind bei vielen Lese/Schreiboperationen deutliche Performanceverluste möglich, ein Szenario das gerade bei virtuellen Maschinen und SQL-Servern eintritt.

Fazit: Windows Server 2012 bringt viele Verbesserungen im Speichermanagement mit, die zu Leistungsverbesserungen und signifikanten Kosteneinsparungen genutzt werden können. In jedem Fall wird dies die Herzen von Datenbankadministratoren und Kostenverantwortlichen höher schlagen lassen.

Post im Original im PTS BI Blog http://biblog.ptsgroup.de/sql-server/windows-server-2012neue-features-fr-den-sql-server/

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).

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.

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/ 

Wer meinen Blog seit einiger Zeit liest wird sich sicher noch an den Artikel Windows Home Server im Eigenbau erinnern.

Auf der damals installierten Hardware habe ich auch ein Update auf Windows Home Server 2011 durchgeführt und war mit dem Ergebnis durchaus zufrieden.
Im Laufe der Zeit habe ich beobachtet, dass doch mehr interessante Home Server-Hardware auf den Markt gekommen ist und habe mich entschiedenen den Mini-Tower durch einen formschönen Server von HP auszutauschen.

Die Wahl fiel auf den HP MicroServer G7 N40L. Neben der kompakten Bauform und der Stromspar-CPU von AMD fiel mitinsbesondere die RemoteManagement-Karte ins Auge.

Diese beiden Komponenten inklusive der Arbeitsspeichererweiterung habe ich bestellt und prompt geliefert bekommen.

Unpacking HP ProLiant MicroServer G7 N40L

Der quadratische Karton enthält den kompakt gebauten Server. Dazu wurde die remote Management Karte in einem weiteren kleinen Karton geliefert.

Das kleine Gehäuse verfügt über zahlreiche Front- und Back-USB-Anschlüsse, einen eSata-Anschluss sowie VGA und Gigabit-LAN-Anschluss.

Zum Öffnen des Gehäuses werden zwei Schlüssel benötigt, worauf sich eine wirklich vorbildliche Platzoptimierung zeigt. Allerdings: Alle Schrauben im Inneren sind mit Torks-Einkerbungen versehen, d.h. mit dem häuslichen Schraubenzieher hat man keine Chance. Nach verzweifelten Versuchen entdeckte ich irgendwann den Imbusschlüssel in der Seitentür. Dann noch flix den Arbeitsspeicher sowie die Remote Management Karte eingebaut und los kann es gehen … oder?

Inbetriebnahme

Der Annahme jetzt einfach einen USB-Stick mit dem Home Server 2011-Image einstecken zu können machte HP allerdings einen Strich durch die Rechnung. Dem Gerät lag noch ein Zettel bei, der darauf hinwies unbedingt zuerst ein BIOS Update zu installieren.
Das gestaltete sich jedoch gar nicht so leicht, da die betreffende URL nicht existierte.

Nach einer Recherche auf der HP Homepage fand sich dann aber doch die Produktseite des MicroServers an. Nach der Erstellung eines DOS USB Sticks lief das Update Problemlos von statten. Die Installation des Windows Home Servers dauerte etwa eine halbe Stunde inklusive Konfiguration. Dies war, denke ich, jedoch nur durch die schnelle Festplatte möglich, die ich in den Server eingebaut habe. Die Wahl fiel auf eine Seagate Barracuda 7200.10 ST2000DM001, SATA-III, 64MB Cache mit 2TB Kapazität.

Das Remote Management

Die remote Management Oberfläche präsentiert sich sehr überflüssig, erlaubt das Anlegen mehrerer Benutzer und die Überwachung sowie Steuerung des Servers. An Überwachungsfunktionen steht der Zugriff auf die Rotationsgeschwindigkeit des Gehäuselüfters, den Temperaturfühlern sowie die Möglichkeit bei bestimmten Ereignissen Alert-Emails zu verschicken.

Wirklich interessant sind aber die Funktionen zum Ein/Ausschalten des Servers aus der Ferne sowie zur Fernsteuerung. Diese erfordert allerdings Java auf dem Client und funktioniert nur, wenn man sich im selben Netz, wie der Server befindet – ein Durchleiten der Ports über einen Router funktioniert nicht.

Ab und zu (ca. 2 Mal im Monat) hängt sich die Karte leider auf und loggt einen aus, nachdem man einen Menüpunkt betätigt, dies lässt sich nur durch einen Neustart des Servers beheben. Ich finde aber bei dem geringen Preis des Severs lässt sich mit dem Manko durchaus leben.

Energieverbrauch

Diese Angaben dürfen natürlich nicht fehlen.
Es zeigen sich folgende Verbrauchswerte:

Ruhemodus: 2,5W (inkl. Remote Management Karte)
Leerlauf: 28W
Volllast: 48W (Schreiben auf Datenträger + 100% CPU Auslastung)

Der Verbrauch ist geringfügig höher, als bei meinem alten Server, was angesichts der schnelleren Festplatte und der Remote Management Karte aber auch durchaus legitim ist. Insgesamt dürfte das Performance pro Watt Ergebnis sich verbessert haben.

Links

HP ProLiant MicroServer G7 N40L bei Amazon
HP ProLiant MicroServer Treiber und BIOS bei HP
Windows Home Server 2011 bei Amazon

Neben einer neuen SQL Server Version erwartet uns in Kürze auch eine neue Version des Self-Service-BI-Tools PowerPivot! PowerPivot ist ein kostenloses Addon für Microsoft Excel 2010, welches den Umgang mit besonders großen Datenmengen erlaubt.

Die derzeit aktuelle Version PowerPivot 10.5 (basierend auf SQL Server 2008 R2) wird zusammen mit diesem Feature als einfaches Tool beworben Daten zu analysieren, die den Rahmen von Excel (sprich 1048576 Zeilen) sprengen. Durch die Komprimierung der VertiPaq-Engine geschieht dies sogar sehr flott und mit geringem Arbeitsspeicheraufwand.

Der Version 10.5 sind jedoch auch einige Grenzen gesetzt. Viele Anwender vermissen eine grafische Darstellung der importierten Datenstrukturen, sodass ein gewisses Verständnis für Datenbanken erforderlich ist, um mit PowerPivot umgehen zu können. Experten hingegen vermissen Features aus der multidimensionalen Welt, insbesondere den DrillThrough. In Version 2012 kommt Microsoft beiden Anwendergruppen einige Schritte entgegen.

Diagrammsicht in PowerPivot 2012

Für eine etwas intuitivere Bedienung sorgt in Version 2012 die Diagrammsicht, welche übrigens auch im neuen BI-Studio (basierend auf Visual Studio 2010) eingeführt wurde. Alle Referenzen werden nun in einem Datenbankdiagramm dargestellt, die Entitäten sind manuell beliebig anzuordnen und auch die aus Analysis Services bekannten Perspektiven erlauben es Ordnung in größere Modelle zu bringen.

Etwas betrüblich an dieser Stelle ist, dass das Erstellen von Beziehungen zwischen zwei Tabellen noch über den selben Dialog wie in PowerPivot 10.5 läuft. Ein Erstellen von Beziehungen mit der Maus, wie es bei Microsoft Access möglich ist, würde das Paket abrunden. Auf diese Funktion dürfen wir wohl vielleicht in der Folgeversion hoffen.

Hierarchien und KPIs

Aus der Welt von Analysis Services finden noch weitere Features Einzug in PowerPivot. Das Definieren von Hierarchien gestaltet sich in der Diagrammsicht sehr einfach. In der oberen rechten Ecke findet sich an jeder Entität ein Symbol zum Erstellen einer neuen Hierarchie. Es wird eine leere Hierarchie hinzugefügt, in die per Drag and Drop dann Spalten hineingezogen werden können. Die erste Spalte stellt dabei die oberste Hierarchieebene dar usw..

Das Erstellen eines KPIs ist im Release Candidate noch etwas kniffliger. Der Button “KPI erstellen” suggeriert, dass es möglich wäre in der Diagrammsicht einen KPI zu definieren. Es ist jedoch notwendig in die Datensicht zu wechseln und dort in der unteren Hälfte der Anzeige ein neues Measure zu definieren. Nur auf neu definierte Measures kann dann ein KPI erstellt werden.

Im folgenden Beispiel ist der Durschnitt aller Internetverkäufe aus der beliebten AdventureWorks-Datenbank als Measure per Data Analysis Expressions (DAX) definiert. Das Dreifarbige Symbol neben dem Wert zeigt an, dass auf diesem Measure bereits ein KPI definiert wurde. Etwas irritierend an dieser Stelle ist auch, dass im Fall der AVERAGE-Funktion im PowerPivot-Fenster bei Währungswerten ein um den Faktor 10.000 zu großer Wert angezeigt wird. In der Excel-Pivot-Tabelle stimmt es aber dann wieder (rechtes Bild).

Drillthrough

Ein kleines, aber feines, neues Feature ist der im nun verfügbare Drillthrough. Versuchte man in der bisherigen PowerPivot-Version auf einer Pivot-Tabelle die Funktion “Details anzeigen” aufzurufen, erhielt man lediglich die Meldung, dass diese Funktion nicht verfügbar sei.

In PowerPivot 2012 führt Excel auf die hinterlegten Daten eine Abfrage aus und schreibt das Ergebnis in ein neues Tabellenblatt, welches dann vom Benutzer durchsucht werden kann. Standardmäßig werden 1000 Zeilen abgefragt, reicht dieses nicht, kann der Benutzer in der Registerkarte Daten auf Verbindungen gehen und dort in den Eigenschaften der PowerPivot-Verbindung die Anzahl Zeilen erhöhen. Dies muss jedoch geschehen, bevor Details anzeigen geklickt wird.

Fazit

Microsoft hat in der neuen Version einige wichtige Verbesserungen eingebaut, jedoch sind einige Funktionen teilweise noch zu umständlich zu Bedienen, sodass der Anwenderkreis kleiner ist, als er sein müsste.
Verschiedene Bugs stören in der RC0 noch, so konnte ich für diesen Bericht keinen Performancevergleich zwischen PowerPivot 10.5 und 2012 durchführen, da beim Import meiner Testdatenbank in der Version 2012 ein Fehler aufgetreten ist. Diesen werde ich nachreichen, sobald die finale Version erschienen ist.

Weiterführende Literatur

Getting started with DAX – Eintrag in der MSDN
Microsoft PowerPivot(TM) for Excel 2010: Give Your Data Meaning
PowerPivot for the Data Analyst: Microsoft Excel 2010

Dieser Artikel wurde auch im Business Intelligence Blog der PTS Group AG veröffentlicht

Kommende Woche findet ein Treffen des PASS Deutschland e.V. in Bremen statt.
Dort werde ich einen Abriss über die neuen Funktionen in SQL Server Denali geben und die CTP3 auch vorführen.

Alle Interessierten sind herzlich eingeladen.

Stattfinden wird das Treffen am 14.09. von 18 bis ca. 21 Uhr in der Linzer Straße 4 in Bremen bei der PTS Group AG.
Die Räumlichkeiten befinden in der Nähe der Universität.

Ich freue mich auf euer Erscheinen.

Mit dem Release von SQL Server 2008 R2 hat Microsoft die Einsatzgebiete des SQL-Servers erweitert, indem neue Features und Editionen geschaffen wurden. Oftmals wird von SQL-Server Fast Track als eine neue Edition gesprochen. Doch dies ist nicht richtig, denn Fast Track liegt eine Enterprise Edition zugrunde – aber was ist Fast Track dann?

Ende 2009 veröffentlichte techconsult im Auftrag von Microsoft eine Studie, welche dem SQL-Server einen Anstieg des Marktanteils in Deutschland, gemessen an den verkauften Lizenzen, auf 26,1%. Damit wurde der Konkurrent Oracle (21,3%) erstmalig überholt, was vor allem auf die Lizenzpreise zurück geführt wurde.
Doch der Preis ist nicht immer das ausschlaggebende Argument für eine Lösung. Bei unternehmenskritischen Lösungen spielen Kriterien wie Stabilität und Performance möglicherweise eine deutlich größere Rolle. Und wer kennt diese Probleme im Software-Dschungel nicht. Das Beste Software-Produkt kann in verschiedenen Umgebungen sehr unterschiedliche Leistungswerte erreichen und auch mit der Stabilität ist es manchmal nicht weit her.
Hier lohnt sich ein Blick auf den Markt für SmartPhones. Mit Windows Mobile konnte Microsoft hier keinen Fuß fassen, dieses System ist zwar hochflexibel und anpassbar, doch genau dies führte zu einer Vielzahl von Installationen, wie sie unterschiedlicher nicht sein könnten. Viele Modelle frieren regelmäßig ein oder leiden unter geringer Geschwindigkeit – für manchen Technikfreak kein Problem, für die Allgemeinheit nervtötend. Apple war der erste Hersteller, der Software und Hardware bei Smartphones optimal aufeinander abstimmte und setzte damit einen neuen Trend, der einschlug wie eine Bombe.
Genau diese Idee liegt SQL Server Fast Track zu Grunde – Software und Hardware werden perfekt aufeinander abgestimmt. In der Praxis heißt das: bestimmte Hardware-Konfigurationen werden nach intensiven Tests als Fast Track-geeignet zertifiziert und mit dem hübschen Titel “Fast Track Referenz-Architektur” geschmückt.

Die Fast Track Architektur

Um eines vorweg zu nehmen: Fast Track eignet sich nicht für jedes Anwendungsszenario, genau genommen ist Fast Track speziell für Data Warehouses im Bereich von 4 bis 48TB Daten entwickelt worden.

Ein Fast Track-System besteht aus einem physischen Server, der über Fiber-Channel an mindestens eine SAN angeschlossen ist. Kleinere Fast Track-Systeme sind skalierbar und können durch das Einbauen von RAM sowie CPUs und Anschließen weiterer Storage-Einheiten weiter ausgebaut werden.
Das Fast Track-System beheimatet idealerweise das Data Warehouse sowie die Staging-Datenbanken, führt jedoch selbst keine ETL-Prozesse aus, beinhaltet keine Cubes, keine Data Marts und auch keine FrontEnd-Anwendungen.

Damit ist der Anwendungsbereich stark eingeschränkt. Wird dieser genauer betrachtet, ist dieses aber auch schlüssig. Data Warehouses werden klassischerweise mit großen Datenmengen aus den Vorsystemen gefüllt, daraus werden wieder große Datenmengen ausgelesen um Data Marts oder multidimensionale Datenbanken aufzubauen.
Für diese Szenarien ist mit einer Fast Track-Architektur ein signifikanter Performance-Vorteil möglich, da Hardware- und Softwarekonfiguration auf sequentielles Lesen und Schreiben optimiert sind, zufällige Lese- und Schreibvorgänge, und damit aufwändiges Neupositionieren der Schreib/Leseköpfe, werden vermieden. So ist es möglich, dass für diese Szenarien die Performance der Installation voraus berechnet werden kann bzw. die Dimensionierung des Servers berechnet werden kann, wenn die voraussichtlichen Workloads bekannt sind.

Technischer Einblick

Microsoft schreibt eine Reihe von Anforderungen an ein Fast Track System vor und stellt diese anhand eines Beispielsystems mit zwei AMD-Opteron Prozessoren und insgesamt acht CPU-Kernen vor. Um diesen Artikel allgemeiner zu halten werden basierend auf den AMD-Konfiguration folgende Variablen definiert und im weiteren Verlauf des Textes verwendet. Für Intel basierte Systeme ist das Verhältnis der CPU-Kerne pro CPU anders.

n  -  Anzahl SQL-Server Datenbanken (beliebig)
k  -  Anzahl CPU-Kerne
p  -  Anzahl verwendeter Prozessoren
s  -  Anzahl verwendeter Storage-Einheiten (SAN)
f  -  Anzahl verwendeter Festplatten insgesamt
r  -  Anzahl RAID-1-Paare je Storage-Einheit

• Minimum 4 GB RAM je Kern
• Lokal mindestens zwei Festplatten im RAID-1 für OS und SQL-Server Installation
• Je physischer CPU wird in der Regel eine Speicher-Einheit zugeordnet, also s = p.
  Im Endeffekt wird je verfügbaren CPU-Kern ein Platten-Paar für Datenbankdateien sowie ein Platten-Paar je CPU-Sockel für Protokolldateien benötigt.
  f = 2*k + 2*p
• Verbindung zum Speicher, in Form eines SANs, muss über Fiber Channel erfolgen
  Der Bereich im FC-Switch muss isoliert sein, ebenso muss Multipath I/O (MPIO) verwendet werden
• Im SAN werden die Platten in RAID-1-Paaren à zwei Platten konfiguriert.
  Die Anzahl der RAID-1-Paare ist f / 2.
  Je Storage Einheit ergibt sich r = f / (2*s)
• Jede LUN muss als separates Laufwerk in Windows erscheinen oder als separates Verzeichnis eingebunden werden

Damit dieses Kraftpaket seine Leistung auch wirklich entfalten kann, muss die Konfiguration der Datenbanken nach den üblichen Empfehlungen erfolgen, nur dass diese hier nicht auf Laufwerke, sondern LUNs zugeordnet werden.

• Für die Datenbanken und TempDB werden paare aus zwei LUNs mit zwei Platten gebildet. In die ersten r Gruppen werden die Datenbanken gleichmäßig aufgeteilt, sie bestehen dann jeweils aus einer mdf- und r-1 ndf-Dateien
• Die Protokolldateien werden auf einer LUN abgelegt, welche aus der verbleibenden RAID-1-Gruppe besteht. Es werden n+1 ldf-Dateien abgelegt.
  • Der Speicher der Datenbankdateien wird bereits im Dateisystem reserviert, das automatische Datenbankwachstum ist deaktiviert

Die folgende Grafik zeigt Beispielhaft die Dateistruktur im RAID auf einer Speichereinheit.

Benchmark-Ergebnisse

Der Erfolg oder Misserfolg einer Fast Track Konfiguration misst sich in der Maximum CPU Core Consumption Rate (MCR), wobei dies für die Datenmenge steht, die ein einzelner CPU Kern bei einer Standardabfrage verarbeiten kann, unter der Annahme, dass die Daten Seitenkomprimiert vorliegen.

Mit dem Referenzsystem bestehend aus 2x AMD Opteron CPUs mit je vier Kernen = 8 Kerne gesamt, 4x 8Gbps Fiber Channel HBA Anschlüsse auf zwei SANs wurde im Test bei Microsoft eine MCR von 200 MB/s erreicht, das sind also 1.600 MB/s Leistung des Gesamtsystems.
Ein Ergebnis, das sich sehen lassen kann.

Spielregeln bei Fast Track

Um den SQL-Server dazu zu bringen zufällige Schreib/Lesevorgänge zu vermeiden, muss das Datenbankdesign wohl durchdacht sein. Die Empfehlungen hierfür sind im Architektur-Referenz-Handbuch für Fast Track genau beschrieben und bestehen im wesentlichen aus folgenden Punkten:

• Microsoft empfiehlt für Tabellen, die in der Regel komplett, oder zumindest zu einem großen Teil abgefragt werden, den Einsatz von Heap-Tabellen. Wobei hier gleich eine Einschränkung gesetzt wird, denn Heap-Tabellen erreichen ihren maximalen Datendurchsatz bei 32 Datenbankdateien, weshalb auf Data Warehouse-Ebene für Faktentabellen der Einsatz von Heap-Tabellen auf Fast Track Systemen nur bis 16 CPU-Kerne empfohlen wird.
  Ist dies der Fall sollte nach Art der Abfrage partitioniert werden, bei dem Aufbau von Cubes sollte sich die Partitionierung an der des Cubes ausrichten
• Tabellen mit gruppierten Indexen werden logischerweise empfohlen, wenn erwartet wird, dass Abfragen häufig auf einen bestimmten Schlüssel erfolgen. Sinnvoll kann ein gruppierter Index auch sein, wenn nach Datum partitioniert wurde. Die Verwendung von gruppierten Indexen in anderen Fällen sollte genau überdacht werden, da der Index, und somit die Daten, möglicherweise fragmentiert, was zufällige Lese/Schreibvorgänge und somit starke Performanceeinbrüche zur Folge hätte.
  Auch hier ist das A und O wieder die gut überlegte Wahl der Partitionierung.
• Nicht gruppierte Indexe sollten nach Möglichkeit vermieden und wirklich nur dann eingesetzt werden, wenn es Abfragen mit einer sehr kleinen Anzahl von Zeilen geben sollte
• Um der Fragmentierung Herr zu werden sollten Indexe nicht reorganisiert, sondern neu aufgebaut werden. Bei dem Neuaufbau eines Index sollte SORT_IN_TEMPDB = True gesetzt sein, um eine Fragmentierung der Dateigruppe vorzubeugen

Diese Regeln sind im Bezug auf ein idealtypisches Data Warehouse schlüssig. Abweichende Anforderungen, durch Wünsche des Auftraggebers oder mangelndes Wissen des Architekten, können bei einem Fast Track-Projekt leicht zu einer Herausforderung werden. Die Beachtung dieser Regeln ist wärmstens zu empfehlen, um erfolgreich ein schnelles Fast Track Datawarehouse zu implementieren.

Weitere Informationen

Gibt es bei Microsoft.

• An Introduction to Fast Track Data Warehouse Architectures
• Fast Track Data Warehouse 2.0 Architecture

Dieser Artikel wurde auch im Business Intelligence Blog der PTSGroup veröffentlicht

Ende letzten Jahres haben Microsoft und Attunity vereinbart die Change Data Capture (CDC) Technologie von Attunity in den neuen SQL Server einfließen zu lassen (Pressemeldung von Attunity).  Microsoft wird somit die seit SQL Server 2008 vorhandene CDC Technologie um eine neue Ergänzen oder Ablösen, Grund genug dieses genauer unter die Lupe zu nehmen.

Arbeitsweise des CDC auf LogFile Basis

Eine CDC Technologie ermöglicht es in nahezu Echtzeit Veränderungen an einer Datenbank festzustellen, um dann diese veränderten Daten in eine andere Datenbank zu kopieren. Ein klassischer Anwendungsfall für die Verwendung von CDC ist der Aufbau von Data Warehouses, da so statt sehr langläufiger ETL-Prozesse, in kurzen Abständen kleine Datenmengen geladen werden können. So kann das Data Warehouse deutlich aktueller gehalten werden und die Last auf die Vorsysteme verteilt sich gleichmäßig. Ebenso kann CDC zur Auditierung genutzt werden, um Datensatzänderungen zu dokumentieren.

Oftmals wird CDC jedoch durch das Verwenden von Triggern implementiert, was eine permanent erhöhte Last und verringerte Performance in den Vorsystemen zur Folge hat. Die in SQL Server 2008 bereits integrierte, sowie die von Microsoft lizensierte Attunity-CDC Technologie basieren auf der Analyse von Datenbankprotokolldateien. Dies hat den Vorteil, dass dies außerhalb der Transaktionsklammer im Datenbankmanagementsystem erfolgt, weshalb Schreibvorgänge wie üblich abgeschlossen werden können. Erst das geschriebene Datenbankprotokoll wird zur Auswertung herangezogen, während dieses Prozesses können in der Datenbank wieder weitere Änderungen erfolgen.

Abgrenzung zum bisher im SQL Server integrierten CDC

Technisch gesehen sind bis zu diesem Punkt die bereits vorhandene Technologie sowie die von Attunity entwickelte identisch. Die Attunity-Lösung bietet im wesentlichen folgende Vorteile

• Sie wird als Windows Dienst außerhalb des SQL-Servers ausgeführt und ist abwärtskompatibel bis SQL-Server 2000
• Beliebige Editionen von SQL-Server werden unterstützt
• Auf dem Server, dessen Daten überwacht werden sollen, muss nichts installiert werden
• Es werden sogar weitere Systeme als Datenquelle, oder Ziel, unterstützt wie Oracle, oder DB2
• Integration in SSIS mit dem Business Intelligence Development Studio

Die Architektur ermöglicht es somit direkt eine Vielzahl von Systemen anzubinden und könnte einem so manche Entwicklung von ETL Paketen ersparen. Ebenso ist der letzte Punkt interessant für jeden BI Entwickler im Microsoft Umfeld.

Das CDC von Attunity

Durch einen Download der Demoversion von CDC für SSIS kann sich bereits jetzt ein Einblick verschafft werden, wie die Technologie in Denali aussehen könnte.

Nach der Installation lässt sich über Visual Studio 2008 in einem Integration Services Projekt die Definition eines CDC Dienstes erstellen. Dies geschieht über einen neuen Kontextmenüeintrag “Attunity SQL-Server CDC” im Integration Services Projekt. Der Eintrag “Configure CDC Service” startet einen Assistenten, der den Entwickler durch die Einzelnen Schritte führt.

Im ersten Schritt wird die Datenquelle definiert, die überwacht werden soll. Schritt zwei ist das Angeben von Parametern, wie einem Port, des zu erstellenden CDC Dienstes. Der CDC-Prozess wird als Windows Dienst auf den späteren ETL Server erstellt werden, für die Entwicklung erstellt der Assistent auch eine Instanz dieses Dienstes auf dem Entwicklungsrechner bereit.

Als nächstes werden die zu überwachenden Tabellen ausgewählt, in denen der CDC Dienst Änderungen auswertet. Der Assistent generiert nun ein SQL-Skript, das auf dem Datenbankserver ausgeführt werden muss, um CDC lauffähig zu bekommen.
Zum Schluss wird überprüft, ob alle Operationen geklappt haben und der Dienst lauffähig ist.

Nun ist der Dienst eingerichtet. Als nächstes können mit einem weiteren Wizard über den Eintrag “Generate CDC Packages” SSIS Pakete generiert werden. Der Wizard fragt zuerst nach einem Connection String für die Zieldatenbank und fordert den Benutzer dann auf ein Mapping auf Zieltabellen zu erstellen bzw. diese ggf. sogar noch zu erstellen. Der Mapping Dialog zeigt dabei übersichtlich die Eigenschaften der Datenfelder, wie Typ, Länge, oder NULL-Fähigkeit an. Werden besonders viele Tabellen durch CDC verwaltet ist es sinnvoll im nächsten Schritt Tabellengruppen festzulegen. Zum Schluss besteht noch die Auswahlmöglichkeit ein Paket zum Vollständigen und eines zum Inkrementellen Laden zu erstellen.

Ein Blick auf die Pakete zeigt von Attunity eigens entwickelte ControlFlow-Elemente, welche zur Synchronisierung mit dem CDC Dienst dienen. Interessanter ist der Einblick in die Datenfluss Elemente. Das initiale Laden wird hier schlicht mit einer OLE DB Quelle sowie mit einem OLE DB Ziel vorgenommen, wobei zuvor die Daten im Ziel mittels eines T-SQL-Statements abgelöscht wurden. Der inkrementelle Ladevorgang enthält Attunity-eigne Datenflusselemente, welche über den CDC-Dienst Änderungen aus den Protokolldaten auslesen und dann in der Zieltabelle entsprechend verarbeiten.

Fazit

Das Produkt ist vielversprechend und deckt Szenarien ab, zu denen der SQL Server aktuell nicht in der Lage ist. Jedoch stellt sich die Frage, wie Microsoft die Lizensierung handhaben wird. Bisher ist Change Data Capture nur in der Enterprise- und Datacenter-Edition verfügbar und bietet nicht die Möglichkeit SQL Server niedrigerer Editionen einzubeziehen. Es ist daher durchaus denkbar, dass der CDC Host mindestens über eine SQL Server Denali Enterprise Edition verfügen muss, damit dieses Feature für andere Datenbanksysteme genutzt werden kann.

Dieser Artikel wurde auch im Business Intelligence Blog der PTSGroup AG veröffentlicht

PHP unter Windows war schon immer eine Odysse. Inzwischen ist es zwar sehr einfach möglich PHP direkt zu installieren, ja sogar die FastCGI Konfiguration im IIS klappt automatisch, doch sobald man auf die Idee kommt sich mit dem SQL Server verbinden zu wollen, wird es spannend.

Seit PHP 5.2.0 ist der Treiber für den SQL-Server standardmäßig nicht mehr bei PHP mitgeliefert, da es seitdem einen Treiber von Microsoft gibt, für den sogar offiziel Support geleistet wird und ja sogar in Open Source. Mittlerweile ist der Treiber in der Version 2.0 erhältlich und liefert eine Vielzahl von DLL-Dateien mit, welche für die verschiedenen PHP-Versionen gedacht sind (Version, Compiler, Threadsicherheit).
Hat man den richtigen Treiber in das ext-Verzeichnis kopiert und in der php.ini eingetragen zeigt sich der Treiber in phpinfo() unter dem unscheinbaren Namen sqlsrv.
Die Suche nach dem richtigen Treiber kann man sich ersparen, indem PHP sowie den Treiber über den Web Platform installer installiert werden.

Doch beim Testen meldet PHP erst mal nichts, dafür muss das Error Reporting in der php.ini aktiviert werden. Dies geschieht indem display_errors = On gesetzt wird.
Dann erscheint die Meldung "Call to undefined function mssql_connect()".
Hier steckt der Teufel im Detail, denn die in der PHP-Dokumentation erwähnten Befehle sind für den alten PHP-eigenen Treiber gedacht. Microsoft lässt einen zum Glück nicht im Stich und stellt in der MSDN eine API-Referenz bereit: http://msdn.microsoft.com/library/cc296152(v=SQL.90).aspx
Der Wehrmutstropfen dabei ist, dass nicht nur die Befehle anders heißen, als bisher, sondern obendrein auch noch die Parameter geändert wurden. Das bedeutet also viel Spaß beim Anpassen bereits existierender Software.

Dies weckt alte Erinnerungen an die Umstellung von PHP 3 auf PHP 4, als die Servervariablen alle nun unter einem Array erreichbar waren und alle Anwendungen angepasst werden mussten, was wirklich ärgerlich war.
Aber immerhin: Es funktioniert!

Dieser Artikel ist auch im PTS BI Blog veröffentlicht: http://biblog.ptsgroup.de/sql-server/sql-server-treiber-fur-php-unter-windows-richtig-verwenden/