4. WHAT ARE EXTENDED EVENTS?

To clarify what Extended Events are, they are a feature within the SQL Server database engine that enables SQL Server to watch for and then respond to specific database engine events occurring. These events could be as simple as a user logging in or something more technical such as a long-running I/O operation. When a watched for event occurs, the Extended Event session performs an action, which is typically to gather additional information about what has just happened. For example, when a long I/O operation occurs, you might want to record the SQL Server statement to which the event was related. All the information collected is sent to a target where it’s stored. This could be something as simple as a flat file, but Extended Events also provides a few advanced storage options that can process the collected data rather than just store it. Figure 1 provides an illustration of this basic process.

FIGURE 1

4.1 Where the Name Extended Events Comes From

Although the name Extended Events provides a clue as to what it’s about, it is not as prescriptive as something like Resource Governor. The Extended Events feature within SQL Server takes its name partly from a high-performance troubleshooting feature in the Windows operating system called Event Tracing for Windows (ETW), a low-level debugging tool that exposes kernel-level events generated by applications or device drivers. It is normally used by developers during development and troubleshooting. Some SQL Server tuning experts use it to obtain very detailed performance data from Windows. ETW has been around since Windows Server 2000, and it introduced the Windows kernel concepts of controllers, providers, and consumers of event data, terminology that’s still used today.

Rather than get very technical, it is sufficient to know that the Extended Events feature was built on the fundamental design principles of ETW, in terms of both its architectural design and its object-naming conventions. The events it refers to are simply “things that happen” within your system, such as a query being executed, a physical file being read, or a memory request being granted — similar to what you are used to seeing in Profiler, but there are more of them, covering more areas. Fortunately for us, SQL Server hides all this low-level complexity and just exposes objects and commands that we can relate to as database professionals.

4.2 Extended Events Terminology

Hopefully, by now you’re beginning to understand the powerful foundations upon which Extended Events is built upon, and why and how you might use it. If not, don’t worry, as you’ll be looking at some examples demonstrating when and how to use this feature in the next section. Before that, however, this section reviews the terminology that Extended Events uses. Like all SQL Server features, Extended Events has its own names for objects and methods, and this section should serve as a comprehensive glossary for them.

4.2.1 Sessions

An Extended Events session is a user-defined combination of events, actions, filters, and targets, which is stored within the SQL Server instance, although SQL Server also ships with some of its own system sessions as well. Each session can be configured to start either manually on request or automatically when SQL Server itself starts. Once a session is started, it tells the Extended Events engine to begin monitoring for the specified events, and what to do should they happen. You can think of the Extended Events engine as a controller and coordinator within the SQL Server engine for everything related to Extended Events.

You can create a session using either T-SQL commands or, new in SQL Server 2012, the GUI available through SQL Server Management Studio. Using the GUI, you can create, manage, and view sessions and their captured data entirely through SQL Server Management Studio. Figure 2 shows you where in SQL Server Management Studio you can find it and any sessions that may have been configured.

FIGURE 2

In this case, five sessions are currently configured, four of which are running. You can stop and start them, as well as find additional options, by right-clicking on a session, as shown in Figure 3.

FIGURE 3

Of the five sessions shown, note that Logins, PageSplit, and LockDemo are user-defined sessions; the other two are system-defined sessions that SQL Server uses internally to provide both itself and administrators with system information. The session AlwaysOn_health looks for expected and unexpected changes to AlwaysOn Availability Groups so they can be displayed in the AlwaysOn dashboard. The system_health session is very similar to the default trace SQL Server also has, a “black box” critical event recorder that can be used to retrospectively diagnose critical system issues.

Sadly, the SQL Server Management Studio interface for Extended Events appears only when you connect to an instance of SQL Server 2012. Although Extended Events existed in SQL Server 2008, you need to use one of the graphical tools created by SQL Server community members in order to connect to SQL Server 2008 instances and manage the Extended Events sessions, or use the T-SQL commands.