== Messung der TempDB Contention mittels Extended Events ==
=== Berechnung der einzelnen Pagearten ===
Page arten
* PFS : Page Free Space/Verwaltung der freien Pages
* GAM : Global Allocation Map
* SGAM : Shared Global Allocation Map
PageID's
* PageID 1 : PFS
* PageID 2 : GAM
* PageID 3 : SGAM
* PageID / 8088 : PFS
* PageID / 511232 : GAM
* (PageID-1) / 511232 : SGAM
D.h. auf jede weitere GAM Page kommt genau eine SGAM Page
=== Magische Nummer Mode ===
Im Skript taucht die Nummer "mode=2 OR mode=3" auf. Wir wollen mit dem Skript nur die speziellen Arten "UP" und "SH" erfassen. Bis jetzt habe ich noch keinen Server gefunden, wo die beiden Arten nicht 2 oder 3 entsprechen. Mit folgendem T-SQL Skript können die Werte kontrolliert werden:
<source lang="tsql">
SELECT map_key, map_value FROM sys.dm_xe_map_values
WHERE name = N'latch_mode' AND map_value IN (N'UP', N'SH');
</source>
=== Anlegen des Extended Events für das Überwachen der TempDB Contention ===
Desweiteren sollte der Pfad für das *.xel File noch gesetzt werden.
Uns interessieren auch nur die Fälle, wo ein Latch warten musste, weil die entsprechende Page durch einen anderen Latch geblockt wurde, daher "duration>0".
Der Wert "database_id=2" begrenzt den Event auf die TempDB, da diese normalerweise die ID 2 erhält.
<source lang="tsql">
WITH (STARTUP_STATE=ON);
</source>
=== Warum so kompliziert? ===
Der Extended Event könnte auch einfach die Contention auf alle Pages messen. Das Ergebnis kann auch für die Optimierung der TempDB verwendet werden.
Das Ergebnis wäre aber verfälscht. Z.B. bei globalen Tabellen in der tempdb, die durch mehrere Transaktionen angesprochen werden, können "Waits" auftreten, die sich nicht durch eine tempdb Optimierung verbessern lassen.
