Archive for June 28th, 2012

Monitor High CPU with Extended Events in SQL Server 2012 June 28th, 2012

Vinod Kumar

Extended Events has always been fascinating for me to learn in the previous editions too. But the only drawback of not having an effective UI means that this was tough to configure and more so to use. With SQL Server 2012, this limitation goes out of the door and now we can use some basic UI to work with Extended Events.

In this post, let me take a simple tour of creating a simple Extended Event via SSMS and then we will add appropriate filters to the collection to collect a specific event of some specified value. This is no way exhaustive of what Extended Events can do but surely can be a great starter.

What is Extended Events?

As per BOL, “Extended Events has a highly scalable and highly configurable architecture that allows users to collect as much or as little information as is necessary to troubleshoot or identify a performance problem.” – Read completely on this topic over TechNet.

Step 1: Initializing a session

To get started, Open SQL Server 2012 Management Studio and get to the Management Node. Expand and click on the “Extended Events” node and right click at the Sessions Folder. Select “New Session”.


Step 2: Session Name to start

The next step is to give a “Session Name” in the Text Box. Enter a value of “High_CPU” for example. This screen has multiple other Checkbox which allows you to start this Extended Event session upon SQL Server Startup etc. For this blog, we will not select any of them. Feel free to use these advanced features once you got a hang of Extended Events with SQL Sever 2012.


Step 3: Add an Event and Filter Values

Once the above is complete, now select the “Events” tab from the left-hand side menu. This will bring you the Events Library to select. Remember we want to get the Queries based on some high CPU value.

Under the “Event Library” text box, apply the filter for ShowPlan. This will get you 3 records like below. Select the “query_post_execution_showplan”. This occurs after a SQL statement is executed. This event returns an XML representation of the actual query plan and we will use the CPU values from this event to get badly performing queries. Once you Select use the small “Right Arrow” to move the event to “Selected Events” section. The wizard will look like below.


Step 4: Configure details

Once you reached this step, Click on the “Configure” button on the top right corner. This brings the Event Configuration Options. Select the “Filter (Predicate)” Tab. Apply some filters. For the demo, I am adding two filters on cpu_time and database_name as below. These can be different for you.


Step 5: Configure Storage Options

Now the once the event and filter conditions are configured, we need to next configure where we be collecting these events. For this demonstration, we have used a “event_file” option and are writing to “c:\temp” folder with the options like below.


This is the final step and click “OK” button at the bottom. We are all set now.

Step 6: Start the session now

Right click on the “High_CPU” node and select start session.


Now the configuration is complete and we are all set to start collecting data. Play around with the various options, events and destinations to configure your own collection.


Step 7: Generate a High CPU query

For this blog I am querying a very large table and doing an aggregate to simulate some CPU cycles. Once this is done. Just "double click” the file “c:\temp\High_CPU_x_xxxxx.xel”.

This will Open up the SSMS and you will be able to view the file with some interesting data.


This shows you that I have had a Stored Procedure – “High_CPU1” that is causing some 3313000 ms of CPU time and this qualified for the event capture and hence was collected. You can also use Live trace if you from one of the options of right-click on the session. That will be functioning like a typical Profiler sorts with a filteration of event.

Clicking on the Query Plan also reveals the query that was used inside the Stored Procedure that caused this CPU spike.

There are nice ways to now group, filter etc on Extended Events. But I will write it for a future post.


Want to wrap up saying, with SQL Server 2012 Extended Events are way more powerful than the conventional way of collecting data via Profiler. We will get into some more options and advanced data collection in the future. Do feel free to pass me your comments (if any) for future posts too.

Continue reading...