Knowing how to access the deployed session metadata and the event metadata attached to that session, I will now begin the dive into how to find the same relevant data for any deployed session action metadata.
There is a wonderful amount of metadata available to be perused in Extended Events. Part of the trick is to know where and how to find it. In this article, learn how to explore the deployed session Event Metadata.
Deployed Session Settings are stored within the system databases and then exposed via system catalog views. These settings help define a session. This article shows how to access those settings and gives an introduction into what these settings mean.
The Extended Events GUI provides a visual access to the Extended Events engine that can help to better understand the XEvents Engine and how a Session is built.
With the core concepts in place as a good foundation to Extended Events, we start pushing these things together to help with assembling a session in Extended Events.
It is well known that there is a wealth of information within Extended Events. One can tap plenty of information about performance issues, errors, or general interest type stuff by setting up an XEvent Session and trapping some (hopefully) useful information.
I want to drive home the importance of the predicate order when dealing with Extended Events. This is an important topic because it can be very helpful in maintaining a reasonably performing event monitoring system.
Predicates are a significant component within the Extended Events Engine. This article discusses one of the pieces of the puzzle of predicates – comparison operators – also known as pred_compare.
A predicate is a filtering mechanism used in SQL Server to target specific data when either querying or updating rows.
Maps are like a way of overloading the data type to expose more meaningful values that relate to the payload data in question. The standard data types can also be called scalar types with a single value (instead of a table lookup).