Since I started playing with Extended Events, it has been my favorite toy for performance troubleshooting. It was introduced in SQL Server 2008, and it provides a very rich method of collecting diagnostic data from SQL Server. You can get in-depth detailed information using extend event for troubleshooting which was never possible with SQL Trace.

Extended Events was introduced to replace the SQL Trace. In SQL Server 2012, SQL Trace was deprecated as a feature. It means the will be removed at some future release of SQL Server.

You can read the white paper written by Jonathan Kehayias here: Using SQL Server 2008 Extended Events.

What are Extended Events?

It’s an advanced event collection infrastructure. It provides a very handy tool for event collection and allows you to do all sorts of performance tuning and analysis that were not possible with SQL Trace or any other tools.

It’s a lightweight way to collects data from a system perspective on spinlocks, severe processing conditions, non-yielding tasks, page faults, CPU usage, IO, memory broker, out of memory, scheduler monitor, buffer pool, capture stored procedures that exceed the previous execution’s max duration, monitor which SQL command execution is raising or causing a user defined exception, deadlocks, locking, blocking, figuring out time-out prone queries, allows to capture the events without having that event continue to fire inside of the engine, Capturing session-level wait statistics, and the list goes on & on…….

Extended Event can be savior of DBA in troubleshooting SQL Server operational and performance issues. In the comings tips, I will be blogging how you can play with SQL Server Extended Events.

Thanks!

The post Introduction to Extended Events appeared first on .