SQL Practice Blog – SQL Server, BizTalk und .NET Erfahrungen

Archive for the ‘SQL Server’ Category

SQL Management Studio: Connect and Queries take so long

leave a comment »

When I connect to my local SQL Server using SQL Management Studio or SQL Operations Studio and want to execute queries, it sometimes takes several minutes to execute.

This setting in Internet Explorer’s Internet Options solved my problem:

  • Open Internet Explorer
  • Go to Tools -> Internet option
  • Open the „Advanced“ tab
  • Uncheck „Check for server certificate revocation (requires restart)“

 

1a9c2cf90ff6a62dc42dddcb742a04ac

Advertisements

Written by Robert Meyer

April 16, 2018 at 09:42

SQL Server 2012: EOMONTH Funktion

leave a comment »

Mit dem SQL Server 2012 ist eine neue Datumsfunktion dazu gekommen. Mit EOMONTH ist es möglich sich den letzten Tag des Monats ausgeben zu lassen. Dies ist besonders interessant wenn man Wertebereiche innerhalb eines Monats oder über mehrere Monate Tag genau selektieren möchte.

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

image

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

image

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

Written by Robert Meyer

August 7, 2012 at 13:18

Veröffentlicht in SQL Server

Tagged with , ,

Paging mit OFFSET und FETCH im SQL Server 2012

leave a comment »

Lange hat es gedauert, doch nun beherrscht der SQL Server mit Version 2012 endlich das Paging. Unter Paging versteht man die Festlegung davon wie viele Datensätze pro Seite ausgeben werden sollen. Dies wird besonders bei diversen Webapplikationen benötigt um die Anzahl der geladenen Daten zu verringern. Würde die Suche auf einer Website ein Trefferergebnis von 400 Datensätzen betragen, möchte der Nutzer sicherlich nicht alle 400 Datensätze mit einmal auf der Website sehen, sondern z.B. immer nur 20 Stück. Diese 20 Datensätze werden jetzt auf 20 Seiten aufgelistet. Damit der Traffic möglichst gering bleibt, werden auch immer nur die Datensätze der aktuellen Seite geladen. Das nennt man Paging.

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.

image

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.

image

Expressions in OFFSET und FETCH

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

image

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

Written by Robert Meyer

Juli 19, 2012 at 07:25

Veröffentlicht in SQL Server

Tagged with , , , , ,

Update auf große Datenmengen mit @@ROWCOUNT

leave a comment »

Häufig steht man vor der Herausforderung in einer sehr großen Tabelle Datensätze zu aktualisieren. Hat diese z.B. wie in meinem Szenario über 10 Millionen Datensätze und einen Trigger der auf Update Commands reagiert, ist es nicht sehr sinnvoll mit einem mal mehr als 1000 Zeilen zu aktualisieren. Hierbei kann es zu ungewollten Table Locks kommen. Noch problematischer wird es, wenn während des Zeitpunktes des Updates viele Abfragen auf dieser Tabelle ausgeführt werden.

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

image

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:

image

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.

Written by Robert Meyer

Juli 11, 2012 at 10:38

Veröffentlicht in SQL Server

Tagged with , , ,

Generieren von DML und DDL Skripten aus einer bestehenden Datenbank

leave a comment »

Häufig begegnet einem in einen Entwicklungsprozess von Software der Vorgang das man Datenbank mit Test- oder Initialdaten von einem SQL Server auf verschiedene andere SQL Server verteilen möchte.

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.

image

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.

image

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

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

Written by Robert Meyer

November 2, 2010 at 10:34

Veröffentlicht in SQL Server

Tagged with , , , ,

SQL Server 2008 R2: Unicode Compression

leave a comment »

Als Teil meiner Serien “SQL Server 2008 R2 – Alles nur BI? möchte ich euch heute ein weiteres neues Features des SQL Servers 2008 R2 vorstellen. Die Unicodekomprimierung!

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.

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

image

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.

Written by Robert Meyer

Mai 12, 2010 at 10:04

SQL Server 2008 R2: Überblick über die Editionen

leave a comment »

Den SQL Server 2008 R2 gibt es in neun verschiedenen Editionen. Diese Editionen kann man grob in drei Kategorien einteilen:

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

Written by Robert Meyer

April 30, 2010 at 09:53