Größe der Extended Event Zieldatei vs. SQL Server Trace Tracedatei - ein Vergleich

Größe der Extended Event Zieldatei vs. SQL Server Trace Tracedatei – ein Vergleich

Keine große Wissenschaft, diesmal mehr aus Neugier…

Die Extended Events Zieldatei für SQL Server speichert Daten mit xml, was, wie gut bekannt ist, ein bisschen „geschwätzig“ ist. Ein Student in meinem letzten SQL Server Master-Class-Workshop zu Extended Events kam zu mir mit der Frage, für wieviel (mehr) Platz er aufzukommen hätte, wenn er Extended Events mit einer Zieldatei verwendet. Obwohl das stark von den bestimmten Events und möglichen Aktionen abhängt, die gewählt werden, war ich selbst ein wenig neugierig und entschied mich zu einem kleinen Test.

Die alten und veralteten SQL Server Trace und Extended Events können beide die Daten in einer Datei speichern, also ist es einfach zu vergleichen, welchen Größenunterschied das neue Format machen wird.

Ich habe eine SQL Server Trace eingerichtet, die fast identisch mit einer Extended Events Trace ist. (Ihr werdet noch sehen, warum nur „fast“.)

Ich musste eine sehr einfache Trace wählen, damit die einstellbaren Spalten der Extended Events den Vergleich nicht uneinheitlich machen würde, und kam zu einer Trace, die SP:Starting/SP:Completed mit den folgenden Spalten festhält:

Ihr werdet später noch sehen, warum ich Source/DatabaseID zweimal sammle. Natürlich verwendete ich eine leichte Server-Trace, auch wenn es zum Zwecke dieses Vergleichs unerheblich gewesen wäre.

Die SQL Trace Definition:

Wie ihr vielleicht sehen könnt, enthält die Trace einen Filter, der für eine bestimmte Datenbank-ID ist.

Die Extended Event Trace-Session sieht so aus:

Ihr wisst vielleicht, dass Extended Events standardmäßig bestimmte Spalten enthalten, und für module_start/end enthält dieser offset und offset_end.

Diese zwei Spalten sind für SP_Staring/SP:Completed in SQL Trace nicht verfügbar. Da sie beide Integern sind, entschied ich mich, eine weitere Spalte, DatabaseID, in die SQL Trace einzufügen. SQL Trace enthält auch standardmäßig SPID, was nicht abgewählt werden kann, daher müssten diese beiden Spalten das ausgleichen. Beide Traces werden vor dem Workload gestartet, der schon eine Weile lief. Am Ende wurde die gleiche Anzahl von Events parallel von beiden Technologien geloggt.

SQL Trace Event Count:

XEvent Trace event count:

100644 + 100644 = 201288, so both captured the exact same events. 🙂

Also, und nun zur Schlussfrage: welche Größe haben die Dateien?

Seht selbst:

Größe in Megabytes:

(Die Zahlen in MB sind die echte Größe, während Windows Explorer die Größe auf der Festplatte anzeigt.)
Das ist ein Unterschied von 5.32 MB bzw. 29.13%.

Und so sieht ein einzelnes module_start-Event für einen Funktionsaufruf in XEvents aus:

Der Inhalt ist selbsterklärend, wie xml ja auch sein soll, und der Overhead in der Größe ist überhaupt keine Überraschung.

Denkt daran, dass dieser Artikel nur zum Vergleich von Dateigrößen dient, und nicht von Performance oder Features. Es gibt gute Gründe dafür, dass SQL Trace & Profiler veraltet sind, und Extended Events im SQL Server 2012 SQL Trace & Profiler bei weitem überholt, sowohl in Sachen Performance als auch Flexibilität/Verwendbarkeit. Für einen Vergleich von Performance Overhead seht euch meinen kürzlich veröffentlichten Benchmark-Blog-Eintrag an: „Leistungseinbußen beim Tracing, Extended Event Ziele gegen SQL Trace unter CPU Last“.

Also, wann immer Performance wichtig ist, denkt daran, Session-Optionen entsprechend einzustellen und, wenn die Anzahl von Events hoch ist, verwendet nicht euren langsamsten Datenträger für die Zieldatei – genau wie auch für alle anderen Tracing-Aktivitäten.