Category: "Extended Events"

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

Jun 21st

Posted by Andreas Wolter in Tracing & Monitoring

14 comments

 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

, , , , ,

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

Jun 9th

Posted by Andreas Wolter in Extended Events

3 comments

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

, , ,

Tracing Analysis Services (SSAS) with Extended Events – Yes it works and this is how

Apr 9th

Posted by Andreas Wolter in Extended Events

2 comments

Tracing Analysis Services mit Extended Events – Ja, es geht, und zwar so

or: “Hasta la vista, Profiler”... ;-)

(en)
One of the features new in Analysis Services 2012 is the support of the SQL Server Extended Events Framework.

While there is no GUI support for that, yet, it is however possible to set up a XEvent session via DDL commands - just like it was in the “old days” with SQL Server 2008/ 2008 R2, until 2012 brought the GUI.

Since I have been asked a lot at my sessions on Extended Events on how it is done in Analysis Services, and the Books Online sample code is not really working (“Use SQL Server Extended Events (XEvents) to Monitor Analysis Services
http://msdn.microsoft.com/en-us/library/gg492139.aspx”), I will show a quick example here.

The following code creates a session to collect the deadlocks events from the Analysis Services Instance:

(de)
Eines der in Analysis Services 2012 neuen Features ist die Unterstützung des SQL Server Extended Events Frameworks.

Obwohl dafür noch keine grafische Unterstützung da ist, ist es jedoch möglich eine XEvent Session über DDL Kommandos aufzusetzen - genau wie in den alten Zeiten” mit SQL Server 2008/ 2008 R2, bis 2012 die GUI brachte.

Da ich im Zuge meiner Sessions zu Extended Events häufig gefragt wurde, wie das bei Analysis Services funktioniert, und das Books Online Beispiel nicht wirklich funktioniert (“Use SQL Server Extended Events (XEvents) to Monitor Analysis Services
http://msdn.microsoft.com/en-us/library/gg492139.aspx”), zeige ich hier ein kurzes Beispiel.

Der folgende Code erzeugt eine Session um Deadlock Events von einer Analysis Services Instanz mitzuschneiden:

<Create xmlns="http://schemas.microsoft.com/analysisservices/2003/engine"
mlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2"
xmlns:ddl3="http://schemas.microsoft.com/analysisservices/2003/engine/3"
xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100"
xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200"
xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300">
    <ObjectDefinition>
        <Trace>
            <ID>Sarpedon AS Trace Demo</ID>
            <Name>Sarpedon AS Trace Demo</Name>
            <ddl300_300:XEvent>                <event_session name="SQL_AS_XE" dispatchLatency="10" maxEventSize="4" maxMemory="4" memoryPartitionMode="none">
                    <event package="AS" name="Deadlock" />
                    <target package="Package0" name="event_file">
<parameter name="filename" value="D:\SQLData\SarpedonASDeadlockTrace.xel" />
                    </target>
                </event_session>
            </ddl300_300:XEvent>
        </Trace>
    </ObjectDefinition>
</Create>

As one can see, the definition like session configuration and targets, is quite similar to SQL Server, since it is in fact based on the same architecture.
The package containing the events is "AS", whereas targets come from our well known "Package0". The one familiar with XEvents will know, what this implicates - more maybe in a later post.

Via the internal system view $system.discover_traces, we can see the active traces on the instance: the “FlightRecorder” which is still using the old-style Tracing technology (I wonder when Microsoft will add a new one just like system_health in SQL Server) and my sample session. You will also note, that the XEvent session’s trace file name is not visible here.

Wie man sehen kann, ist die Definition wie Session-Konfiguration und Targets recht ähnlich zu SQL Server, da es tatsächlich auf der selben Architektur basiert.
Das Package welches die Events enthält, ist "AS", wohingegen die Targets aus dem bereits bekannten "Package0" stammen. Wer bereits mit XEvents vertraut ist, wird wissen, was das impliziert - mehr vielleicht in einem späteren Post.

Über die interne Systemsicht $system.discover_traces können wir die aktiven Traces auf der Instanz sehen: der “FlightRecorder”, der noch die alte Tracing Technik verwendet (Ich frage mich, wann Microsoft eine Neue, wie die system_health in SQL Server hinzufügen wird), und meine Beispiel-Sitzung. Man sieht auch, das der Trace Dateiname der XEvent-Session hier nicht sichtbar ist.

 Trace Sessions

To access the collected data one can easily stop and delete the session by name as follows:

Um auf die gesammelten Daten zuzugreifen, kann man die Trace session wie folgt bequem über den Namen beenden und löschen:

 <Delete xmlns="http://schemas.microsoft.com/analysisservices/2003/engine"
xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <Object>
        <TraceID>Sarpedon AS Trace Demo</TraceID>
    </Object>
</Delete>

The collected data can be viewed, aggregated and filtered as normal with the Extended Events Viewer in Management Studio.
Here a sample with query runtimes:

Die gesammelten Daten lassen sich dann wie gewohnt über den Extended Events Viewer in Management Studio ansehen, aggregieren und filtern.
Hier ein Beispiel mit Query-Laufzeiten:

XEvent Viewer

In the detail pane on the bottom you can notice, that I turned on causality tracking here. Hence the activity ID /GUID correlate activity.

Im Detailbereich kann man sehen, das ich hier auch “Kausalitätstracking” eingeschaltet habe. Daher die activity ID/GUI um Aktivitäten zu korrelieren.

So as you see, for a fact, the Analysis Services engine has been extended to be using the Extended Events architecture for better performing and more flexible Tracing.
I do expect some more GUI-support for Managing XEvents in Analysis Services in the next major release.


Have fun, playing around with the sample. :-)

From now on there is no excuse any more, to burden an Analysis Server that is already on its knees with Profiler...

Wie man sehen kann, sind die Analysis Services tatsächlich erweitert worden um die Extended Events Architektur für performanteres und flexibleres Tracing zu verwenden.
Mit dem nächsten Major-Release des SQL Server erwarte ich mehr GUI-Unterstützung  für die Verwaltung von XEvents in Analysis Services.

Viel Spaß beim Herumspielen mit dem Beispiel. :-)

Ab jetzt gibt es keine Entschuldigung mehr, einen Analysis Server, der bereits auf den Knien ist, weiter mit dem Profiler zu belasten...

                      “Hasta la vista, Profiler” ;-)

Hopefully by MCM buddy and friend Reeves Smith will soon write his promised post on Tracing Analysis Services, maybe with a Performance Comparison.
”So, now you have to get going, Reeves!” :-D

Hoffentlich wird mein MCM Kollege und Freund seinen versprochenen Post über XEvent Tracing Analsis Services bald einlösen – vielleicht mit einem Performance-Vergleich.
”So, nun musst Du aber loslegen, Reeves!” :-D

Meanwhile I’d like to refer you to this article from another fellow MCM, Jonathan Kehayas, where you can see the enormous difference in terms of negative performance-impact of tracing via Profiler and SQL Trace vs XEvents:

Bis dahin verweise ich gerne auf diesen Artikel eines andern MCM Kollegen, Jonathan Kehayas, wo man den gewaltigen Unterschied des negativen Performance-Einflusses von Tracing mittels profiler aund SQL Trace gegenüber Extended Events sieht:

 www.sqlperformance.com/2012/10/sql-trace/observer-overhead-trace-extended-events

Update: I conducted an excessive benchmarking on Extended Events and SQL Trace & Profiler myself now. The results ar now public and can be found here:

Update: Ich habe nun selber ein exzessives Benchmarking zu Extended Events und SQL Trace & Profiler durchgeführt. Die Ergebnisse sind hier nun auch öffentlich und können hier gefunden werden:

www.insidesql.org/blogs/andreaswolter/2013/08/performance-overhead-tracing-extended-events-sql-trace-under-cpu-load

 

Andreas

 

Hinweis: es wird noch im 1. HJ 2013 einen zweiten Termin für die Master-Class Seminare zu Extended Events geben (13. und 14. Juni). 

Die nächste Möglichkeit ist am 22.11. bzw. 25.11.2013!

http://www.sarpedonqualitylab.com/SQL_Master-Classes.htm

, , ,

SQL Server Master-Class Seminare – Für Alle, die es genau wissen wollen – Start im Mai mit Extended Events

Mär 20th

Eingetragen von Andreas Wolter in Seminare

2 comments

Mein Erster Blog Post hier ist teils in eigener Sache, auf der anderen Seite aber für Euch und alle, die Wiss- und Lernbegierig in Sachen SQL Server sind:

Ich werde häufig darauf angesprochen, ob ich nicht mal ein Buch schreiben möchte, um mein Wissen so weiterzugeben, oder Deep-Dive Seminare anbiete, wie es einige andere Kollegen in den USA tun.

Um ein Buch zu schreiben, habe ich leider nicht die Zeit. Ein komplettes Buch würde mich zu sehr von der Praxis abhalten - und Praxis ist das A und O - zumal es ständig neue Dinge zu lernen gibt.

In Seminaren und Vorträgen hingegen, hat man einen kurzen Zyklus, und sieht den Erfolg direkt. Abgesehen davon, das ich mein Wissen gerne weitergebe, macht die Interaktion einfach Spaß.

Ich habe mir überlegt, und mich auch unter Kollegen umgehört, was an anderen Angeboten, die ich selber oder andere kennengelernt haben, störte, und kam zu folgenden Kern-Punkten:

  1. Reine Präsentation mit zwar Deep-Dive Inhalten, aber kaum eine Chance, diese mit Übungen direkt vor Ort zu festigen (sehr typisch für die USA, ob PreCon-“Workshops” oder Seminare, das ist eher immer Vortragsstil und Demos, aber keine echten “Hands-On”) – und nach der Schulungswoche hat man oft keine Zeit mehr dafür.
  2. Viele Themenkomplexe innerhalb einer oder mehrer Wochen, die man gar nicht alle mehr benötigt, aber Bestandteil der 5 Tage sind. – Und diese 5 Tage sind dann auch komplett blockiert.
  3. Weite und damit teure Anreise.

Und nun ist es soweit: ab diesem Sommer biete ich eine eigene Deep-Dive Trainingsreihe, “SQL Server Master-Classes” an.

 SQL Server Master-Classes

Und was ist hier anders?:

  1. Es sind immer Übungen und auch Zeit für diese eingeplant, so dass man das gerade erlernte gleich ausprobieren kann. In den SQL Server Master-Classes, die “Workshop” in der Bezeichnung tragen, beträgt der Praxisanteil ca. 40%.
  2. Server Master-Classes sind jeweils 1 - max. 3-tägige Veranstaltungen, die jeweils einen Themenkomplex abdecken.
    Z.B. 1 Tag “Concurrency” mit allem, was zum Thema Transaktions-Isolation, Locking & Blocking gehört, oder 2 Tage “Indexe, Statistiken und Partitionierung”, denn das Thema ist ein einem Tag nicht zu schaffen. Beides lässt sich aber einzeln buchen, obwohl es insgesamt natürlich zum Thema “Performance” gehört.
  3. “Learn from a Master” - Zum einen sind dies die ersten regulär angebotenen offenen Seminare mit einem Certified Master (MCM + MCT) als Instruktor in und aus Deutschland
    Microsoft-Certified-Master
    - zum anderen kann ich für die in Frankfurt laufenden Seminare einen absoluten Knüllerpreis für Bahnfahrer anbieten: 99,- Euro für Deutschlandweite An- und Abreise. (Details dazu auf der webseite: www.sarpedonqualitylab.com/SQL_Master-Classes.htm)
  4. Nur um Sicherzugehen: der Vergleich mit MOC-Kursen wird gar nicht erst versucht. Hier geht es nicht nur um Best Practices, sondern es soll erlernt werden, was dahinter steckt, um den BESTEN Weg zu ermitteln, und nicht die “allgemeine Best Practice”.
  5. Natürlich wird sich auch ganztägig um das leibliche Wohl gesorgt. Die Seminare finden in einer hochwertigen Location statt, und ein Mittagsmenü sowie Pausensnacks (Kaffee, Tee, Kuchen uä.) und “Getränke-Flat” gehören dazu.

Und nun zu den Inhalten:

Folgende Themenkomplexe sind derzeit vorbereitet:

  • Workshop Tracing mit Extended Events in SQL Server (1 Tag)
  • Workshop Fortgeschrittene Techniken für Tracing mit mit Extended Events in SQL Server (1 Tag)
  • Concurrency - Transaktionen, Isolation Level und Sperren (1 Tag)
  • Indexe, Statistiken und Partitionierung (2 Tage)
  • Optimierung von Prozeduren und Funktionen (1 Tag)
  • Performance und Analysetechniken & -Tools + Workshop (2 Tage)
  • Baselining & Benchmarking (1 Tag)
  • Sicherheitsworkshops (Essentials, Vertiefung für Entwickler, Vertiefung für Administratoren, je 1 Tag)
  • Wiederherstellungsstrategien und Techniken (1 Tag)
  • Workshop Hochverfügbarkeit (2 Tage)
  • Beyond Relational mit SQL Server - Filestream, FileTable, FullTextSearch, Geospatial (1 Tag)
  • Workshop Replikation (1 Tag)

Und los geht es mit XEvents:

  • Workshop Tracing mit Extended Events in SQL Server (1 Tag)
    • Frankfurt am Main, 17.5.2013
  • Workshop Fortgeschrittene Techniken für Tracing mit mit Extended Events in SQL Server (1 Tag)
    • Frankfurt am Main, 18.5.2013

Bis zum 29.3. läuft noch der Super-Early-Bird, und bis zum 22.4. der Early-Bird!
Für den ersten Termin gibt es keine freien Plätze mehr. Daher haben wir einen 2. Termin zum 13. und 14.Juni gepant. Anmeldungen sind ab jetzt möglich. (dafür gibt es auch wieder einen Early-Bird-Tarif)
Mitglieder der PASS Deutschland e.V. erhalten einen Rabatt von 10%

Hier geht es zur aktuellen Liste und Anmeldung: www.sarpedonqualitylab.com/SQL_Master-Classes.htm

happy learning,

Andreas

------------------------------------------------------------------------

Andreas Wolter | Microsoft Certified Master SQL Server

MCT, MCITPDD, MCITPBID, MCITPDA, MCDBA, MCSA, MCTS
Sr Technical Consultant & Architect Datenbanken & BI

Sarpedon Quality Lab

, , ,

Locking & READONLY Filegroups vs READONLY Databases // Sperren & READONLY Dateigruppen vs READONLY Datenbanken

Feb 22nd

Posted by Andreas Wolter in Locking & Blocking

No comments

(en)
The Topic Locking and Read-Only for filegroups and databases is one of the ongoing myths around SQL Server in forums – and at least half of the information unfortunately wrong.
Since I recently fell into the trap myself, I want to write down, how it really is.

To have a definite picture, I made 3 test series under 3 different isolation levels:
  • Read Commited (the default)
  • Read Uncommitted (equal to the often misunderstood “NOLOCK”)
  • Repeatable Read

     

    The Setup:


    Tested under:
    Microsoft SQL Server 2012 - 11.0.2376
    A Test using SQL Server 2008 R2 produced identical results

    The base is a simple table, which has a Clustered Index. Altogether it consists of 36 pages
    (In case you wonder about the name – I had also tested with a single-Page table)

 (de)
Das Thema Sperren im Zusammenhang mit Readonly Filegroups und Datenbanken geistert immer wieder durch die Foren - und mindestens zur Hälfte leider mit Falschinformationen angereichert. Da ich kürzlich selber in die Falle tappte, möchte ich hiermit schwarz auf weiß festhalten, wie es sich wirklich verhält.

Um ein eindeutiges Bild zu erhalten, habe ich Testreihen unter 3 verschiedenen Isolation Levels durchgeführt:

  • Read Commited (also dem Standard)
  • Read Uncommitted (gleichbedeuted mit dem ebenfalls gerne missinterpretierten “NOLOCK”)
  • Repeatable Read

    Das Setup:

    Getestet unter:
    Microsoft SQL Server 2012 - 11.0.2376
    Ein Test unter SQL Server 2008 R2 ergab identische Ergebnisse

    Basis ist eine simple Tabelle, welche mit einem Clustered Index versehen ist. Insgesamt besteht sie aus 36 Pages.
    (Falls ihr Euch über den Namen wundert: ich hatte auch Test mit einer single-Page Tabelle gemacht)

 

Databases

 

Read-Only Filegroup


USELockingDemo_RW
go
exec sp_help'BigTable'

Data_located_on_filegroup
PRIMARY

index_name    index_description
PK__BigTable__3213E83FFF01B718    clustered, unique, primary key located on PRIMARY

USELockingDemo_RO
…

Data_located_on_filegroup
PRIMARY

index_name    index_description
PK__BigTable__3213E83FFF01B718    clustered, unique, primary key located on PRIMARY

Identical structure so far except the database LockingDemo_RW_FG_RO – here the Table resides on filegroup FG_RO Also ein identischer Aufbau, bis auf die Datenbank LockingDemo_RW_FG_RO – hier ist die Tabelle auf der Filegroup FG_RO

USELockingDemo_RW_FG_RO
…

Data_located_on_filegroup
FG_RO

index_name    index_description
PK__BigTable__3213E83FC5587D01    clustered, unique, primary key located on FG_RO

The first/upper query shows the total amount of data, the lower is used as the test query: Die die erste/obere Abfrage zeigt die Gesamtdatenmenge, die untere wird als Testabfrage verwendet:

1)
SELECT * FROM BigTable

(1000 row(s) affected)

Table 'BigTable'. Scan count 1, logical reads 36, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 

2) – The Testquery / die Testabfrage

SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

(101 row(s) affected)

Table 'BigTable'. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 

This is what the test looked like (abbreviated): So sah der Testlauf aus (abgekürzt):

--====================

--  1

--====================

 SET TRANSACTION ISOLATION LEVEL READ COMMITTED

 

USELockingDemo_RW

go

 BEGINTRAN

 SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 COMMITTRAN

 

USELockingDemo_RO

go

 BEGINTRAN

 

SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 

COMMITTRAN

 

USELockingDemo_RW_FG_RO

go

 BEGINTRAN

 SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 COMMITTRAN

 

USEmaster

 --====================

-- 2

--====================

 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

 ...

 --====================

-- 3

--====================

 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

 ...

 

Parallel to that, an extended events session was running (Lock-escalation isn’t happening in this scenario) Parallel dazu lief eine Extended Events session
(Lock-Escalation tritt in diesem Szenario nicht auf)

 CREATE EVENT SESSION [Locking] ON SERVER

ADD EVENT sqlserver.lock_acquired(

    ACTION(package0.event_sequence,sqlserver.database_id,sqlserver.is_system,sqlserver.session_id)

    WHERE ([sqlserver].[database_id]>=(23) AND [sqlserver].[database_id]<=(25)))

ADD TARGET package0.event_file(SET filename=N'D:\SQLData\SQLData1\Locking.xel')

WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)

GO 

 

Results

(Locks with granularity / resource_type = DATABASE left out)

1. Read Committed

Resultate

(Sperren mit Granularität / resource_type = DATABASE ausgelassen)

1. Read Committed

  Locks under Read Committed

2. Read Uncommitted

(for obvious reason I left out the sub-totals :-)

2. Read Uncommitted

(aus offensichtlichem Grund habe ich die Zwischensummen weggelassen :-)

 Locks under Read Uncommitted

3. Repeatable Read

3. Repeatable Read

 Locks under Repeatable Read

A note about Statistics und eXclusive Locks on ReadOnly-Databases:

Yes, one can indeed watch X-Locks on Read-Only databases. And this happens when auto-created stats jump in.
This works only starting with SQL Server 2012. The statistics themselves are stored in Tempdb.
In order to create those, SQL Server generates SCH_S and METADATA locks on several system objects (here: sysallocunits, sysschobjs, sysobjvalues, syssingleobjrefs, sysobjkeycrypts):
Eine Bemerkung zu Statistiken und eXklusive-Sperren auf schreibgeschützten Datenbanken:

Ja, tatsächlich kann man auch auf Read-Only Datenbanken hin und wieder X-Locks beobachten. Und zwar wenn auto-created Statistics einspringen.
Das funktioniert erst seit SQL Server 2012. Dabei werden die Statistiken selber in der Tempdb hinterlegt.
Um sie zu erzeugen, generiert SQL Server SCH_S und METADATA Locks auf diverse Systemobjekte (hier: sysallocunits, sysschobjs, sysobjvalues, syssingleobjrefs, sysobjkeycrypts):

image

This is of course not the most common scenario, but it does happen (especially in AlwaysOn scenarios with read-only secondaries involved) and belongs to a complete picture.

-

Besides that one can see on first sight, that there is no diffference in the Locking behaviour beetween the table on a ReadWrite Filegroup (here Primary) and the table on the ReadOnly filegroup.

Only if the whole database is ReadOnly, SQL Server  saves himself the Page- and Key- locks.
Even there an Intent shared Lock is placed on the table.

Conclusion:

Putting Tables onto a ReadOnly-Filegroup does not save Locks.
But it often does make a lot of sense, to break up databases in this manner.
Just thinking of: less backup, faster restore, NTFS-compression etc.		 Das ist sicherlich nicht das am meisten übliche Szenario, aber es tritt auf (insbesondere in AlwaysOn Szenarien mit read-only Secondaries) und gehört zu einem vollständigen Bild.

-

Abgesehen davon erkennt man auf den ersten Blick, das kein Unterschied im Sperrverhalten zwischen der Tabelle auf einer ReadWrite Filegroup (hier Primary) und der Tabelle auf der ReadOnly Filegroup besteht.

Nur wenn die gesamte Datenbank ReadOnly ist, spart sich SQL Server die Page- und Key- Locks. Selbst dort jedoch wird ein Intent-Share-Lock auf die Tabelle gesetzt.

Fazit:

Tabellen auf eine ReadOnly-Dateigruppe zu verlegen spart keine Sperren.
Aber es macht natürlich trotzdem oft sehr viel Sinn, Datenbanken so aufzuteilen.
Ich denke da nur an: Weniger Backup, schnellere Wiederherstellung, NTFS-Komprimmierung  etc.

Andreas

Sarpedon Quality Lab

, , , ,
1 3