So wendet man EOMONTH an, um sich den letzten Tag des Monats August im Jahr 2012 ausgegeben zu lassen:

Man kann jedoch auch Monat dazu addieren oder abziehen. Hierfür steht ein optionaler Operator zur Verfügung.

Es ist nur eine kleiner Erweiterung, aber sie erleichtert doch auf angenehme Art die Arbeit mit TSQL.

Möglichkeiten mit dem SQL Server 2012

Mit dem SQL Server 2012 kommen unter anderen zwei neue Befehle welche in der ORDER BY Klausel genutzt werden können:

• OFFSET
  Legt fest wie viele Datensätze übersprungen werden, bevor Datensätze zurückgegeben werden.
• FETCH
  Gibt an wie viele Datensätze nach der OFFSET Klausel angezeigt werden sollen

Beispiel

In dem Beispiel werden Kundendaten selektiert, welche mit dem Nachnamen Meyer beginnen. Allerdings werden die ersten 40 Zeilen übersprungen und von da an 20 Zeilen selektiert.

Varianten von OFFSET und FETCH

Anstelle von NEXT kann man auch FIRST genutzt werden, es handelt sich hierbei nur um ein Synonym. Das gleich gilt für das Wort ROWS, hier kann auch ROW genutzt werden. Anstelle der direkten Anzahl der Datensätze bei OFFSET oder FETCH kann hier auch eine Variable zum Einsatz kommen. Dies könnte zum Beispiel so aussehen und wäre im zusammenhangen mit dynamisches Stored Procedures recht interessant.

Expressions in OFFSET und FETCH

Es ist ebenfalls möglich Expressions im Zusammenhang von OFFSET und FETCH zu nutzen. Hier ein Beispiel:

Zur Verfügung stehen die Erweiterungen OFFSET und FETCH bereits ab dem SQL Server 2012 Express.

Der erste Lösungsansatz bei diesem Problem ist ein eingeschränkter Update Befehl auf 1000 Zeilen. Diese kann man mit einem UPDATE TOP (1000) und ebenso mit dem Befehl SET ROWCOUNT 1000 erreichen (Siehe Beispiele).

Möchte man nun etwa 100000 Zeilen aktualisieren empfiehlt es sich hierfür eine Schleife zu bauen. Außerdem sollte nach jedem Updatebefehl eine Wartezeit von 1-3 Sekunden eingefügt werden, damit andere Anfragen die Möglichkeit haben Sperren zu setzen. Dies erreicht man durch den Befehl WAITFOR DELAY. Hier ein Beispiel:

Der gesamte Updatevorgang kann dadurch etwas länger dauern, man minimiert jedoch die Wahrscheinlichkeit von Locks über die ganze Tabelle und erlaubt z.B. Triggern optimaler zu arbeiten.

Hierfür stellt Microsoft verschiedene Wege zur Verfügung, welche aber alle in der einen oder anderen Weise an eine Technologie gekoppelt sind. Hier wären als Beispiel die SQL Server Integration Services (SSIS) aufzuzählen. Diese erzeugen ein SSIS Packet, welches wiederum durch das installierte Feature SSIS Daten auf verschiedene andere Datenbanken verteilen kann.
Eine andere Möglichkeit besteht darin, T-SQL Skripte mit dem SQL Server Management Studio zu erzeugen. Diese Skripte beinhalten jedoch nur DDL Befehle, welche zum erzeugen von Datenbanken, Tabellen, Stored Procedures etc. benötigt werden. Jedoch werden keine DML Befehle inkludiert welche für das Erzeugen und Bearbeiten von Datensätzen zuständig sind.

Der einzige Weg, den Microsoft anbietet, führt über Visual Studio. Im Visual Studio öffnet man den Server-Explorer und verbindet sich mit der Datenbank in der sich die Tabelle befindet, von der ein T-SQL Skript erzeugt werden soll. Für die gewünschte Tabelle öffnet man das Kontextmenu und wählt den Eintrag Publish to provider aus.

Daraufhin startet ein Assistent der durch den Vorgang führt. Als ersten Schritt muss man hier nochmals die gewünscht Datenbank auswählen. Als nächsten Schritt entscheidet man sich für ein Ziel. Hier stehen die Möglichkeiten Script to file und Publish to shared provider zur Auswahl. Die erste Auswahlmöglichkeit dürfte klar sein, die zweit erlaubt das Ausführen des Skripts auf einem gehosteten SQL Server.

Im nächsten Schritt des Assistenten können nun verschiedene Generierungseinstellungen für das T-SQL Skript definiert werden:

• Drop existing objects in script
  Wird diese Eigenschaft auf True gesetzt, so wird als erstes in dem T-SQL Skript ein DROP Befehl für alle bestehenden Objekte definiert.
• Schema qualify
  Ist diese Eigenschaft auf True gesetzt, so werden die Objekt mit dem jeweiligen Schema erzeugt. Setzt man diese Eigenschaft jedoch auf False, werden nur die Objekte ohne Schemainformation erzeugt. Man sollte diese Eigenschaft auf True lassen.
• Script for target database
  Hier kann man die Version der Zieldatenbank definieren. Zur Auswahl stehen SQL Server 2000, 2005 und 2008.
• Types of data to publish
  Nicht immer möchte man die Daten und das Schema zusammenerstellen. Hier hat man die Auswahl für was das T-SQL Skript generiert werden soll. Für das Schema und die Daten (DDL + DML), nur das Schema (DDL) oder nur für die Daten (DML).

Als letzter Schritt zeigt der Assistent noch eine Zusammenfassung aller Einstellungen an. Danach wird das T-SQL Skript generiert.

Dies ist eine einfach Möglichkeit, mit der man schnell eine Datenbank von einem SQL Server auf einen anderen SQL Server übertragen kann wenn man keine direkte Verbindung zwischen den Servern aufbauen kann.

Die Datenkomprimierung gibt es im SQL Server schon seit der Version 2005. Seit dem SQL Server 2008 R2 ist nun auch möglich im Zuge der Datenkomprimierung die Komprimierung von Unicode durchzuführen. Aber was ist Unicode eigentlich? Betreibt man eine Website die unter mehreren Sprachen zur Verfügung bereit gestellt wird, unter anderem z.B. Japanisch, und die Inhalte aus dem SQL Server geladen werden, so bekommt man bei der Benutzung der Datentypen VARCHAR oder CHAR schnell Zeichenkonvertierungsprobleme.
Deshalb gibt es die Datentyp NVARCHAR bzw. NCHAR welche auch mit anderen Zeichen umgehen können, als der eingestellten Sprache des SQL Server.
Der Nachteil ist, das ein Zeichen in einer NVARCHAR oder NCHAR Spalte zwei Byte belegt. Speichert man das gleiche Zeichen in eine VARCHAR oder CHAR Spalte, so belegt ein Zeichen auch nur ein Byte.
Aus diesem Grund wurde die Unicodekomprimierung eingeführt um beim speichern von Zeichen, welche weniger Platz benötigen auch weniger Platz belegt wird.

Praktisch bedeutet das: Speichert man in ein Unicodefeld mit Unicodekomprimierung Zeichen des westlichen Alphabets, so spart man bis zu 50% des Platzes. Bei z.B. japanischen Zeichen spart man hingegen nur bis zu 15% Speicherplatz.

Wie aktiviert man die Unicodekomprimierung nun? Ich erwähnte bereits das die Unicodekomprimierung an die Datenkomprimierung des SQL Servers gekoppelt ist. Um die Datenkomprimierung für eine Tabelle zu aktivieren klickt man mit der rechten Maustaste auf die jeweilige Tabelle und wählt den Menupunkt Storage aus und dann den Eintrag Manage Compressions …, worauf sich ein Wizard öffnet mit dem man die Komprimierungsart auswählen kann. Hier stehen ROW oder PAGE zur Auswahl, wobei die Unicodekomprimierung für beide Komprimierungsarten zur Verfügung steht. Des Weiteren kann man in dem Wizard bereits erkennen wie groß die voraussichtliche Ersparnis des Festplattenspeichers sein wird. So eine Komprimierung geht aber immer mit einer höheren CPU Last einher, welche bei vielen Schreibvorgängen um die 10% liegen liegen kann.

Das ganze funktioniert natürlich auf per T-SQL Befehl der wie folgt lautet:

Wie groß der Nutzen für jeden selbst ist, muss getestet werden. Bei sehr großen Tabellen / Datenbanken mit Inhalten in verschiedenen Sprachen, lohnt es sich jedenfalls darüber nachzudenken die Unicodekomprimierung einzuführen.

• Premium Editionen
• Core Editionen
• Spezielle Editionen

Im folgenden werde ich die einzelnen SQL Server Editionen kurz erklären und die Einschränkungen aufzeigen.

Premium Editionen

Unter Premium Editionen findet man die größten und damit auch teuersten Lösungen des SQL Servers für große Datawarehouse Lösungen oder hochverfügbare und skalierbare Systeme.

• Datacenter
  Mit dem SQL Server 2008 R2 kommt zum ersten mal eine Datacenter Edition. Mit ihr hat man die beste Lösung in den Bereichen Sicherheit und Skalierbarkeit. Die Datacenter Edition unterstützt die meisten Features der Enterprise Edition. Besonders an der Datacenter Edition ist die Unterstützung von bis zu 256 logischen Prozessoren, bis zu 25 Instanzen in einem Utility Control Point (UCP), uneingeschränkte Virtualisierung und keine Speichereinschränkungen.
• Parallel Data Warehouse
  Diese Edition ist ebenfalls neu mit dem SQL Server 2008 R2 gekommen. Bei der Parallel Data Warehouse Edition handelt es sich um eine, speziell für große Data Warehouses, konzipierte Edition. Sie unterstützt die Massively Parallel Processing (MPP) Technologie und eine Hub-and-Spoke Architektur. Sie kann bis zu 1 Petabyte Daten in einer einzigen Solution verwalten.

Core Editionen

Unter den Core Editionen versteht man die klassische Standard und Enterprise Version. Im folgenden möchte ich nochmal auf die Unterschiede zwischen der Standard und der Enterprise Edition hinweisen.

• Enterprise
  Die Enterprise Edition stellt eine umfassende und sichere Plattform für anwendungskritische Daten bereit. Hinzu kommen Features wie SSIS, SSRS und SSAS. Sie kann bis zu acht Prozessoren und 25 Instanzen in einem einzigen Utility Control Point (UCP) verwalten. Des Weiteren werden PowerPivot für SharePoint, Datenkomprimierung, die Master Data Services unterstützt. Es können bis zu zwei Terabyte Arbeits-speicher adressiert werden. Weiterhin werden die klassischen Features wie Backupkomprimierung, Transport Data Encryption (TDE) und gespiegelte Backups unterstützt.
• Standard
  Die Standard Edition ist eine BI und Datenverwaltungsplattform für kleine bis mittlere Unternehmen. Sie unterstützt nicht alle Features der Enterprise oder Datacenter Edition, beinhaltet jedoch die meist-genutzten Features. Neu in der Standard Edition ist nun die Backupkomprimierung, welche vorher nur in der Enterprise Edition zur Verfügung stand. Die Standard Edition unterstützt nur bis zu vier Prozessoren und 64 GB Arbeitsspeicher. Des Weiteren werden nur bis zu zwei Failover Cluster Nodes unterstützt.

Spezielle Editionen

Mit dem SQL Server 2008 R2 kommen auch Versionen, welche auf ganze spezielle Anwendungsfälle bzw. Personen zugeschnitten sind.

• Developer
  Die Developer Edition entspricht zu 100% der Datacenter Edition. Diese Edition darf jedoch nur für die Entwicklung, für Testzwecke und zu Demonstrationen eingesetzt werden. Möchte man die installierte Developer Edition inkl. der entwickelten Lösungen live setzen, so kann man problemlos zu einer Enterprise Edition upgraden.
• Web
  Die Web Edition hat vor allem einen preislichen Vorteil. Sie ist dafür ausgelegt primär auf Webservern installiert zu werden und damit bei Webapplikationen zum Einsatz zu kommen. Sie unterstützt wie die Standard Edition bis zu vier Prozessoren und 64 GB Arbeitsspeicher. Sie unterstützt jedoch nicht die Premiumfeatures der Standard Edition.
• Workgroup
  Die Workgroup Edition befindet sich sowohl preislich als auch funktional noch eine Stufe unter der Web Edition. Sie ist die erste Edition mit einer eingeschränkten Datenbankgröße von 512 Terabyte pro Datenbank, desweitere unterstützt sie nur zwei Prozessoren und bis zu 4GB Arbeitsspeicher. Die Workgroup Edition ist ohne Probleme upgradefähig auf die Standard oder Enterprise Edition.
• Express
  Die Express Edition ist die kostenlose Version des SQL Servers. Die unterstützt seit dem SQL Server 2008 R2 nun eine maximale Datenbankgröße von 10 GB. Jedoch kann sie weiterhin nur einen Gigabyte Arbeitsspeicher adressieren und einen Prozessor nutzen. Diese Edition wird z.B. mit Visual Studio ausgeliefert und unterstützt kein SSIS und SSAS.
• Compact
  Die Compact Edition ist für mobile Geräte ausgelegt oder für Desktopszenarien wo kein SQL Server installiert werden darf, sondern nur mit einer Datenbankdatei gearbeitet werden soll. Sie ist kostenlos wie die Express Edition, ist aber jedoch in ihrer Funktionalität stark eingeschränkt.

Dazu habe ich mir überlegt Beiträge zu den folgenden Themen zu bringen:

• Überblick über die neuen Editionen des SQL Servers 2008 R2
• SQL Server Utility und Utility Control Point (UCP)
• Data Tier Applications
• Integration von SQL Azure in das SSMS
• Unicode Komprimierung
• Möglichkeiten von Monitoring mit dem SQL Server 2008 R2

Anfangen werde ich diese Woche mit einem Überblick über alle SQL Server 2008 R2 Versionen. Wenn ihr noch weitere Wünsche habt, welche ich berücksichtigen soll, so meldet euch doch einfach bei mir

Wenn ihr die neuen Features selbst ausprobieren möchtet, so könnt Ihr den SQL Server 2008 R2 auf der Seite von Microsoft bereits herunterladen (Download).

Der Unterschied beginnt schon damit, das sich ein Integerwert in der Regel fortlaufend erhöht und damit eine minimale Fragmentation des Index bewirkt. Ein weiterer Vorteil von dem Datentyp Integer ist dessen Größe. Ein Integer benötigt im Vergleich zum einer GUID sehr wenig Speicherplatz.

Manchmal jedoch reicht ein Integer nicht aus. Soll z.B. ein Datensatz über ein Unternehmen mit verschiedenen Standorten hinweg eindeutig sein, so wählt man meist eine GUID als ID.

Was ist ein Uniqueidentifier (GUID)?

GUID bedeutet Globally Unique Identifier und ist eine eindeutige Binärzahl. Für gewöhnlich generiert kein anderer Computer auf dieser Welt eine bereits erzeugte GUID ein zweites Mal. Eine neue GUID kann mit dem T-SQL Befehl NEWID() erstellt werden. Dazu wird die ID der Netzwerkkarte mit einer eindeutigen Zahl welche von der CPU Uhr stammt kombiniert. Das ergibt einen Globally Unique Identifier.

Welche Möglichkeiten zu erzeugen einer GUID gibt es?

Mit dem SQL Server ist es auf zwei Wegen möglich eine GUID zu erzeugen. Der erste und bereits angesprochene Weg, ist das erstellen einer GUID mit Hilfe der NEWID() Funktion. Ein anderer Weg ist das erstellen einer sequentiellen GUID, hierbei wird die erstellte GUID immer größer sein als die zuvor erstellte GUID. Dadurch entsteht eine fortlaufende GUID. Die Funktion dafür lautet NEWSEQUENTIALID() und kann jedoch nur in der DEFAULT Anweisung beim erstellen oder bearbeiten einer Tabelle angegeben werden.

Praktisches Beispiel:

Wir erstellen eine Tabelle mit zwei Spalten, einer ID Spalte als Primary Key welcher mit NEWID() bzw. NEWSEQUENTIALID() automatisch erstellt wird und einer Value Spalte, wo ein beliebiger Wert gespeichert wird. In diese Tabelle fügen wir nun mit Hilfe einer Schleife 2000 Datensätze ein. Danach werden wir uns folgende Indikatoren ansehen:

• Größe des Clustered Index
• Fragmentierung des Clustered Index
• Anzahl von Seiten die der Clustered Index benötigt

Als erstes erstellen wir eine Tabelle, welche in der ID Spalte eine GUID mit der NEWID() Funktion erstellt.

Nun füllt eine WHILE Schleife die Tabelle mit 2000 Datensätzen. Die Funktion REPLICATE sorgt dafür das der Buchstabe A so oft repliziert wird wie der Wert Variable @i gesetzt ist.

Als nächsten Schritt müssen wir nun die drei Indikatoren auswerden. Um die Speicherplatzbelegung des Index auszulesen, bedienen wir uns der sp_spaceused Stored Procedure.

Um die Fragmentierung und die Anzahl der Seiten auslesen zu können, sprechen wir die sys.dm_db_index_physical_stats Funktion an. Als Übergabewert müssen wir hier die DatabaseID und die ObjectID angeben.

Wir führen das Script aus und notieren uns die Werte. Danach löschen wir die Tabelle und erstellen die Tabelle erneut, nur diesmal nutzen wir anstatt NEWID() die NEWSEQUENTIALID() Funktion zum erstellen der GUID.

Das Ergebnis ist eindeutig. Die sequenzielle GUID belegt weniger Speicherplatz und benötigt damit auch weniger Seiten. Am deutlichsten ist der Unterschied wohl bei der Fragmentierung zu sehen, hierbei spielt die NEWSEQUENTIALID() ihre ganze Stärke aus. Da die neue GUID immer höher sein muss als die zuvor erzeugte GUID, entsteht in dem Index keine Unordnung und damit auch keine Fragmentierung. Ich habe zum Vergleich mal die Werte eine Primary Key Spalte mit dem Datentyp Integer dazugetan.

Wenn man keine absolut eindeutige ID benötigt, so sollte man auf einen Integer zurückgreifen. Dieser lässt den Index nicht so schnell wachsen und fragmentiert diesen auch nur minimal.

Was sind Trigger?

Ein Trigger ist ein Datenbankobjekt, welches z.B. auf einer Tabelle oder einer Datenbank liegen kann und auf
Ereignisse reagiert. Es wird nach drei Arten von Triggern unterschieden:

DML Trigger
Kommen bei INSERT, UPDATE oder DELETE auf eine Tabelle oder Sicht zu Einsatz

DDL-Trigger
Reagieren auf Data Definition Language Events (CREATE, ALTER, DROP)

LOGON-Trigger
Reagieren auf LOGON Events

Ich möchte heute jedoch nur auf die DML Trigger eingehen und dessen Einsatz an einem ganze praktischen
Beispiel einmal zeigen.

Beispiel:

Gegeben ist folgende Tabelle:

Es handelt sich zugegeben um eine sehr einfache Tabelle, jedoch lässt sich damit der Umgang mit Triggern sehr gut erläutern.
In der Tabelle werden die Prüfdaten für ein Gerät gespeichert, d.h. wann ein Gerät zuletzt geprüft wurde und in
welchen Intervall (Monate) es wieder geprüft werden muss.

Hierbei kommt der Trigger zum Einsatz, welcher berechnen soll wann die nächste Prüfung des Geräts ansteht. Dazu muss ich einen Trigger in der Tabelle DeviceCheck einsetzen welcher auf INSERT und UPDATE Anweisungen reagiert.

Syntax für einen DML-Trigger:

In unserem speziellen Fall würde der Trigger wie folgt aussehen:

Dieser Trigger wird ausgeführt wenn ein INSERT oder UPDATE Befehl auf die Tabelle DeviceCheck abgefeuert wird. Dabei wird der Intervall mit dem letzten Prüfungsdatum addiert und der Datensatz in der Datenbank aktualisiert.

Fazit

Ein Trigger ist oftmals ein guter Helfer, jedoch sollte man sich im Klaren sein wohin man die Logik packen möchte. Kommt die Logik ausschließlich in die Businesslogik des Projekts (z.B. .NET Applikation) oder ist es erlaubt Logik auch in Datenbankobjekte auszulagern? Was meint ihr? Außerdem sollte man drauf achten das man in Triggern keinen komplizierten Berechnungen ausführt, da sowas die Performance der Datenbank erheblich beeinträchtigen kann.

In den SSIS ist es möglich diverse Datenquellen, aus denen ich meine Daten beziehen kann, anzugeben. Ich möchte in diesem Beispiel Bezug auf eine ADO.NET Datenquelle nehmen. Dieser hinterlege ich beim Erstellen einen statischen Connection Manager, welcher sich immer zu der selben Datenquelle verbindet. Jedoch sieht es in der Praxis so aus, das ich mich häufig in verteilten Systemen bewege, also die Daten aus verschiedenen Quellen mit der selben Struktur extrahiere. Hierfür wäre es jedoch ein unnötiger Overhead genauso viele Connection Manager anzulegen wie ich Datenquellen habe. Sowas kann im schlimmsten Fall in die Hunderte gehen. Die zentrale Frage die sich daraus ergibt lautet:

Wie nutze ich dynamische Connection Strings bei ADO.NET Datenquellen?

Man benötigt als erstes eine Variable, in welche man den aktuellen Connection String hinterlegen kann. Dieser Connection String kann z.B. mit einem Script Task erzeugt bzw. aus einer beliebigen Quelle geladen werden. Hier ist es durchaus denkbar einen eigenen DataFlow Task zum Auslesen der Connection Strings zu erstellen. Auf der Abbildung rechts sieht man wie ein ControlFlow für dieses Szenario aussehen könnte.

Die Skriptkomponente muss dann den aktuellen Connection String in die Variable schreiben. Hier ist durchaus denkbar ein Array zu füllen, welches danach mit einer Schleife abgearbeitet werden kann. In der Schleife sollte sich dann der DataFlow Task befinden, welcher den ETL Prozess ausführt.

In dem DataFlow Task muss ich nun eine ADO.NET Datenquellen anlegen, für dich ich zuerst einen statischen Connection Manager erstellen muss. Nachdem das Erstellen der ADO.NET Datenquelle abgeschlossen ist, begebe ich mich in die Eigenschaften des erstellten Connection Managers. Dort kann man nun dem Punkt Expressions der Eigenschaft ConnectionString einen Ausdruck zuweisen. Hier wähle ich nun meine Variable aus, welche den Connection String beinhaltet. Siehe linke Abbildung. Sollte ich die erstellte Variable nicht auswählen können, so kann dies daran liegen, das die Variable für einen falschen Bereich deklariert worden ist.

Damit haben wir das Problem auch schon gelöst. Es gilt nur eins immer zu beachten: Die Struktur der Datenquellen muss identisch sein!