SQL Server & BI Blog by Andreas Wolter

(DE)

Was für ein Jahr: nachdem ich bereits  3 SQLSaturdays (Dänemark, Niederlande, Deutschland) hinter mir habe, werde ich nun auch auf dem SQSaturday #258 (5. Okt.) in Istanbul sprechen.
Und nach meiner ersten PreCon dieses Jahr auf dem SQLSaturday in Deutschland, die ich zusammen mit Mladen Prajdić, zum Part “XEvents” gegeben habe, werde ich dieses mal einen ganzen Tag PreCon (4. Okt.) zum Thema “Performance Analyse & Tuning Techniken” geben!

(EN)

What a year: after already 3 SQLSaturdays (Denmark, Netherlands, Germany) behind me, I will now also speak at SQSaturday #258 (Oct. 5th) in Istanbul, Turkey.
And after my first PreCon this year at the SQLSaturday in Germany, which I was co-presenting together with Mladen Prajdić, on the part “XEvents”, I will now be giving a full day PreCon (Oct. 4th) on “Performance Analysis & Tuning Techniques”!

Ich freue mich wirklich sehr über das Thema und zugleich auch über den Austragungsort.
Istanbul ist für Geschichts- & Fotografie Enthusiasten wie mich ein absolutes Muss. (Meine Facebook Wand erwartet wieder tolle Bilder :)

Zurück zum Technischen: Hier ist die Vortrags-Beschreibung & Agenda:

Sei bereit für einen vollen Tag Abtauchen in SQL Server Performance Analyse.
Diese Session konzentriert sich auf Werkzeuge und Techniken und wie man häufige Probleme löst.
Wir starten auf Betriebssystem-Ebene mit PerfMon, und steigen dann weiter ein in SQL Server Wait Stats Analyse für Flaschenhalsanalyse. Wir verwenden verschiedene Werkzeuge wie SQL Trace & Profiler und den Nachfolger: Extended Events für detaillierte Analyse und sehen auch, welche anderen Tools von Codeplex zur Verfügung stehen.
Wir untersuchen den Plan Cache und Indexierung mithilfe von DMVs und steigen schließlich auch in Sperren und Parallelitätsprobleme ein.
Macht Euch auf viele Demos und einen Deep Dive in Kern-Konzepte von SQL Server gefasst.“

I am really excited about the topic and location at the same time. Istanbul is a must-see city for history- & photography enthusiasts like me. (My Facebook wall is awaiting great images :)

Back to the technical stuff. Here is the session description & agenda:

“Be ready for a full day of diving into SQL Server Performance Analysis.
This session is focussed on tools and techniques and how to resolve common problems.
We will start on Operating System level using Perfmon and advance into SQL Server Wait Stats analysis for identifying bottlenecks. We will use different tools like SQL Trace & Profiler and the successor: Extended Events for detailed analysis and see what other tools are available from codeplex. We will examine the Plan cache and Indexing using DMVs and finally get into locking & concurrency problems.
Expect lots of demos and a deep dive into core concepts of SQL Server.”

Enthaltene Themen:

• Performance Monitor für Server-Ebenen Performance Analyse
• Wait-Stats Methodik
• SQL Trace & Profiler bis Extended Events für Arbeitslast & Abfrage-Analyse
• Tempdb Performance Optimimierung
• Plan-Cache Analyse
• Index & Statistiken, Analyse & Tuning
• Sperren & Blockade Analyse / Parallelitätsprobleme

Included Topics:

• Performance Monitor for Server-Level Performance Analysis
• Wait-Stats Methology
• SQL Trace & Profiler to Extended Events for Workload & Query-Analysis
• Tempdb Performance Optimization
• Plan-Cache Analysis
• Index & Statistics, Analysis & Tuning
• Locking & Blocking Analysis / Concurrency problems

And hier ist der Link zur PreCon (4. Okt.) Registrierung: www.eventbrite.com/event/7619115981

Wer ein Wochenende in einer historischen Stadt voller Sehenswürdigkeiten mit deep-dive SQL Server Themen kombinieren möchte, ist gern willkommen :-)

And here is the link to the PreCon (4th of Oct.) registration:
www.eventbrite.com/event/7619115981

If you want to combine a week-end in a city of history and beauty, with some deep-dive SQL Server topics, come and join us :-)

Neben der PreCon werde ich auch einen Vortrag am Samstag (5. Okt) halten.

Thema: Sicherheit

Titel: "SQL Attack…ed” – SQL Server under attack."

Und auch zwei weitere Kollegen von der PASS Deutschland e.V. werden dabei sein: Tillmann Eitelberg und Oliver Engels.

Besides the PreCon I will also hold a presentation on Saturday (5th of Oct.).

Topic: Security

Title: "SQL Attack…ed” – SQL Server under attack."

And also two other colleagues from the German PASS will be there: Tillmann Eitelberg and Oliver Engels.

(DE)

Auf dem diesjährigen SQLSaturday in Deutschland habe ich wieder einmal einen meiner Sicherheitsvorträge gehalten, in denen ich mich auf „Angriff“ konzentriere. Für mich eine gute Gelegenheit, mich wieder einmal intensiv mit SQL Server Sicherheit und einigen Penetrationstest-Tools auseinanderzusetzen, und SQL Server auf Fallstricke in Sachen Sicherheitskonfiguration zu untersuchen. Am Ende hatte ich eine lange Liste an möglichen Demonstrationen, worunter auch eine von mir frisch entwickelte DoS-Attacke via SQL Injection zählt (zumindest habe ich nirgends einen Hinweis auf eine Beschreibung dieser Art Angriff gefunden oder auf meine Nachfragen erhalten), sowie eine „privilege elevation“(Privilegienerweiterung)-Attacke, die in dieser Form auch noch unbekannt zu sein scheint. – Alles jedoch unter Ausnutzung von angepassten Einstellungen, und keine Schwächen in der Engine(!).

Da es speziell zu SQL Server kaum nennenswerte Sessions in Deutschland zu diesem Thema gibt (selbst auf den Summits in den USA war ich damit meist recht allein unterwegs), und mir das Thema in dieser Tiefe natürlich auch besonders Spaß macht, habe ich mich entschieden, hier meine möglichen Themen zu sammeln. Ich werde sie nicht nur auf weiteren kommenden Konferenzen in Europa oder USA präsentieren, sondern auch den Regionalgruppen der deutschen PASS anzubieten – die sich hier sozusagen im „Menü“ bedienen können :-)

An einem Abend schafft man vermutlich maximal ein Drittel der möglichen Themen. – Und damit wälze ich nun die Qual der Wahl auf die Kollegen RGVs ab ;-)

(EN)

At this year’s SQLSaturday in Germany I have shown one of my sessions again, in which I concentrate on “attack”. For me a great opportunity to dive deep into SQL Server Security and several penetration-test-tool, and to explore SQL Server for pitfalls and security configuration. At the end I had a long list of possible demonstrations. Among them a just recently developed DoS-attack via SQL Injection (at least I did not find any clue on a description for this kind of attack anywhere or got an answer on my inquiries), as well as a “privilege elevation”, which in this form seems to be quite unknown as well. – Everything is just done by exploiting customized settings and not by weaknesses in the engine (!).

Since there are barely any nameable sessions on this topic specifically for SQL Server in Germany (even at the Summits in the US I tended to be quite alone with my sessions on security), and I enjoy this topic in this a lot, I have decided to collect all possible topics here.
I will not only present them on upcoming conferences in Europe or the US, but also I am offering these to the regional chapter leaders in Germany  – “serve yourself” - style :-)

Session Beschreibung:

SQL Server kann als "secure by default" gelten, aber da das am häufigsten erfolgreich angegriffene Ziel die Daten, die in der Datenbank liegen, sind, möchte ich in dieser Session für das Thema sensibilisieren.
Die meisten der ausgenutzten Schwachstellen in einer SQL Server Umgebung sind auf Miss-konfiguration, schwache Sicherheitseinstellungen oder ungenügende Programmierpraktiken zurückzuführen.

In dieser rein Demo-basierten Session werden verschiedene Angriffsszenarien auf verschiedenen Ebenen gezeigt. Auf speziellen Wunsch auch einige Advanced SQL-Injection Beispiele. Des Weiteren zeige ich, wie eine „privilege elevation“ aufgrund einer nicht unüblichen Einstellung möglich ist und die Ausnutzung von Rechten mit einem Datenbank-Rootkit durch einen "Insider".

In dieser Art Vortrag gebe ich natürlich keine Anleitung "wie man hackt", sondern ich beleuchte häufige Schwachstellen - "Was kann unter welchen Umständen passieren".

Session Description:

SQL Server is considered "secure by default", but one of the most often successfully attacked targets is the data that resides in a Database Server.
Most of the exploited weaknesses in a SQL Server environment are due to misconfiguration weak security settings or inadequate coding practices.

In this purely demo-based security session, I am showing several attack scenarios on different layers. Due to special request this includes some special SQL Injection types. Furthermore I show how an evaluation of privileges attack is possible due to a not uncommon configuration as well as an “insider-exploit” with a database root kit.

Note that in this kind of session I do not give instructions on “how to hack” but rather I am highlighting common weaknesses - “what can happen and under which circumstances”.

(Web)Application Layer

• Mein Formular und die WAF lassen nichts durch – oder doch?
  • Standard SQL Injection
  • Blind / Error-based /Time-based SQL Injection, Encoding Injection
  • 2nd Order SQL Injection
  • Privilege Escalation über SQL Injection und trustworthy
  • Automatisierte Attacken mit Tools, weitere „Features“ (sqlmap,...)
  • “Der Fall der nicht-terminierbaren Transaktion“ -  DoS Attack über SQL Injection (von mir "erfunden" für den SQLSaturday Germany 2013)

• Schwachstellen in Zeilen-basierter Sicherheit
• XML Bomb
• Spaß mit Zeichensätzen
  • Tabellen ohne Namen? – Oder überhaupt keine Tabellen?
    „Garantiert eindeutige Objektnamen“ ;-)

(Web)Application Layer

• My form and the WAF don’t let anything pass through – or do they?
  • Standard SQL Injection
  • Blind / Error-based /Time-based SQL Injection, Encoding Injection
  • 2nd Order SQL Injection
  • Privilege Escalation via SQL Injection and trustworthy
  • automated attacks using tools, further “features” (sqlmap,...)
  • “case of the unkillable transaction” - DoS Attack via SQL Injection ("invented" by me for SQLSaturday Germany 2013)

• SQL Server Row- and Cell-Level Security – Disclosure vulnerability
• XML Bomb
• A bit of fun with collation
  • Tables without a name? Or no tables at all?
    “guraranteed unique object names” ;-)

Innerhalb des Netzwerk

• Aufklärung: Erkennen von SQL Server Instanzen
• SQL Authentifizierung
• Beobachten von SQL Traffic (Login + Select)
• Automatisierte brute-Force Attacke gegen sa-Passwörter

Inside the Network

• Reconnaissance: Detecting SQL Server Instances
• SQL authentication
• Watching SQL Traffic (Login + Select)
• Automated brute-Force Attack against sa-passwords
  

Server & Datenbank-Ebene – Angriffe von Innen, Teil 1: der böse Consultant

• SQL Authentifizierung
  • Cracken von Passwörtern – möglich? Wie?
  • Auslesen von Passwörtern aus dem Arbeitsspeicher
• Was ein Consultant so hinterlassen kann
  
  • Automatisierte Einrichtung eines SQL Server Rootkits
• „Wenn der Gast die Party wechselt“
  • Umgehen von Denies durch „guest-guest-impersonation“ – erstmalig gezeigt auf dem PASS Summit 2010 in Seattle :-)

Server & database-Level – attacks from inside, Part 1: evil Consultant

• SQL authentication
  
  • Cracking Passwords – possible? How?
  • Reading passwords from memory
• What a Consultant may leave behind
  
  • Automated install of a SQL Server rootkit
• „When the guest switches the party“
  • Circumventing denies by “guest-guest-impersonation“
    – first shown at PASS Summit 2010 in Seattle :-)

Server & Datenbank-Ebene – Angriffe von Innen, Teil 2: der böse Entwickler

• „Kenne Deine Rechte“
  • "Transfer-Schema Attack"
    – erstmalig gezeigt auf dem PASS Summit 2010 in Seattle :-)

• „Alles meins“ – oder nicht?
  • Datenbankbesitzverkettung
  • Db_owner unterschätzt & ausgenutzt
  • Schema-ownership-chaining

Server & database-Level – attacks from inside, Part 2: evil Developer

• „Know your rights“
  • "Transfer-Schema Attack"
    – first shown at PASS Summit 2010 in Seattle :-)
• „Everything belongs to me“ – does it?
  • Database-ownership-chaining
  • Db_owner underestimated & exploited
  • Schema-ownership-chaining

Alias "Apollo ist gelandet"

(Apollo war der Codename für das Columnstore Index-Projekt vor SQL Server 2012)

(DE)

Während In-Memory Processing mit XTP die Grundlage für die Veränderung in der Verarbeitung von OLTP im SQL Server 2014 formt (Update 09-2013: XTP werde ich auf der TechNet Conference erstmalig  in Deutschland präsentieren), wurde für OLAP/Datawarehouse-Systeme die Columnstore Indexe fundamental verbessert. Tatsächlich sind die Neuerungen so gewaltig, das es sich vorhersehen lässt, das Columnstore (spaltenorientiertes Speichern) mit dem SQL Server 2014 der Standard Speichertyp für DataWarehouses wird (zumindest für Systeme, welche die Enterprise Edition verwenden).

Beginnen wir mit einem Blick auf das, was wir mit SQL Server 2012 erhalten und zugleich vermisst haben, als ColumnStore Indexe eingeführt wurden:

aka "Apollo has landed"

(Apollo was the Codename for the Columnstore Index project before SQL Server 2012)

(EN-US)

Whereas In-Memory Transactional Processing with XTP builds the foundation for the shift in processing OLTP in SQL Server 2014, for OLAP/datawarehouse-systems Columnstore Indexes have been improved fundamentally. In fact the improvements are so huge, that it can be foreseen that Columnstore will become the standard type of storage for DataWarehouses starting in SQL Server 2014 (at least for systems running Enterprise Edition).

Let’s start with what we had and missed at the same time so far, in SQL Server 2012 when Columnstore Indexes were introduced:

1. Ein Non-clustered columnstore index (ab hier jetzt abgekürzt als NCCI) pro Tabelle – der geclusterte war weiterhin row-basiert
2. Keine DML Unterstützung: keine Updates (Datenaktualisierung) – größte Einschränkung für nahe-Echtzeit DataWarehouses und ständige Aktualisierungen
3. Mittelmäßiges memory management – z.B. wurde der Resource Governor nicht beachtet
4. Kein Batch hash join spilling
5. Eingeschränkte Datentypen Unterstützung – ok, Ich persönlich habe wenig Probleme damit, da es Entwickler dazu animiert/zwingt, Spalten-Datentypen und Tabellendesign bewusst zu wählen (wir erinnern uns, das, Columnstore Indexe hauptsächlich für Faktentabellen in DataWarehouses gedacht waren), aber das ist nur meine persönliche Meinung dazu :-)
6. Eingeschränkte Batch Operationen unterstützt– ein nicht unterstützter Operator führte zu row-mode-Verarbeitung der gesamten Abfrage

1. One Non-clustered columnstore index (I’ll refer to that as NCCI from now on) per table – the clustered was still row-based
2. No DML support: no updates (data refresh) – biggest bummer for close to real-time DataWarehouses and continuous updating
3. Mediocre memory management – i.e. Resource Governor not honored
4. No batch hash join spilling
5. Limited data types support – ok, I personally have little problems with that as it forced developers to wisely chose column-types and table design (remember, that columnstore indexes were mainly meant for FactTables in DataWarehouses), but that’s just my personal opinion on that :-)
6. Limited batch operations supported – one unsupported plan operator led to row-mode processing of the whole query

Aus dieser Liste bereiten sicherlich die folgenden Dinge die größten Probleme unter SQL Server 2012: Updates auf columnstore indexierte Tabellen sind nur mittels drop NCCI/Daten laden/create NCCI oder partition switching möglich und zum zweiten: viele Abfragen erhalten nicht einmal den vollständigen möglichen performance-Schub durch den NCCI, weil eine nicht unterstützte Operation im Abfrageplan stattfindet.

Auf der TechEd Europe 2013 in Madrid wurde die CTP1 des  SQL Server 2014 als öffentlich verfügbar verkündet (www.insidesql.org/blogs/andreaswolter/2013/06/ctp1-sql-server-2014-release-techedeurope ) und da detaillierte Informationen über die gewaltigen Verbesserungen endlich offiziell sind, kann ich die guten Neuigkeiten mit meinen Lesern teilen (Ein großes Dankeschön an Igor Stanko vom Parallel Datawarehouse-Team bei Microsoft, der alle Fragen im Detail beantwortet hat, während er mit mir und anderen MCMs und MVPs am Microsoft Stand "gefangen" war;-) )

Zu den Fakten:

Out of that list, probably the biggest issues in SQL Server 2012 are, that updates to columnstore indexed tables are only possible by drop NCCI/load data/create NCCI or partition switching and secondly: many queries actually do not get even get all of the possible performance gain from the NCCI because of an unsupported operation inside the query (plan).

At the TechEd Europe 2013 in Madrid CTP1 of SQL Server 2014 was announced publically available (www.insidesql.org/blogs/andreaswolter/2013/06/ctp1-sql-server-2014-release-techedeurope ) and as detailed information on the big improvements are finally official, I can share the good news with my readers (Big Thanks to Igor Stanko from the Parallel Datawarehouse-Team at Microsoft who answered all questions in detail, while "bound" with me and other MCMs and MVPs at the Microsoft booth ;-) )

To the facts:

Im SQL Server 2014,

1. Können wir einen Clustered Columnstore Index (CCI) anlegen
2. sind Clustered Columnstore Indexes mit Standard DML-Operationen aktualisierbar! – das funktioniert über eine delta store und einem tuple mover, der ein einmal volles Segment in columnstore konvertiert
   
3. ist Memory Management dynamisch und Resource Governor Einstellungen werden beachtet
4. unterstützt (Hash Join) Spilling den Batch Mode
5. funktioniert ein Mix von row und batch mode innerhalb einer Abfrageausführung
6. haben wir mehr unterstützte Operatoren im Batch Mode (Outer Join, partial Aggregates, Union All)
7. erhalten wir mit dem neuen Komprimierungstyp
   “COLUMNSTORE_ARCHIVE” weitere 30% Komprimierung für die ausgewählte Tabelle/Partition
8. werden mehr Datentypen unterstützt (decimal mit hoher Präzision, (var)binary, uniqueidentifier)

In SQL Server 2014,

1. We can create a Clustered Columnstore Index (CCI)
2. Clustered Columnstore Indexes will be Updatable with standard DML-Operations! – this works via a delta store and a tuple mover, that converts a once full segment into column store
   
3. Memory management is dynamic and honors resource governor settings
4. (Hash Join) Spilling now supports Batch Mode
5. Mixed row and batch mode inside query execution now works
6. We have more supported operators in batch mode (Outer Join, partial Aggregates, Union All)
7. The new compression type: “COLUMNSTORE_ARCHIVE” adds another 30% compression for chosen table/partition
8. More data types are supported (high precision decimal, (var)binary, uniqueidentifier)

– Diese Verbesserungen in Kombination können schwerlich überschätzt werden, da sie letztlich zu einer Schlussfolgerung führen:

“Columnstore (und clustered columnstore Index) wird die BEVORZUGTE Storage Engine für DW Szenarien”

(das ist ein original Microsoft-Zitat - und ich habe keinen Grund, das irgendwie anders zu auszudrücken)

Hinweis: Das Clustered Columnstore Index Feature wurde von dem Parallel Data Warehouse (PDW)-Team für die PDW Version 2012 entwickelt, welche Anfang 2013 released worden ist. (Danke an Henk van der Valk für die Erinnerung an diesen nicht unerheblichen Fakt.)

Und hier ist ein Vergleich der  möglichen Speicherplatz-Ersparnisse bei der Verwendung von CCI gegenüber allen anderen Indexierungs-Methoden bisher (herausgegeben auf der TechEd 2013 - ich lasse das Diagramm für sich selbst sprechen):

– Those improvement combined can hardly be overestimated as they ultimately lead to one conclusion:

“Columnstore (and clustered columnstore index) will be PREFERRED storage engine for DW scenarios”

(this is an official quote from Microsoft - and I see no need to say it any differently)

Note: The Clustered Columnstore Index feature is was actually developed by the Parallel Data Warehouse (PDW)-Team for the PDW Version 2012 which was released in the beginning of 2013. (Thanks, Henk van der Valk for reminding me of that not so insignificant fact.)

And here is a comparison of the possible space savings when using CCI over any other indexing methods so far (released at TechEd 2013 - I'll let the graph speak for itself):

Nach all den guten Neuigkeiten: Ist da noch etwas, was uns fehlt, bei der Verwendung von ColumnStore? Ich möchte auch die wenigen Dinge, die noch schmerzen können, nicht vergessen:

1. keine Constraints, die Indexe verwenden, werden unterstützt, noch nicht einmal Fremdschlüssel ohne Index. Wenn solchermaßen benötigt wird, muss man zum hybriden Ansatz mit NCCIs wechseln und Partition switching oder eine andere Methode wie zuvor verwenden.
2. Auch DML-Trigger sind mit CCIs nicht möglich.
3. Nur der Vollständigkeit halber: keine anderen Indexe sind möglich, wenn ein CCI auf einer Tabelle vorliegt. Aber dafür wäre auch keine Verwendung mehr, wie der aufmerksame Leser bis hier sicherlich erkannt hat :-)

After all the good news: Is there anything that we might still miss when using ColumnStore? I do not want to forget to mention the few things that might still hurt:

1. No constraints using index are supported, not even Foreign Keys without index. So if such is needed, one has to revert to using a hybrid approach with NCCIs and using partition switching or any other of the methods as before.
2. Also DML-Triggers are not possible with CCIs.
3. Just for completeness: no other indexes are possible when a CCI is present on a table. But there is no use for it anyways, as the attentive reader might have noticed by now :-)

Als Datawarehouse-Architekt bin ich begeistert und freue mich auf die ersten Implementierungen von DataWarehouses unter SQL Server 2014. Das Index-Design wird viel einfacher, in einigen Umgebungen sogar trivial. - Man möge beachten, dass ich nicht "Database-Design" schrieb: Ein geeignetes Datenbank-Design (Hinweis: "Star-Schema") ist weiterhin notwendig um die maximal mögliche Performance herauszuholen - nicht vergessen, dass Batch-Mode-Verarbeitung und Segment-elimination die Schlüssel zum Maximum sind.

So, as a datawarehouse-architect I am really excited and looking forward to the first implementations of Datawarehouses under SQL Server 2014. The index-design will become much easier, in fact in many environments even trivial. - Note, that I am not using the word “database-design” itself: A proper database-design (hint: “star-schema”) is still necessary to get the maximum performance gain possible – don’t forget that batch mode processing and segment elimination are the keys to the max.