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.
Conclusion
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.
As new versions of software get released, companies and products also get into this natural transition of upgrading and supporting the latest and greatest. And in the same space, SQL Server is no exception -almost as an predictable cycle, every 3 years we can expect a version of SQL Server getting released. This has been a trend since the SQL Server 2005 version for sure. As part of my job in meeting customers, I have to give recommendations and best practices to move to the latest versions. There are so many nuances to keep in mind as we make a successful upgrade. Let me take a moment to give you some of the suggestions I give to customers. Hope these will be helpful for you too.
Please make sure you are aware of the specific call-outs mentioned in the Upgrade Technical reference mentioned above. During upgrade there can be specific features or settings that might need special attention. I am calling out some of them as I have seen at multiple customer upgrade process.
I was generally exploring for content to explain the nuances of using ColumnStore Index with SQL Server 2012. And interestingly during a conversation with Pinal, he had already written a number of blog posts on the same subject –
TechEd India 2012
