So far, I have talked about some of the metadata associated with Extended Events. But I have not yet started to dive into the individual components of that metadata.

Today I want to start diving into some of this data a little deeper as we progress through some of the core concepts surrounding Extended Events. At the base of these core concepts is the data that relates to objects. This is not your ordinary objects like we see in a database such as tables, views, procs and so forth. These are objects specific to Extended Events.

Objects

In Extended Events, all of the objects that help to build an extended event session are exposed through the DMV sys.dm_xe_objects. That should not be too much of a surprise after reading my introduction on the topic – here.

Querying that DMV, one will see there are numerous objects. With each release of SQL Server, this list grows larger and larger. With all of these objects, where does one really begin? Well, a good place to start is to figure out the types of objects that are available to use.

SELECT DISTINCT xo.object_type
FROM sys.dm_xe_objects xo;

Unbelievably simple, right? The results of that query will yield results similar to this:

While I would not necessarily think of some of those as objects (e.g. message), it does make sense if thought of as in terms of “components” instead of objects. Each of these components contributes to the whole of the Extended Event System.

Beyond being able to find all of the objects/components that pertain to Extended Events, we can also see that various components have some specialized capabilities. This is shown to us through the capabilities and capabilities_desc columns within the DMV. According to BOL, the capabilities is a bitmap field. Let’s take a look at the various capabilities we can find in the DMV.

SELECT DISTINCT capabilities, capabilities_desc, object_type
FROM sys.dm_xe_objects
WHERE capabilities > 0
ORDER BY object_type, capabilities

The bitmap, when viewed in this order, appears to have different bitmaps for each of the different “components”/objects. But where it seems to lose the whole bitmap feel is around value 512 within the target components. If you do the normal bitmap math, 1536 should be composed of the values for 512 and 1024. Within the target collection, 1024 is the “synchronous” capability, but there is no corresponding 512. It was simply skipped. At least it appears that way.

It would be nice to see the entire bitmap. Even what is documented falls a wee bit short of what is exposed through the DMVs.

If you are curious, here is a bit more showing how some of those capabilities relate to the different objects and types.

SELECT DISTINCT capabilities, capabilities_desc, object_type,type_name
FROM sys.dm_xe_objects
WHERE capabilities > 0
ORDER BY object_type, capabilities

I wanted to look at it this way for one simple reason. Take a look back at the capabilities bitmap results from the previous query. Find the value for sign_extended. Which value did you find first? Was it 1280 or was it 256? I wouldn’t normally expect the same capability to be mapped to two different values – with no further explanation of it.

When I combine the type_name to the output, I see that 1280 is related to string data types while 256 is related to numeric data types.

This is mostly trivial information – at least it is on the part of the types. This is helpful when dealing with the other items such as targets. For instance, the singleton synchronize lets me know that target can only have one existence. If I look a bit further, I will see that this target is the etw target. We will discuss targets another day though. Just understand that there are different capabilities for some of these items.

A good one to point out here is the “private” capability. This means it is reserved for internal use by Extended Events.

Stay tuned for more on Extended Events as this series continues. Next up – Channels.