Day 10 – Retention of XE Session Data in a Table

This is the tenth installment in the 12 day series for SQL tidbits during this holiday season.

Previous articles in this mini-series on quick tidbits:

  1. SQL Sat LV announcement
  2. Burning Time
  3. Reviewing Peers
  4. Broken Broker
  5. Peer Identity
  6. Lost in Space
  7. Command ‘n Conquer
  8. Ring in The New
  9. Queries Going Boom

food-storage

 

Gathering event information is a pretty good thing.  It can do wonders for helping to troubleshoot.  What do you do if you need or want to be able to review the captured information in 3 months or maybe 12 months from now?

Retaining the session data for later consumption is often a pretty essential piece of the puzzle.  There is more than one way to accomplish that goal.  I am going to share one method that may be more like a sledgehammer for some.  It does require that Management Data Warehouse be enabled prior to implementing.

When using MDW to gather and retain the session data, you create a data collector pertinent to the data being collected and retained.  In the following example, I have a data collector that is created to gather deadlock information from the system health session.  In this particular case, I query the XML in the ring buffer to get the data that I want.  Then I tell the collector to gather that info every 15 minutes.  The collection interval is one of those things that needs to be adjusted for each environment.  If you collect the info too often, you could end up with a duplication of data.  Too seldom and you could miss some event data.  It is important to understand the environment and adjust accordingly.

Here is that example.

[codesyntax lang=”tsql”]

[/codesyntax]

Looking this over, there is quite a bit going on.  The keys are the following paramaters: @parameters and @interval.  The @parameters parameter stores the XML query to be used when querying the ring buffer (in this case).  It is important to note that the XML query in this case needs to ensure that the values node is capped to a max of varchar(4000) like shown in the following.

[codesyntax lang=”tsql”]

[/codesyntax]

With this data collector, I have trapped information and stored it for several months so I can compare notes at a later date.

page 1 of 1








Calendar
January 2014
M T W T F S S
« Dec   Feb »
 12345
6789101112
13141516171819
20212223242526
2728293031  
Content
SQLHelp

SQLHelp

  • @AngryPets: @SQLYard #sqlhelp Nope - they just need to be sized to handle the indexes on them. I'd check file stalls vs all files to see if helping/etc.
  • @SQLPrincess: #sqlhelp Any ideas on how to reverse engineer a data flow diagram from queries to show the data transformations?
  • @SQLYard: @AngryPets Thnks so the 3 filegroups different sizes are normal then? I was thinking they needed to be aligned in size. #sqlhelp
  • @AMtwo: @SqlRyan If you want to use source control with your report designer, use Visual Studio + SSDT. #sqlhelp
  • @AngryPets: @SQLYard #sqlhelp [2/2] storage, they aren't as helpful as they could be in 'spin disk' days. But still have benefits. Can be over-used.
  • @AngryPets: @SQLYard #sqlhelp Index filegroups are/can-be a best practice - depending upon data, load, and IO subsystem. With more modern ... [1/2]
  • @SQLYard: Index Filegoups? I took over a server that has 3 index filegrps. 1 grp is Lrge seems other 2 rnt being used.whts best pract on this #sqlhelp
  • @SqlRyan: Report Builder 3.0 (for SSRS 2016) doesn't seem to support source control. Is there a connect item or request I can vote for? #sqlhelp
  • @k_t_schmidt: @AdamMachanic awesome! Have a great day! :) #sqlhelp
  • @AdamMachanic: @k_t_schmidt it's not CLR "causing" it but rather the unload msg is in regard to CLR AppDomain. Are you running any DBCC commands? #sqlhelp

Welcome , today is Friday, September 30, 2016