The Columnstore Indexes & Batch Mode Processing (R)Evolution in SQL Server 2014

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)

 Clustered ColumnStore Index Insert:
Clustered ColumnStore Insert

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

         http://www.sarpedonqualitylab.com/sql-images/sql-articles/1306_Space_Savings_Clustered_ColumnStore.png

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.

happy indexing

Andreas

CTP1 des SQL Server 2014 Released / öffentlicher Download

Tolle Neuigkeiten von der TechEd Europe in Madrid: Die CTP1 des SQL Server 2014 steht zum Download bereit!

Features, die in dieser Release schon enthalten sind:

Im Bild die Build Nummer des SQL Server 2014 CTP1: 11.9.9120 mit der Unterstützung für In-Memory Optimized Tables (XTP)

SQL2014 CTP1 XTP Support

 Und hier ein Clustered Columnstore Index (Typ 5)

SQL2014 CTP1 Clustered ColumnStore Index

Hier gehts zum Download: http://msft.it/6039kfa9

Tipp: Es gibt auch eine Azure-Version zum ausprobieren.


Grüße vom Microsoft-SQL Server Stand auf der TechEd in Madrid,

Andreas

Survey: Which Tracing and Analysis-Tools do you use for SQL Server?

 Umfrage: Welche Tracing und Analyse-Tools verwendet ihr für SQL Server?

(DE)
In meiner Session „Hasta la vista Profiler – Tracing with Extended Events“, die ich nun seit über einem Jahr bei diversen Gelegenheiten gehalten habe, habe ich die Zuhörer meist gefragt, welche Monitoring-Tools sie bisher verwendeten.

Ich möchte diese Stelle einmal nutzen, um einmal breit zu erheben, welche Werkzeuge von SQL Server Professionals zur Protokollierung und Analyse von Performance-Problemen verwendet werden. Um ein differenzierteres Bild zu erhalten, ist auch eine Einordnung in „Administrator“, und „Entwickler“ sicherlich interessant.

Die Ergebnisse werde ich auf dem kommenden SQLSaturday #230 am 12. Juli in St. Augustin auf der PreCon, „From SQL Traces to Extended Events. The next big switch.“, die ich zusammen mit Mladen Prajdic gebe, präsentieren, und später mit Sicherheit noch auf dem PASS Camp sowie bei weiteren Gelegenheiten der deutschen und auch internationalen PASS - und natürlich hier in meinem Blog selber. Die Antworten können natürlich auch anonym abgegeben werden.

Im Folgenden liste ich eine Reihe von geläufigen Tools auf.

Bitte gebt Eure Stimme einfach als Kommentar wie im folgenden Beispiel ab - ich gebe ALLE Antworten (außer reinem Spam und Werbung) frei, auch Oracle-Tools ;-)

(EN-US)
In my session Session „Hasta la vista Profiler – Tracing with Extended Events“, that I have been presenting at several occasions, I used to ask the audience, which tools they used for monitoring so far.

I would like to use this platform to survey on a broader range, which tools are being used by SQL Server professionals for logging and analyzing performance-problems. In order to get a differentiated result, a classification in “Administrator” and “Developer” is certainly also interesting.

The results will be presented first at the upcoming SQLSaturday #230 on the 12th of Juli in St. Augustin/Germany at the PreCon, From SQL Traces to Extended Events. The next big switch.“, which I will be giving together with Mladen Prajdic gebe, and later on certainly also at the PASS Camp and other occasions of the German and international PASS - and of course also here in my blog itself. You can of course also keep your comments anonymously.

In the following I am listing a series of common tools.

Please simply provide your vote as a comment like in the following example – I will publish ALL answers (except plain spam/ads), even Oracle-Tools ;-)

„Administrator and/or Developer“
A 3
B 1
D 2
L 0

Dabei stehen die Zahlen für // The numbers stand for:

3: fast immer // almost all the time
2: manchmal // sometimes
1: selten // rarely
-1: das Tool ist mir unbekannt // I haven't hear of this tool

- Die Auswahl “unbekannt” auf Anregung eines Lesers (Danke!).

Werkzeuge, die nie verwendet werden gerne einfach weglassen.

Und das ist die Auswahl an Tools:

The choice “unknown” at a reader’s suggestion (Thank you!).

Tools that are not used can be simply left out.

And these are the choices of tools:

A) ClearTrace
B) Datenbankoptimierungsratgeber // Database Engine Tuning Advisor
C) Dynamic Management Views (DMV's)
D) Event Notifications
E) Extended Events unter 2008/R2
F) Extended Events unter 2012
G) Management Datawarehouse (MDW) / Data Collection Reports
H) PAL
I) PerfMon
J) RML Utilities / ReadTrace
K) SQL Diag
L) SQL Profiler
M) SQL Trace
N) Software von Drittherstellern – siehe auch O) // Third-Party Tools - also see O)
O) Andere // Other: …

- Die Reihenfolge ist alphabetisch und soll nichts implizieren :-)

Meine Liste enthält ausschließlich mit SQL Server gelieferte, sowie codeplex-Tools, es können aber auch andere angegeben werden. (Punkt „O“)

Mir ist natürlich völlig bewusst, das auch die SQL Server Version und ggf. Edition Einfluss auf die zur Verfügung stehende Auswahl hat, aber ich möchte die Umfrage auch nicht zu komplex gestalten. Das Ziel, einen Eindruck über die Verbreitung der Tracing-Gewohnheiten zu erreichen, wird so sicherlich erreicht werden können :-)

Vielen Dank an dieser Stelle schon einmal für die Beteiligung - ich bin sicher, dass es auch viele andere Community-Mitglieder gern sehen, was andere so für ihre Arbeit einsetzen.

- The order is alphabetical and not supposed to imply anything :-)

My list contains solely tools shipped with SQL Server and from codeplex, but feel free to add others (point “O”)

I am totally aware that also the SQL Server version and possibly edition have an influence on the choices available, but I also do not want to make the survey all too complex. The aim, to gain an impression on the prevalence and practices of tracing-habits will certainly be reached like that, too :-)

Thank you very much for participating – I am sure that many members of the SQL Server Community are also interested to see, what others use for their work.

Andreas

Upcoming Conferences 2013 – die nächsten SQL Server Konferenzen dieses Jahr

Das Jahr 2013 dürfte das bislang am meisten mit Konferenzen durchsetzte Jahr für mich sein. Das liegt nicht zuletzt an den SQLSaturdays, die mittlerweile fest in der SQL Server-Welt etabliert sind, und mit ihrem kostenlosen aber dennoch, durch viele bekannte Experten, hochwertigen Charakter immer mehr Interessenten anziehen.

So ist dann auch die nächste Konferenz diesen Sommer in Deutschland der SQLSaturday #230 am 13.Juli in St. Augustin bei Bonn – der 2. deutsche SQLSaturday!

- Diesmal darf ich wieder einmal mein Spezialgebiet, Sicherheit, aufgreifen. In der Session „SQL Server under Attack – Angriffsszenarien“ gehe ich SQL Server an den Kragen und zeige auch einige unbekanntere Schwachpunkte, aus denen hoffentlich hervorgeht, warum „Best Practices“ das Mindeste sein sollten.

- Letztes Jahr hatte ich in Unterschleißheim bei München auf dem SQLSaturday #170 die Extended Events als Nachfolger von SQL Trace & Profiler vorgestellt („Tracing with SQL Server 2012 Extended Events“ )

Außerdem gibt es dieses Mal sogar eine Precon mit 3 parallelen Workshop-Tracks. Wer sich noch nicht mit dem Nachfolger von SQL Trace/Profiler auseinandergesetzt hat, bekommt in der Session „From SQL Traces to Extended Events. The next big switch.“ einen Überblick über die bisherigen Monitoring Tools wie SQL Trace und Event Notifications, bis hin zu einem halben Tag input in Sachen Extended Events! Mehr dazu hier: http://sqlsaturday230.eventbrite.de


Am 24. September findet in Mainz die BASTA mit dem SQLday statt.

- Dort spreche ich - wer hätte das gedacht -  auch über Sicherheit. Diesmal vor allem für Entwickler: Security Essentials und Best Practices für SQL-Server-Entwickler

 

Im Oktober (15.-18.10.) folgt der Höhepunkt mit dem PASS Summit 2013, dieses Jahr in Charlotte, NC USA, der größten SQL Server Konferenz überhaupt, wo ich die wiederholte Ehre, als einziger deutscher Sprecher auftreten zu dürfen, habe. (einen gewissen Stolz hierüber will ich gar nicht leugnen)

UPDATE: Wie ich gerade erfahren habe, sind meine Kollegen Oliver Engels und Julian Breunung von der PASS RG Rhein/Main nachträglich als Sprecher eingeladen! Superb! - Der alljährliche "Steak-Abend" mit den deutschen Kollegen ist gewiss. :-)

Und zwar mit dem Thema: From Locks to No Locks – Concurrency in SQL Server

- Mit einer kleinen Variante dieses Vortrages war ich dieses Jahr bereits in mehreren deutschen Regionalgruppen auf “Rundtour”.

 

Vorankündigung:
Die nächste Runde der SQL Server Master-Classes mit spannenden ein- bis zweit-tägigen intensiven Trainings & Workshops mit Themen von Extended Events über Indexing bis Hochverfügbarkeit plane ich für November 2013.

Stay tuned unter: www.sarpedonqualitylab.com/SQL_Master-Classes.htm

 

Vom 3. -5. Dezember bin ich dann auch wieder auf dem PASS Camp im Lufthansa Conference Center in Seeheim bei Darmstadt.

Das Besondere an diesem Event, das rein von der deutschen PASS e.V. veranstaltet wird, ist sein „Hands-On“-Konzept. D.h. alle Themen beinhalten praktische Übungen, die von den Sprechern begleitet werden. Im Gegensatz zu den amerikanischen „Workshops“ also kein „lecture-only“. Ein absoluter Tipp für SQL Server Profis und solchen, die tiefer in die Materie eintauchen möchten.

Mit dem
SQLzaterdag #221 in Veenedal/Holland: „Tracing with Extended Events. – Adios Profiler


dem
SQLSaturday #196 in Kopenhagen/Dänemark, ebenfalls mit „Tracing with Extended Events. - Adios Profiler

und den Frankfurter Datenbanktagen, bei denen ich in buchstäblich letzter Minute mit dem Thema Hochverfügbarkeitstechniken in SQL Server 2013 eingesprungen bin (mehr dazu hier: Conferences 2013: Frankfurter Datenbanktage und einige “Oracle-Momente”)
sind das – bislang - 8 Konferenzen + eine PreCon, auf denen ich dieses Jahr als Sprecher aufgetreten sein werde. (!)

– Bislang? - Vielleicht schaffe ich ja noch die SQLRally Nordic, die dieses Jahr vom 4.-6. November in Stockholm stattfindet :-). Mein Eindruck der SQL Rally letztes Jahr - mit dem Thema Sicherheit in SQL Server dabei - war jedenfalls überaus positiv. (Upcoming Conferences 2012: PASS SQLSaturday in Munich, SQLCon in Mainz, PASS SQLRally in Copenhagen, PASS Summit in Seattle, PASS Camp in Darmstadt)

Ich würde mich freuen, einige meiner Leser auf der einen oder anderen Konferenz anzutreffen – einfach „Hallo“ sagen ;-)

CU in St. Augustin, Mainz, Charlotte USA, Seeheim, oder auf einem Regionalgruppentreffen

 

- Ach ja, und nächste Woche, vom 25. bis zum 28. Juni bin ich auf der TechEd Europe in Madrid am Microsoft-Stand anzutreffen.


Andreas

 

Extended Event File Target size vs SQL Server Trace trace file - a comparison

No big science, more out of curiosity this time..

The Extended Events File Target for SQL Server saves data using xml, which as is well known, is a bit “chatty”. A student in my recent SQL Server Master-Class workshop on extended events came up with the question for how much (more) space he would have to account for using Extended Events with a file target. Although this depends greatly on the specific events and possibly actions, selected, I was a bit curious myself and decided for a small test.

Both, the old and deprecated SQL Server Trace and Extended Events can save the data in a file, so it’s easy to compare what difference in size the new format will make.

I set up a SQL Server Trace that is almost identical to an Extended Events Trace. (You will see why “almost”.)

I had to choose a very simple Trace, so the customizable columns of extended events would not make the comparison unequal and ended up with a trace that captures SP:Starting/SP:Completed with the following columns:

You will see why I collect Source/DatabaseID twice later on.
Of course I used a lightweight Server-Trace, although for the purpose of this comparison it would not have mattered.

The SQL Trace definition:

exec sp_trace_setevent@TraceID, 43, 3, @on
exec
sp_trace_setevent@TraceID, 43, 5, @on
exec
sp_trace_setevent@TraceID, 43, 12, @on
exec
sp_trace_setevent@TraceID, 43, 13, @on
exec
sp_trace_setevent@TraceID, 43, 22, @on
exec
sp_trace_setevent@TraceID, 43, 28, @on
exec
sp_trace_setevent@TraceID, 43, 34, @on
exec
sp_trace_setevent@TraceID, 43, 48, @on
exec
sp_trace_setevent@TraceID, 43, 62, @on
exec
sp_trace_setevent@TraceID, 42, 3, @on
exec
sp_trace_setevent@TraceID, 42, 5, @on
exec
sp_trace_setevent@TraceID, 42, 12, @on
exec
sp_trace_setevent@TraceID, 42, 22, @on
exec
sp_trace_setevent@TraceID, 42, 28, @on
exec
sp_trace_setevent@TraceID, 42, 34, @on
exec
sp_trace_setevent@TraceID, 42, 62, @on 

declare @intfilter int
declare
@bigintfilter bigint

 set @intfilter = 7

exec sp_trace_setfilter@TraceID, 62, 0, 0, @intfilter

As you might see the trace includes a filter, which is for a specific database ID.

The Extended Event Trace session looks like that:

CREATE EVENT SESSION [ModulesStartEnd_ToFile]
ON
SERVER
ADD
EVENT sqlserver.module_start(
    WHERE ([source_database_id]=(7))),

ADD
EVENT sqlserver.module_end(
    WHERE ([source_database_id]=(7)))

ADD
TARGET package0.event_file
   
(SET filename=N'R:\Tracing\XE\ModulesStartEnd.xel', max_file_size=(10240))
WITH
(MAX_MEMORY=
4096 KB, EVENT_RETENTION_MODE=NO_EVENT_LOSS,  MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB, MEMORY_PARTITION_MODE=NONE, TRACK_CAUSALITY=OFF, STARTUP_STATE=OFF)

You may know, that Extended Events include certain columns by default, and for module_start/end, this includes offset and offset_end.
 

Those two columns are not available for SP_Staring/SP:Completed in SQL Trace. Since they are both integers, I decided to include another column, DatabaseID, into the SQLTrace. SQL Trace also includes the SPID by default, which cannot be deselected, therefore those two columns should equalize it.
Both traces were started before the workload which ran for a while. At the end, the same number of events have been logged by both technologies in parallel.

SQL Trace event count:

XEvent Trace event count:



100644 + 100644 = 201288, so both captured the exact same events. :-)

So, and now to the final question: what size are the files?

See yourself:

Size in Megabytes:


 
(The numbers in MB are the real size, whereas windows explorer shows the size on disk.)
That’s a difference of 5.32MB or in other words 29.13%.

And this is what one single module_start-event for a function call in XEvents looks like:

<eventname="module_start"package="sqlserver"timestamp="2013-06-08T18:41:48.780Z">
<
dataname="source_database_id"><value>7</value></data>
<
dataname="object_id"><value>103671417</value></data>
<
dataname="line_number"><value>1</value></data>
<
dataname="offset"><value>0</value></data>
<
dataname="offset_end"><value>-1</value></data>
<
dataname="object_type"><value><![CDATA[TF]]></value></data>
<
dataname="object_name"><value><![CDATA[ufnGetContactInformation]]></value></data>
<dataname="statement"><value></value></data>
</
event>

The content is self-explanatory, as xml is supposed to be, and the overhead in size is no surprise at all.

Keep in mind that this post is purely on comparing file sizes, and not performance or features. There are good reasons that SQL Trace & Profiler have been deprecated, and Extended Events in SQL Server 2012 overcomes SQL Trace & Profiler by far, in performance as well as in flexibility/usability.
For a performance overhead comparision check out my recently published benchmark blog post: "Performance overhead of tracing with Extended Event targets vs SQL Trace under CPU Load".

So whenever performance matters, remember to set session options appropriately and if the amount of events is high, do not use your slowest volume for the file target - same as for all other tracing activities anyways.

happy tracing,

Andreas