Syspolicy Phantom Health Records

SQL Server comes with a default SQL agent job installed (for most installations) to help manage the collection of system health data. I would dare say this job is ignored by most people and few probably even know it exists.

This topic is not new to me. You may recall a previous article I wrote entailing one type of failure and how to resolve that failure. That article can be found here.

I recently ran into a variant of the problem outline in that previous article that requires just a bit of a different approach. The errors turn out to be similar on the surface but really are different upon closer inspection.

Phantom Health Records

If you are unfamiliar with the topic, I recommend reading the previous article. Then after reading that article, maybe brush up a little bit on the SQL Agent. The failures we will be looking at are within the SQL Agent and come from the job called: syspolicy_purge_history.

For this latest bout of failure, I will start basically where I left off in the the last article. The job fails on a server and I have access to other servers of the same SQL version where the job works.

Before diving any further into this problem, let’s look at what the error is:

A job step received an error at line 1 in a PowerShell script.
The corresponding line is ‘set-executionpolicy RemoteSigned -scope process -Force’.
Correct the script and reschedule the job. The error information returned by PowerShell is:
‘Security error. ‘. Process Exit Code -1. The step failed.

Having the error in hand, and knowing that the job works elsewhere, my next logical step (again based on experience from the last article with this job) is to script the job from another server and use it to replace the job on the server where it fails. In principle this is an AWESOME idea.

 

Sadly, that idea was met with initial failure. As it turns out, the error remained exactly the same. This is good and unfortunate at the same time. Good in that I was able to confirm that the job was correctly configured with the following script in the job:

Since the step fails from SQL Server let’s see what else we can do to make it run. Let’s take that code and try it from a powershell ise. So, for giggles, let’s cram that script into powershell and see what blows up!

Now isn’t that a charming result! This result should be somewhat expected since the code I just threw into the ISE is not entirely powershell. If you look closer at the code, you will notice that it is using sqlcmd like conventions to execute a parameterized powershell script. Now, that makes perfect sense, right? So let’s clean it up to look like a standard PoSH script. We need to replace some parameters and then try again.

This will result in the following (resume reading after you scratch your head for a moment):

The key in this failure happens to be in the sqlserver. PoSH thinks we are trying to pass a drive letter when we are just trying to access the SQLServer stuff. Depending on your version of server, SQL Server, and PoSH you may need to do one of a couple different things. For this particular client/issue, this is what I had to try to get the script to work.

If you read the previous article, you may notice this command looks very much like the command that was causing the problems detailed in that previous article. Yes, we have just concluded our 180 return to where we started a few years back. Suffice it to say, this is expected to be a temporary fix until we are able to update the system to PoSH 5 and are able to install the updated sqlserver module.

As is, this script is not quite enough to make the job succeed now. To finish that off, I created a ps1 file to house this script. Then from a new step (defined as a sqlcmd step type) in the syspolicy purge job, I execute that powershell script as follows:

Tada, nuisance job failure alert is resolved and the system is functioning again.

Conclusion

I dare say the quickest resolution to this job is to probably just disable it. I have seen numerous servers with this job disabled entirely for the simple reason that it fails frequently and just creates noise alerts when it fails. Too many fixes abound for this particular job and too few resolve the failures permanently.

I would generally err on the side of fixing the job. Worst case, you learn 1000 ways of what not to do to fix it. 😉

Given this job is tightly related to the system_health black box sessions (sp_server_diagnostics and system_health xe session), I recommend fixing the job. In addition, I also recommend reading the following series about XE and some of those black box recorder sessions – here.

Profiler for Extended Events: Quick Settings

Not long ago, I wrote a rather long article about a new-ish feature within SQL Server Management Studio (SSMS) that impacted Extended Events. You can read that book – here! The XEvents Profiler feature is one of those things that you may or may not use. If you consider using the feature, I do believe it is important that you research it a bit and try to learn the pros and cons first.

With that there is a little more about the feature that the aforementioned book did not cover. In fact, this information has pretty much gone ignored and mostly stays hidden under the covers.

Settings

As of SSMS 17.4 we have been given the ability to control XEvents Profiler just a tiny bit more. For what it is worth, we as Database Professionals love to be able to control our database environment. So this teeny tiny bit of new control ability is potentially a huge win, right?

If you are the controlling type, or maybe just the curious type, you will be pleased to know that under “Options” from the Tools menu in SSMS, Microsoft has tucked some new control options to help you configure XEvents Profiler – to a degree. If you open options, you will see this new node.

If you expand the “XEvent Profiler” node (circled in red), you will discover the “options” node. If you click on this “options” node and do a quick comparison (in SSMS 17.4 and SSMS 17.5) you will also find that you don’t need t expand the “XEvent Profiler” node at all because the options are listed in the right hand pane for both nodes and they are exactly the same. So, choose one or the other and you will end up at the same place.

The options that you currently have are:

  • Stop Session on Viewer Closed
  • Toolbar commands stop and restart

You can either set these options to True or False. I recommend you play with them a bit to discover which you really prefer. That said, I do prefer to have the “Stop Session on Viewer Closed” set to true. There is “profiler” in the name of the feature afterall. And if you have read the “book” I wrote about this feature, you would know that the filtering offered by the default sessions of this feature basically turn on the fire hose effect and can have a negative impact on your server. Are you sure you want a profiler style fire hose running on your production server?

Conclusion

There surely will continue to be more development around this idea of an XE style profiler. More development generally means that the product will mature and get better over time. This article shows how there is more being added to the feature to try and give you better control over the tool. We love control so the addition of these options is actually a good thing. Is it enough to sway me away from using the already established, more mature, and high performing tools that have been there for several generations? Nope! I will continue to use TSQL and the GUI tools available for XE that predated the XEvent Profiler.

Some say this is a way of bridging the gap. In my opinion, that gap was already bridged with the GUI that has been available for several years. Some say that maybe this tool needs to integrate a way to shred XML faster. To that, I say there are methods already available for that such as Powershell, the live data viewer, the Target Data viewer, or even my tools I have provided in the 60 day series.

I would challenge those that are still unfamiliar with the XE GUI (out for nearly 6 years now) to go and read some of my articles or articles by Jonathan Kehayias about the power that is in XE as well as some of the power in the GUI.

An Identity Crisis: Is it Profiler or is it Extended Events?

I have been working on this article for far longer than one might think is necessary for something of this nature. Truth be told, I was reluctant because there are so many people that quickly jumped on the wagon to write about this feature as soon as it was released. With some coercing, here the article is finally!

What is this newfangled feature? Well, that is kind of the problem. The name has already changed in the second release – be it ever so slightly. The feature is XE Profiler or XEvents Profiler and in theory it is supposed to give us something new in management studio.

Fact or Fiction

This Extended Events Profiler is a brand spanking new feature (ok, so the bouncing baby is a few months old now and no longer a newborn). Despite it being new, it seems there are a handful of “facts” already published about it that may or may not be accurate. Due to that, I want to play a little game of fact or fiction with it in this article.

Here is the short list from which we will work:

  1. Sessions (XE Profiler Sessions) are Customizable
  2. The default standard session displays all Extended Events
  3. It works with instances of SQL 2012 or greater only
  4. XE Profiler Adds ability to quickly start/stop sessions
  5. XE Profiler provides a new live view of the Event Session
  6. XE Profiler provides a GUI for Extended Events
  7. Templates were not available in XE until the release of XE Profiler
  8. Similarly, XE Profiler also brought the Profiler templates with it as part of the feature release
  9. A DBA can now do something that was not previously possible to do (quickly start a session)

That is a rather wealthy list of “facts” to be checked for validity if you ask me. Let’s go ahead and start diving into each of these. I will not be following the provided list order. Rather, I will be looking at items that seem appropriate to validate in my own special order. Rest assured tho, we will get through the list.

GUI

I don’t know how this is still a misconception about Extended Events, but it is certainly still out there. Suddenly XE Profiler comes along and people suddenly think that this tool has provided the GUI that everybody has been clamoring about since Extended Events was released in 2008 (yes almost 10 yrs ago).

I am not going to waste much time on this because it is a complete and total piece of fiction. The GUI has been readily and easily available since SQL Server 2012. In addition to that, there was a GUI that could have been installed for the older versions that was created by Jonathan Kehayias.

From SSMS 2014, here is a sample screenshot of the GUI wizard followed by a standard GUI screen.

As you can see, there is clearly a GUI prior to the release of SSMS 17.3.

Result: Fiction

Templates

This is probably the next easiest notion to prove or disprove. I have heard from more than a single source that templates are brand new with SSMS 17.3 (which is when XE Profiler was released).

I don’t really need to go very far or work very hard to prove this notion as a complete work of fiction. I have SSMS 2014, 2016, 17.0, 17.3, and 17.4 readily available to me. I am going to start with SSMS 2014.

If I  once again open the GUI for XEvents in SSMS 2014, I can easily see the available templates in that version.

It looks pretty obvious there that templates were introduced well before SSMS 17.3.

I can also see all of the templates available by browsing out to the file system.

And for good measure, here is one from a 2012 instance.

The same templates (minus possible changes within the template definitions) are available in SSMS 2012, 2014 and 2016. We will see those same templates available in SSMS 17 and above as well – in addition to a few that have been added.

I want to also add here that these are just the default templates. Just like in Profiler, you can create and save your own templates for future use.

Result: Fiction

Profiler Templates

We just saw how there are templates available prior to the release of SSMS 17.3. We can also see that the profiler templates are not available in those prior versions of SSMS. So does that also mean that the profiler templates were only released as a part of SSMS 17.3? We best be careful with that slippery slope of assumption. Let’s take a closer look at SSMS 17.0.

And just so we can confirm that this is indeed a version of SSMS that pre-dates 17.3…

As you can see there, this is RC3 of SSMS 17.0 so it is definitely a version that precedes 17.3

And similarly from a peek inside the folder on disk:

Seems to me we have ample evidence that the profiler templates were made available to the XE GUI well in advance of SSMS 17.3

Result: Fiction

Event Session Live View

One of the most widely used feature of profiler is the ability to watch the data as it streams through the session. According to many, this ability is missing in Extended Events and the XE Profiler feature has brought this ability to the forefront with XE now.

Let’s start by taking a look at an XE Session in SSMS 2014 connected to a 2014 database instance to check the validity of this concern.

All I need to do is browse the nodes in SSMS down to the session I want to view. Right click the session and then select the option to “Watch Live Data”.

After clicking watch live data, the event session live stream will appear on the right and start streaming the data to your SSMS workspace as shown in the following image.

For this session demo, I selected a session that should be readily available to everybody – the system_health default session. That session comes installed and running for you already.

Don’t like the layout of the screen? Well, you can customize the view to your liking and it can be customized differently for each and every different running session on your server.

As it turns out, the ability to watch livestream data has been available to you for Extended Events since 2012 when the GUI was made available. If you are curious about learning more about the GUI and customizing the view, you can read various articles I have written in my 60 day series you can find here.

Result: Fiction

That brings us to the halfway point. To recap we are now sitting at a score of Fact 0 and Fiction 4. Let’s see if we can turn the tide in these last 5.

Quick Start a Session

To be quite frank here, this has been a long time argument against using Extended Events. It just isn’t possible to start a session quickly and easily. I have two methods that I have shown in my training sessions concerning that concern. Let’s take a look at the first. I will demonstrate this from SSMS 2014.

The first thing that needs to be done is browse the SSMS tree until a session is found that you want to start. Here is an ancient cheat code – I leave many sessions on the server in the stopped state until I need to use them. Pro-tip: create your XE sessions on all of your servers and leave them stopped until you think you need to use it.

For this example, I have selected my AG_LeaseTimeout sessions which is in the stopped state (denoted by the little red “stop” icon next to the session name).

Then right click the session name and select “Start Session” from the context menu. To help clarify, I have circled the session name in green and the menu item in blue. This an extremely easy method to start a session. Once started, and if you really feel you must watch data stream onto the screen, then you can also follow the steps shown for watching the live stream data in the previous section.

The second method to quick start a session is only a touch more difficult. The steps are just the same as shown in the “template” section. You select a template that matches your desires and give the session a name. Here are some broad strokes shown in SSMS 17.0 (same steps apply for SSMS 2014 minus the ability to select a profiler template):

Right click the “Session” node and selection “New Session” from the context menu.

Select the “Standard” template from the dropdown box. This is a profiler equivalent (and also happens to be one of the two default sessions in “XE Profiler” so makes sense for a good comparison. Note that the window has a warning that the Session name cannot be empty, so let’s give the session a name.

With that warning cleared, we can now move on to the next configuration. Notice the two red arrows in the preceding image. Enabling these two options will start the session immediately and also give you that profiler warm and fuzzy by allowing you to immediately start watching the session without needing to lift another finger.

From here, click the OK button ( I know I normally teach people that they should script it, but in this case we are going for quick and easy). After clicking “ok”, be prepared for something like the following.

After just a few seconds on a busy server, one should expect thousands of events to fire in a very profiler type manner. I want to reiterate here, that this was the same session template that feeds one of the two available sessions in XE Profiler.

Once you have determined that you have enough data, you can easily stop the session by right clicking the session name and then selecting the “Stop Session” menu item.

And that is all. It is very easy to start a session in two different manners without XE Profiler. One of the options even allows you to create the exact same session as XE profiler but without that feature even being made available on the version of SSMS being used. So if you really want that profiler type of session, you can use a template to quickly create it even if your SSMS version pre-dates 17.3 and even if you don’t have the profiler templates by default (remember you can simply add the profiler templates should you choose).

In the end, I have to call this one a piece of fiction as well. The XE Profiler does not add any new ability to quickly start a session that wasn’t already a viable option. That said, the XE Profiler does add a third alternative to start a session – so long as it is one of the two default sessions.

Result: Fiction

SQL 2012 Required

This is one of those areas that I wish were fiction. However, this has actually been a consistent theme ever since the GUI was released for XE. The GUI components only work on 2012 instances and later. Let’s take a look at a connection to a 2014 Server and a 2008R2 Server in the same SSMS window from SSMS 17.0.

We can see here that the standard Extended Events GUI is just not available for the 2008R2 instance. The 2014 instance is denoted with a Green box and arrow to help distinguish between that and the red marks for the 2008R2 instance.

Now, let’s take a look at it with SSMS 17.3. With a similar setup and similar notation, we see the following in SSMS 17.3 when connected to both a 2014 instance and a 2008R2 instance.

Once again, I will admit this is something I really wish were not the case. It would definitely be helpful if the XE GUI were to be made available to SQL Server Instances that are 2008 and 2008R2. Especially given that the tool is an “SSMS feature”. That said, it really behooves everybody to get their SQL Servers updated to current technologies (2008 is nearly 10 years old afterall).

Result: Fact

The default “Standard” session displays all Extended Events

So far, we have been easing ourselves into this XE Profiler very gently. It is time to finally get into the deeper end and actually look at some very specific XE Profiler things. When I first heard this one, I was admittedly flabbergasted. One session displays all extended events? Really? Let’s actually establish some baselines about the default sessions for XE Profiler first.

  1. There are only two default sessions for XE Profiler
  2. The session names are “Standard” and “TSQL”
  3. The default sessions are based on templates (discussed previously)
  4. The template for the “Standard” session is the xe_Profiler_Standard xml template file
  5. The template for the “TSQL” session is xe_Profiler_TSQL

If I peruse the template file located in the directory on disk (C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Templates\sql\xevent) for the standard session, I will be able to see that it contains the following events:

Now, that is not the entire template file. I shorted it to only include the events and none of the other details like session configuration or the actions attached to each event. As you can see, there is a grand total of seven events in this particular session.

If I run the following statement against a SQL Server 2014 instance, I will get a few more events than just seven.

And the results:

And just for the sake of clarity, the results on a 2017 instance:

Obviously the math does not add up. There are multiple things wrong with the notion that a session from XE Profiler will contain all events. First, there is no sense at all in adding every event to a single event session. The second problem is that the session is supposed to mimic a profiler default template session. If it is supposed to mimic a profiler style session, you can only use 180 events max anyway. Profiler only had 180 events and XE is obviously way beyond that with so much more feature support than Profiler could even muster back in its glory days.

In case, you were wondering, here is how you access the XE Profiler. It is not under the Extended Events Node, it is a brand new node.

As you can see, there really are only the two options for XE Profiler and if you recall, both of those options are derived from the templates that were made available in the traditional XE GUI and are very easy to create a quick session via the same templates as these two options.

Whether using the XE Profiler or the previous method to create these sessions, there is just no way that these sessions could contain every event in Extended Events. It’s just a bunch of hot air with no foundation to the claim.

Result: Fiction

XE Profiler adds ability to start/stop session

Let’s start back with the last image from the previous section and then go from there. We need to access what is available to us via the XE Profiler node so we can test this theory. I will start by right clicking one of the sesisons (right clicking on the “XE Profiler object itself will not yield anything very promising fwiw).

As you can see here, we are given some pretty basic options to either “Stop Session” or to “Launch Session”. It also seems very obvious what they want you to do here because the option is bolded – “Launch Session”.

This menu is the same regardless of the session state. What I mean by that is even if you do not have the session created, this menu is the same as if you have the session created and running. None of the options dim and all are clickable on this menu. This holds true for SSMS 17.4 as well. Let’s take a look at a server where none of these “profiler” sessions are running.

 

I want to make it abundantly clear. This is the way it appears after a completely fresh install of SSMS 17.3. None of these sessions have ever run on this particular instance of SQL Server 2017 and this is even a completely fresh install of SQL Server 2017. That said, I have done nothing yet to break it – buahaha.

Knowing that no sessions have ever been “launched” for XE Profiler, it is clear that it is time to go ahead and “launch” a session. In this new feature “launch” is the new equivalent of “start”. Once you launch a session you will get the same net effect as what we saw earlier when I created a session from the profiler template and checked the box to watch live data and the box to start the session. When I click launch, I will see something like the following:

A new XE session was created under the Extended Events node and it is now called “QuickSessionStandard”. Once again, this is created from that profiler template I have mentioned a few times.

And then after a bit, I may want to try and stop the session.

You can see here that I was able to capture some quick data into the live stream view (which was a feature that was already there prior to 17.3). And after clicking the “stop session” menu item, I will see the following.

Note that the “QuickSessionStandard” event session now has a “Stop” icon instead of a “play” icon. So yay – I was able to start and stop a session quickly from XE Profiler. In addition, XE profiler launched a live stream view just like we saw earlier when creating the same session from the template in the XE GUI. Now for a pro-tip – start and stop an XE Session from the old GUI – “right click any event session and select start/stop from the context menu.”

Yes it is that easy. In addition, only the available option for that session will be enabled (e.g. you cannot stop a session that is already stopped – or not running). In fact you can even start/stop from TSQL. If you try to stop a session that is not running in TSQL, you will get a warning message that it is already stopped. Far more intuitive than XE Profiler. You will get no indication that the session is unable to be stopped if it is already stopped. Let’s take a look at the old way.

And after the session is started, I can also quickly stop it.

You can also see from each of those images, that I have the option to watch live data for the session. Another easy access feature from the old XE GUI.

While XE Profiler has added an additional means to be able to start/stop sessions quickly, the fact of the matter is that it is not a new feature brought to the table by XE Profiler. All it did was add a different way of doing it. I will also add that this new method can actually be somewhat confusing as well. You can only determine (visually) if the session is running or stopped by expanding the “Extended Events” node. Stopping a session from the XE Profiler node does not close the livestream viewer so you could easily presume it is still running. The XE Profiler node gives you no insight into the actual state of the session.

And for giggles, this is how easy it is to start or stop a session via TSQL.

If I run the statement to stop the session when it is already stopped, I will get the following:

Msg 25704, Level 16, State 1, Line 9
The event session has already been stopped.

I have previously covered this specific topic (start/stop sessions) in my 60 Day series which can be found here.

Result: Fiction

Customizable XE Profiler Sessions

Let’s take a gander at the previous section where I showed the context menu available in XE Profiler and not the extent of that menu. The profiler iteself does not offer any sort of customization. You have only two default sessions. You cannot change either session within that particular feature.

Since I cannot customize anything for these sessions via the XE Profiler, let’s use the XE GUI that is tried and true. I will effectively perform the following via the XE Session Properties window:

And after I am done, that session will look like the following:

And visually, from the GUI, it will look like this:

You can see that the aforementioned events are definitely gone from this session. From here, I can absolutely start that session from the XE GUI and it will run just fine. I can hit “watch live data” from the context menu and it will open up the previous view of the live data that was used (so the exact same configuration of that window because the XE GUI has always done that). If I double check my session after it is started, I will be able to confirm that the altered session is indeed still tact just the same as I customized it.

Let’s go ahead and stop that and then “launch” it from the XE Profiler now. After the “launch” I will re-script the session to verify that it is either the same or altered from what I had configured. In this case, since the session was already in place, I will find that the XE Profiler did not alter my session in any way and merely started the session. That is a win for XE Profiler in that it was able to determine that the session did indeed exist. However, I have to use the XE GUI and not XE Profiler in order to get a decent config on those default sessions.

Result: Fiction

Bonus time

XE Profiler only has SQL Profiler Events

This is actually an interesting statement. While the XE Profiler relies on templates based on SQL Profiler and the events in those templates are events that are available in SQL Profiler, they are not exclusive to SQL Profiler. These events can be used in Extended Events and have been a part of the XE Engine since inception. So, I would call this one fiction as well. I think an obvious litmus test for that is that the events are actually running through an XE Session so they must obviously be XE events as well.

Result: Fiction

Up to this point I have not addressed any changes in the Extended Events Profiler that were made for SSMS 17.4. Here is where it seems we compound a bit of confusion for the masses. Not only do we have this Extended Events tool that we have decided to call “Profiler” which has already had many people asking me about it because the name confused them (is it profiler or is it XE??), but it seems that the identity crisis for this feature is exacerbated slightly with a sudden name change.

Using yet another very clean install of SSMS on a different instance of SQL Server to ensure that none of the XE Profiler components had been used or any of the default sessions created and launched, I have the following:

Yes, the name change is very innocuous but it can lead to some confusion for various parties involved. If a set of step by step instructions says to do something and the learner cannot find that explicit node, they will become confused.

For anybody that has been working with XE for some time, they will know that XE is synonymous with XEvent and will quickly figure it out.

Conclusion

So, in wrapping up this very long article, I want to recap the score of the Fact v. Fiction items. The final tally is Fact 1 and Fiction 9 (9 original list items plus 1 bonus entry). This means that there is a whole lot of stuff going on around out there about this new feature that is just not accurate. While some may be able to derive some small use from the XE Profiler, it really does not add anything that you could not already do with either TSQL or the old XE GUI.

Some say this is a way of bridging the gap. In my opinion, that gap was already bridged with the GUI that has been available for several years. Some say that maybe this tool needs to integrate a way to shred XML faster. To that, I say there are methods already available for that such as Powershell, the live data viewer, the Target Data viewer, or even my tools I have provided in the 60 day series.

I would challenge those that are still unfamiliar with the XE GUI (out for nearly 6 years now) to go and read some of my articles or articles by Jonathan Kehayias about the power that is in XE as well as some of the power in the GUI.

Simplified Session Backups

Comments: No Comments
Published on: October 12, 2015

posh_DBPowerShell exposes scads of information and provides the professional with a formidable tool for the tool-belt. Over the past several articles, I have demonstrated how this tool can be used to uncover useful information and metadata.

The groundwork has been laid to be able to mine information about each of the core components for Extended Events Sessions. These core components are Targets, Events, Actions, and Predicates. Being able to query this metadata and understand what it represents is an essential skill to more effective Extended Event Session management.

Thus far, I have demonstrated how to perform metadata inquiries from both PowerShell and TSQL. I even showed how to map this metadata between script and the GUI screens. As I concluded the metadata discovery via TSQL segment, I demonstrated a very useful script, to generate backup scripts of deployed sessions, using all of the concepts discussed to that point. That script can be found here. In this article, I will share how to do the same thing via PowerShell.

Backstory

Before I go into depth on the script within PowerShell that can be used to backup a deployed session, I want to share a bit of a story.

Many years ago while still in High School, I had a really tough teacher for Calculus. He had a reputation going back to long before I took any of his classes of being a very hard teacher. I enjoyed this teacher quite a bit. My group of friends and I even enjoyed giving him a hard time because it seemed like he could take it as well as dish it out a little.

This teacher had a few philosophies that I didn’t really much care for at the time, but I can sure appreciate now. Truth be told, I gained an appreciation for his teaching philosophies within the first year out of High School. One of his philosophies was to make the High School classes at least on par with what could be expected in College. This made college significantly easier.

Another of his philosophies was to teach core concepts first then to build on those concepts. While teaching the core concepts, he always showed the hard way of doing things first and sometimes an equally hard method as the secondary approach. But there was always an easy way of doing things that would be eventually taught. Sometimes it is essential to a solid foundation to know how to solve a problem the hard way before learning how to do it the easy way.

Correlating that to SQL Server, there are many times that the first approach to do something may be a more difficult approach. As the skills are learned, then maybe an easier solution may present itself, but there is (hopefully there is) a solid foundation there first to help support and enable the learning of an easier method.

Simplified Session Backups

In the aforementioned article, I shared a script that would recreate a deployed session via TSQL. That script was lengthy and required a few tricks to get things to work out just right (e.g. concatenations). Now I will show how to do the same thing in a sickeningly simpler way.

The example that I am about to share requires that SQLPS be loaded and the “demosession” Session be loaded into an object. If a recap of how to do that is needed, I recommend reading this article prior to proceeding.

With the “demosession” Session loaded into an object, I also want to load the name of the session into a parameter to simplify things just a bit.

I can confirm the value of the $sessionname parameter if I choose. In this case, the value does return as “demosession” and is the correct value needed. With that, now I can run the following script to create a backup of my deployed session:

That is the entire script! Just one line! This script could have been even smaller, but I felt it necessary to dump the script out to a SQL file in order to have the script available for future needs – should it be needed. One caveat here is that the directory path must exist or an error will be thrown. To create the directory path, it is as simple as the old DOS commands of old to create that directory.

While the script produced is perfectly viable to recreate a deployed session, it is important to note that the Events listed in this script will be in the order of Package then Event sorted alphabetically. Recall from the prior article on Session backups that this is the default script order used by SSMS as well and is not necessarily the same order that the original Session was created.

How did I arrive at this method to create this script? This goes back to repeating some of the processes I have used throughout these articles on PoSH and Extended Events. Starting with a quick exploration into the $sessionobject object.

This would lead me to seeing the following results:

session_script

Seeing ScriptCreate as an option is a great indicator that I can do something with this Session to quickly recreate the session script. If I run that with the session obj, then I get the next clue.

session_scriptnocommands

I highlighted the interesting clue to this. Even though it says ScriptCreate, it apparently needs to have an additional command in order for it to do anything. With that in mind, a quick Get-Methods on ScriptCreate() will produce insight that there are commands that can be utilized. One of those commands happens to be GetScript(). GetScript seems pretty self-explanatory, so I would settle on that and voila the script can be reproduced.

session_scriptgetscript

There it is. I have shown two methods to create backups of deployed sessions. The first being the more complex solution and then this extremely simple solution. Both are valid means to produce the backup scripts and it now just boils down to a choice as to which to use.

 

This is the latest article in the 60 days of XE series. If you have missed any of the articles, there is a recap for the series. To recap or reread the articles in this series, please visit the table of contents.

Deployed Target Metadata with PoSH

Comments: No Comments
Published on: October 9, 2015

posh_DBHaving just covered the methods to discover the metadata for a deployed session including the details about the session settings, events, actions, and predicates, I am nearly finished with the session metadata. All that remains is to dive into the metadata for Targets.

Through the articles thus far, I have shown some of the nuances in dealing with PowerShell to retrieve this metadata and how it differs a bit from performing the same inquiries via TSQL. PowerShell exposes Extended Events differently than what one would expect due to familiarity with Extended Events through the catalog views and the DMVs I have previously discussed.

Along with the nuances associated with accessing this metadata via PoSH, I have also showed how some of this metadata is different. The dive into the metadata about Targets will continue to reinforce and embrace these differences.

Regrouping

Picking up from where I left off, and following the same pattern as has already been target_metadataestablished, it is time to dive into the metadata for the Predicates and Actions that are tied to an Event deployed with a session using PowerShell. This means that I will need to ensure I have a session established that has the SQLPS module loaded. Then I need to ensure I browse back to the sessions folder.

Just in case, here is the working directory for the sessions out of the default instance.

Also, from this point, I will go ahead and load the “demosession” session into an object again for demonstration purposes throughout the remainder of this article.

With that loaded, I just need to remember to reference the Events object (as was introduced in the prior article).

Targets

While the Actions, Predicates, and Events are all tied tightly together (Actions and Predicates have to be attached to an Event), Targets are somewhat independent. The Target is directly attached to the Session in the same way that an Event would be tied directly to the session. Looking at the Metadata for the Session attached to an object, it will show the Targets object being similar to the Events object. Let’s see that in action:

That script will produce the following:

session_psmetadata

Reverting back to the patterns used so far through this series of posts, I will explore what is available to me for the Targets that may be deployed to the session of interest. The following query would be the first step:

This query will result in the following:

ps_targets

Following the established patterns and results, I can see some very common ground here. The results of this query are strikingly similar to the results seen when querying Actions and Events where I would also see the “name”, package and a description. This is a pretty basic demonstration into viewing the targets tied to a session. To get a better view of the Targets attached to a session, I need to dig a little bit deeper.

This will produce the following useful information:

ps_targetsmethods

From those results, I can see that I would immediately be interested in the TargetFields (recall the similar property from the Events) and the Properties property. The first of these that I want to explore is the Properties property.

Note the trick I am using again to dump the results into a quasi-table format. And the results will look like this:

ps_targeteav

Once again, the results should seem somewhat familiar. These properties underscore one of the nuances being the EAV model with how PoSH accesses the Extended Event properties. With this kind of query, I can see what kind of targets have been deployed to the Session and get a little bit of information as to the type(s) of target(s) they are.

This is all really cool. The real meat of the metadata for Targets is in the “Set” options that have been configured. The “Set” options are the configurations that are exposed via the TargetFields property previously seen. With that said, it is time to dive into these configuration options.

This query returns this rather useful data:

ps_targetsettings

And to make this slightly more useful and more valuable, I need to know which target has which setting. For a more usable query, I can resort back to the table output. Instead of just using the data directly accessible from the previous query, I will use the Parent property to get the name of the Target.

And now I will get something like this:

ps_targetsettingswname

This is good and useful information. Being able to tie the target type to the specific setting is crucial to better understanding how the metadata is interrelated. This is also something pretty easy to do via TSQL as I demonstrated in this article.

In this article I have covered the core concept of Targets. I showed how to access the Target metadata which includes the “Set” operations for each of the Targets. This is the last of the core concepts to discuss the means to access the metadata via PowerShell. I do have one more item I wish to discuss via the means of PowerShell and I will be discussing that in the next article.

Stay tuned as I continue to work through another trick that can be done via PowerShell in the next article. To recap the series, please visit the table of contents.

Deployed Action and Predicate Metadata with PoSH

Comments: No Comments
Published on: October 8, 2015

posh_DBI have recently shown that using PowerShell can be extremely powerful in obtaining insight into how to investigate deployed Extended Event Sessions. Throughout the demos I have used, I hope that it has also shown that PowerShell can be very easy to use.

Querying this metadata through TSQL is easy, but using PowerShell does seem to simplify this just a step more. The simplicity of PowerShell is a different kind of easy over TSQL. For me, the simplicity of PowerShell comes in the quantity of code. That said, I want to reiterate what I said previously – there is a bit of a learning curve with PowerShell. PowerShell exposes Extended Events differently than what one would expect due to familiarity with Extended Events through the catalog views and the DMVs I have previously discussed.

I have demonstrated how to access session information as well as how to access Event metadata. That said, I left the discussion of Actions and Predicates for this article. As I expose this information, the simplicity of PowerShell will continue to be reinforced – along with the patterns that I hope have started to become apparent in the previous articles.

Regrouping

Picking up from where I left off, and following the same pattern as has already been 3d_toolestablished, it is time to dive into the metadata for the Predicates and Actions that are tied to an Event deployed with a session using PowerShell. This means that I will need to ensure I have a session established that has the SQLPS module loaded. Then I need to ensure I browse back to the sessions folder.

Just in case, here is the working directory for the sessions out of the default instance.

Also, from this point, I will go ahead and load the “demosession” session into an object again for demonstration purposes throughout the remainder of this article.

With that loaded, I just need to remember to reference the Events object (as was introduced in the prior article).

Predicates

Looking back at some of the metadata that was revealed for the Events object in the previous article, I have the following:

ps_eventgm

If I query the Events directly, I should be able to see that there is a Predicate returned. Unfortunately, the formatting of the output is not very friendly and much of the information is truncated. Seeing the Predicate listed as another item that can be queried direct is somewhat useful. In addition there is a PredicateExpression property that could be useful.

In this following image, I show both the queries used for each (Predicate and PredicateExpression) as well as the corresponding output.

ps_predicates

Notice how the PredicateExpression is a bit more familiar in the output? With the wonky formatting of the output for the predicate, one could also presume that this output would be the XML type of formatting for a pred_compare object. With a little extra effort, this can be confirmed.

And with better formatting, here are those results:

ps_predcompare

These results would reinforce the prior presumption. And it also helps to reinforce the differences between how the Predicate is represented in PowerShell over the sys.server_event_session_events view where the predicate column is closer in value to the PredicateExpression in PowerShell. Additionally predicate_xml in the the view more closely fits the Predicate property within PowerShell. As long as one can keep these differences in mind, it will make working with PowerShell and Extended Events a tad easier.

Actions

Accessing the metadata for Actions via PowerShell is a little bit more straightforward in that there aren’t multiple objects like with Predicates. Unfortunately, with Actions, it is right back to the EAV data model with the Actions object which can cause a different level of complexity and possibly confusion.

Starting with a very basic query to the Actions:

And the results of that query:

ps_basicActions

In addition to a problem noted with the Events (package name being listed twice), there is an additional problem with the initial output here. The problem with the default output is that the Event name is missing. Granted, this is also a problem with the Predicates examples too. This is one of those areas where extra effort has to be made when using PowerShell to explore Extended Events. Luckily, the data is there. All that is needed is to know how to get to the data.

So how does one figure out the Event for which the Action (or Predicate) was added? I have that in this next example:

This query is simply requesting the Parent (Event) of the Action, and then the Action name to be returned in a table format. Here is what the output should look like:

ps_actiontable

Having the Event name is a critical piece, especially in a more complex Session such as the system_health default session. After-all, an Action (yes it must be repeated because it is a core concept) is only attached to an Event and has to be configured for each individual Event.

Circling back around to the EAV concept. One of the areas within Actions where this is more evident is when trying to look at the properties of the Actions module. Starting with a sample query such as this:

Again, I am instructing the results to be returned in a table format. If I don’t do that, then everything is returned in a single column and it is far more difficult to pick out the needed bits of information. Forcing the results to a table format, I get the following:

ps_actioneav

Looking at these results, I see Name as a value under the Name column and the associated value for it under the Value Column. Then there is a lot of repeating. This means that a little extra work is going to need to be done to parse things a bit further.

In this article I have covered two of the core concepts related to deployed sessions in Extended Events – Actions and Predicates. To be able to effectively use PowerShell, I have also covered a few of the nuances necessary in figuring out where essential metadata is exposed via this tool.

Stay tuned as I continue to work through some of the Target metadata in the next article. To recap the series, please visit the table of contents.

Exposing Deployed Event Metadata with PoSH

Comments: No Comments
Published on: October 7, 2015

posh_DBIn the last article I introduced a power tool that can be used to help manage Extended Events. That tool is PowerShell. In that article, I focused primarily on introducing PowerShell as a power tool to help in discovering the Extended Event Sessions deployed to the server as well as some of the settings that are associated with a session. This is the same as thing as calling these settings the Session metadata introduced here.

Now that some of the basics concerning how to access Extended Events via PowerShell have been covered, it is appropriate to start digging in a little deeper. This deeper dive will continue in the direction of metadata discovery and familiarity with this powerful tool.

More Power

Picking up from where I left off, and following the same pattern as has already been established, I want to now 3d_toolstart diving into the metadata for the events that are tied to a deployed session using PowerShell. This means that I will need to ensure I have a session established that has the SQLPS module loaded. Then I need to ensure I browse back to the sessions folder.

Just in case, here is the working directory for the sessions out of the default instance.

Also, from this point, I will go ahead and load the “demosession” session into an object again for demonstration purposes throughout the remainder of this article.

In the previous article I noted that within the metadata for the session, there is a listing of some objects that can be further perused, which are related to the session itself. Those objects are Targets and Events (shown in the next image). I want to immediately jump into the Events object and see what needs to be done within PowerShell to access the metadata for the deployed Events.

session_psmetadata

Luckily, as with how things work from TSQL queries into the metadata, there are patterns that can be established within PowerShell as well. In this case, to get to the Events within the Deployed Sessions, I would need to “query” that object by adding it to the “query” that I use to list the contents of the “Sessions” object already declared (the $sessionobj instantiated previously). This is a lot easier to explain via the code.

See the pattern? This is the same sort of pattern that was used when querying the various deployed Session settings in the previous article. With the Session loaded in an object, I can query properties or sub-objects by appending that “object” or “property” at the end of the $sessionobj object I created. Running that last snippet will produce the following output.

ps_eventlist

Immediately visible are a couple of interesting tidbits. Beyond the query returning the list of all of the events in the session, I can see the package names, the predicates and the descriptions of the events. This is similar to the sys.server_event_session_events catalog view excluding the descriptions. Unfortunately, the formatting is a bit awkward so extra measures would be needed in order to get that description to be useful – just the same as would be needed when querying via TSQL.

Additionally, there is a bit of redundancy with this object. There is a listing for the package name for each of the events. Now, take a look at the event names in these results. I cheated a little bit and highlighted the interesting parts. Each event will have the package name as part of the event name within the PowerShell results. Again, just a note because it is one of those things that could cause a bit of grief later when trying to build more complex queries via PowerShell.

Looking a little bit further, if I continue to follow patterns established thus far, I can check the Metadata for  this “object” and learn a little bit more.

And the results:

ps_eventmetadata

This should come as no surprise. Actions are tied to specific events so it makes sense that it is an object accessible via the events object. In addition, I can see how the “SET” operations are tied into the Event. The difference here being that the object is called “EventFields”. This should make sense since this metadata is exposed in TSQL via the sys.server_event_session_fields catalog view.

And if I invoke a Get-Methods on the Events Object as follows:

I will get a clearer picture of the metadata and what I can do with the Events.

ps_eventgm

In addition to the Actions and EventFields objects, I can see the Name and Predicate properties just the same as I would if I were to query the session events through the catalog view – sys.server_event_session_events.

With the connection to the event fields being so much more obvious through PowerShell and thanks to the prior article on the event fields / “SET Operations”, I want to explore this metadata at this point.

The results of this will be:

ps_eventfieldmeta

From these results, I can see that the “customizable” data point “collect_database_name” for this particular event has been enabled.

In this article I have shown how to begin the exploration into the metadata for deployed Session Events. Additionally, I demonstrated how to quickly get to the set operations tied to those events. I have not yet covered the core concepts of Actions and Predicates which were exposed through some of the queries demonstrated in this article. Tune in for the next article where I will cover both of those topics in greater detail.

With all of the information that has been revealed through this series, it is easy to have either missed some  of the information or to have sensed a bit of information overload. If a recap is needed for one of these or any other reason, feel free to catch up here.

Extended Event Management Power Tools

Comments: No Comments
Published on: October 6, 2015

So far in this series I have introduced a couple of tools that are suitable for helping with the management of Extended Events. The tools introduced so far are the GUI and TSQL scripts. While the GUI is suitable, using a script really is a far better means of managing Extended Events.

That said, these are not the only tools that could be in the shed for helping in the posh_DBmaintenance and management of Extended Events. One really cool tool that can be added is PowerShell. Isn’t that just amazing?

PowerShell can pack a pretty big punch when dealing with Extended Events. With using PowerShell to manage Extended Events, there could be a bit of a learning curve, and it may not be the right tool all the time. I will cover some uses of PowerShell with XEvents over the next handful of articles.

Management Tools

Since I will be discussing the use of PowerShell to help manage Extended Events, a working knowledge of PowerShell would be somewhat advantageous. If PowerShell is a new endeavor, then I recommend checking out a few tutorials prior to proceeding. Here are a couple of options: Microsoft PowerShell Introduction, Month of Posh by Wayne Seffield, or this Month of SQLPS by Mike Fal (as of publication of this article, this series is ongoing). For my demos, I will be using the Windows PowerShell ISE. Feel free to use whichever tool you feel most comfortable, whether it be an ISE or direct to PowerShell.exe.

After spinning up my ISE, I am going to dive straight into SQLPS.

start_sqlps

The first thing I need to do is to change the security policy so I can load the SQLPS. After loading SQLPS, I then revert the security policy back to what it was prior to the change. Here is that code snippet:

As shown in the previous image, I now have SQLPS loaded. Notice the directory change after the module load, going from C:\Windows\System32> to SQLSERVER:\>. With SQLPS loaded, I can start exploring a little bit.

sqlps_xeventsession

Part of the exploration technique is to figure out what is available at each level. In this case, I use dir to figure out what is available to me as I progress through the structures. After the first dir from the SQLSERVER:\ , I can see the possible paths to follow and that one of them is XEvent. That is the path (for the default instance) that I want to follow, and I did as shown with this particular script.

Now, after I run another dir, I can see the beginnings of a wealth of information. I will get the names of all Extended Event Sessions, if the session is started and when that session was started. This is pretty good news. Seeing the list of sessions, I will pick a session and explore further.

Using the Get-Member method against the object I created into which I attached the session of interest, I can peruse the options available to work with the session.

session_gm

Unlike doing this from within TSQL where views are used to expose the metadata, PoSH takes advantage of Methods and Properties that will permit the perusal of the various components of a session. To explore a little further, I can take advantage of the Metadata property.

session_psmetadata

Because of the way Extended Events is architected, there is some consistency between the way investigating Extended Events via PoSH vs. TSQL. Here, attached as an object to the Session, there are the Events and Targets objects. This also tells me that I can browse from within the session object down through the Events and the Targets.

To investigate the properties, like I did in the article on exploring session metadata, I can do so in PoSH by doing something like this (bear in mind, that these are scriptlets designed to work with prior examples):

And this would show me the following output:

session_psproperties

These properties should be rather familiar. These are the same settings (the ones in grey outline) that are exposed via the sys.server_event_sessions catalog view. The variable here being that the StartTime property is not one of the properties in that view. Rather, this particular information can be handy and is easily accessed via PowerShell. The ID on the other hand, though not a setting that can be configured, is exposed via that view and is the same ID whether seen through the view or through PowerShell (just as are the properties outlined in grey).

There is a lot of information that is exposed through PowerShell for Extended Events. I have only begun to tap into the available information as I have begun to introduce this tool. I have just shown how to expose the various session settings as was done previously via TSQL in the aforementioned article.

This is just another quick tutorial in the series about Extended Events. Feel free to peruse the growing recap – here.

Free SQL Training in Seattle

Categories: News, Professional, SSC
Comments: No Comments
Published on: September 15, 2015

The annual SQL Server Professional migration is about to begin. Many of us will be descending upon the city of Seattle for a week of training and networking at the PASS Summit. The week in Seattle will invariably begin and end on different days for many people. And since many will be coming to Seattle in advance of the first day of the actual Summit, there may be some idle time available.

free training

Well, because of this, SQL Solutions Group decided to provide yet another opportunity for those that may have a bit of free time on their hands. So, on Oct 27th, SSG is offering a day of free training (with a small fee for lunch) provided by four of our Microsoft Certified Masters.

If you are in the market for some extra training, you are invited to attend this day of training. Please register at our EventBrite listing to attend and see the training that we have on tap for you on Oct 27th, 2015.

Here is a brief overview of the training that will be given:

Code Smells for the Consultant

Throughout my career, I’ve seen developers do some pretty crazy things to databases ( I know because I come from a developer background). Come to this session to learn both what I (and SSG) look for and why it’s bad for the database (or your career), and alternatives that can be used. Some of the topics that I will discuss include; how coding mistakes open up the database for SQL Injection attacks, how coding choices can slow down the server, and how design choices keep SQL Server dumb ( if SQL Server was allowed to be smart, it would be faster!). Trust me, your DBA will love you for identifying and fixing these code smells.

A Masters Passport to Extended Events

As is commonly the case, all good things come to an end.  And now is as good a time as any for the use of SQL Trace and Profiler to come to an end.  Let’s face it, Trace was a good tool and had some wonderful uses.  Profiler for that matter was a good tool and was useful at times.

It is time to let those old tools retire gracefully and move into the world of XE.  This workshop will provide you the means to let Profiler and Trace be retired from your tool-set as you discover all that XE has to offer.

This focused session on Extended Events will help prepare you to put this tool to immediate use as you walk back to your daily duties.  This workshop will teach you about Extended Events starting with the basics and moving through to some specific XE sessions that I would use to troubleshoot in a client environment – while doing so with minimal impact.

You will be exposed to advanced troubleshooting techniques as we work through complex issues that are made easier through the use of XE.  Take advantage of this opportunity to dive into the world of Extended Events and learn how you can make best use of this tool in your SQL 2008+ environment.

Practical Powershell for the DBA

Think of all the tools you use in managing your SQL Servers. All those SQL Servers being managed by tools and man that is a lot of clicks. We will show practical scripts and techniques to help you get a handle on all those clicks. Whether you are gathering data or statistics from your SQL Servers or deploying an object to all of them. Configuration items are not excluded from the need for good tools. PowerShell is that tool that will let you get away from all those clicks. Reusable scripts that let you manage all those instances with ease. This session will give you a great start on how to think about admin tasks using PowerShell scripts or modules. Many items are already out there to help you and we will take a good look.

Transaction Isolation Levels, Locking and Deadlocking

Managing concurrency is one of the most challenging aspects of working with any enterprise DBMS. There is much confusion out there about locking, blocking, and deadlocks.

In this demo heavy session we will clear up the confusion by defining what each of these items are and what their causes are. We will then dig into each of SQL Server’s built in isolation levels and explore how they affect concurrency. Understanding concurrency and how isolation levels impact it is one of the most important things you need to know as a SQL Server developer. But understanding when to use each one can be daunting. Whether you are a developer who needs to understand how isolation works and why NOLOCK is not an appropriate hint in most cases, or a seasoned DBA who needs to understand the less commonly used isolation methods, this session is for you. We will look at each level, how it impacts the engine, and examine appropriate (and inappropriate) use cases for each.

 

Learning Extended Events in 60 Days

This post will serve as the landing page for a series I am calling 60 Days of Extended Events. The purpose of these posts will be to help somebody progress through the Extended XEisFutureEvents Concepts and become more proficient at implementing and using them.

The 60 days of XE will be a two month series running from September 1, 2015 through October 30, 2015. The posts will go live only on weekdays. So while it is 60 calendar days, it will end up being somewhere in the neighborhood of 45 articles.

These are the  types of articles designed to take 5 to 15 minutes to learn a concept and move on with the work day. The articles are designed to build on previous concepts.

As the posts go live, I will return and update this page with the article title and link.

XE Table of Contents

  1. Shredding the Actions attached to an Extended Event – 01 September 2015
  2. How to View the Metadata for Deployed Extended Event Sessions – 02 September 2015
  3. How to View the Metadata for Running Extended Event Sessions – 03 September 2015
  4. Some Supporting Objects of Extended Events – 04 September 2015
  5. Packages as they Relate to Extended Events – 07 September 2015
  6. What is an Object in Extended Events? – 08 September 2015
  7. Categorization within Extended Events – 09 September 2015
  8. Introduction to Events within Extended Events – 10 September 2015
  9. The Anatomy of an Event – 11 September 2015
  10. Extended Events and Fixed Schemas – 14 September 2015
  11. Actions in Extended Events – 15 September 2015
  12. Storing/Consuming Event Payloads – 16 September 2015
  13. Data Types for your Event Payloads – 17 September 2015
  14. Custom Data / Maps / Lookup Tables for your Event Payloads – 18 September 2015
  15. Predicates and Event Data – 21 September 2015
  16. Comparison Predicates – 22 September 2015
  17. Predicate Order is Critical – 23 September 2015
  18. Putting it all together into a Session – 24 September 2015
  19. Extended Events GUI – 25 September 2015
  20. Deployed Session Settings – Metadata – 28 September 2015
  21. Deployed Session Metadata for Events – 29 September 2015
  22. Deployed Session Metadata for Actions – 30 September 2015
  23. Deployed Session Metadata for Targets – 01 October 2015
  24. Set Operations and Metadata – 02 October 2015
  25. Backup Deployed Sessions – 05 October 2015
  26. Extended Event Management Power Tools – 06 October 2015
  27. XEvent Metadata via PoSH – 07 October 2015
  28. Action and Predicate Metadata with PowerShell – 08 October 2015
  29. Target Metadata with PowerShell – 09 October 2015
  30. Simplified Session Backups – 12 October 2015
  31. Intro to Reading Event_file Data – 13 October 2015
  32. Dynamically Read event_file Data – 14 October 2015
  33. Better Practices for Reading Event_file Targets   – 15 October 2015
  34. Jumping into the ring_buffer – 16 October 2015
  35. Know before you Go – Target Settings – 19 October 2015
  36. Matching Events into Pairs – 20 October 2015
  37. Parsing Matched Events – 21 October 2015
  38. Using and Reading the Histogram – 22 October 2015
  39. Bean Counting and Events – 23 October 2015
  40. Seeing Short-Circuiting at Work – 26 October 2015
  41. Intro to Internals Via XEvents – 27 October 2015
  42. Azure SQL DB and XE – 28 October 2015
  43. Default Sessions – 29 October 2015
  44. Tricks and Treats with XE – 30 October 2015 (Happy Halloween)

At the end of this two month series, there is still just too much to cover. Since I have plenty more in my queue, I have decided to extend the series into overtime. I have no guarantees on how many more posts I will add to the series from here, but I will continue to add more into the series until the queue is depleted.

  1. Log Files from Different Sources – 30 December 2015
  2. Customize The XEvent Log Display – 31 December 2015
  3. Filtering Logged Data – 01 January 2016
  4. Hidden GUI Gems – 02 January 2016
  5. A Day in the Stream – 04 January 2016
  6. Waiting, is it a Bad Thing? – 04 January 2016
  7. Alter Event Session – 07 January 2016
  8. Extended Event Help Queries – 19 July 2016
  9. Query to Find the Right Event – 21 July 2016
  10. Better Method to Parse Session XML Data – 01 August 2016
  11. Using XEvents to Audit Queries – 08 August 2016
  12. Finding the Right Path – 24 August 2016
  13. Deprecated Features via XEvents – 30 August 2016
  14. Index Maintenance Operations – 20 December 2017
  15. Feature: XE Profiler – 22 December 2017
  16. XE Permissions – 25 December 2017
  17. XE System Messages – 27 December 2017
  18. Correlate Trace and XE Events – 28 December 2017
  19. An Introduction to Templates – 30 December 2017
  20. Enterprise Thinking with Default Sessions – 9 September 2015
  21. Correlate SQL Trace and Actions – 1 January 2018
  22. Dynamics AX Event Session – 2 January 2018
  23. Sharepoint Diagnostics and XE – 3 January 2018
  24. Checking the Health of your CLR – 16 January 2018
  25. Profiler for Extended Events: Quick Settings – 5 March 2018
  26. Extended Events File Initialization Failure – 9 March 2018
  27. Monitor Database Offline Events – 15 November 2018
  28. How to Translate Event Duration – 20 November 2018
  29. Azure Data Studio and XEvents – 21 November 2018
  30. Ghost Cleanup in SQL – 28 October 2014
  31. Audit Database File Size Changes (v1) – 26 November 2014
  32. Database File Size Changes – 27 November 2018
  33. Where did the Database Go? – 7 April 2015
  34. Track Trace Flag Changes – 6 December 2018
  35. Missing Backup Files (a story) – 10 December 2018
  36. Using XE to Solve a Synonym Issue – 12 April 2016
  37. Quick and Easy XE for Azure DB – 24 December 2018
  38. How to: XEvents as Profiler – 25 December 2018
  39. Upgrading From SQL Server Profiler – 26 December 2018
  40. How to: File Target use in Extended Events – 27 December 2018
  41. SQL Servers Black Box Recorder – Def Trace – 28 December 2018
  42. SQL Servers Black Box Recorder – system_health – 29 December 2018
  43. SQLs Black Box Recorder – sp_server_diagnostics – 30 December 2018
  44. Finding Installed Event Sessions – 31 December 2018
  45. Finding Application Session Settings – 1 January 2019
  46. Checking Your Memory with XE – 2 January 2019
  47. Event Tracing for Windows Target – 3 January 2019
  48. Automatic Tuning Monitoring and Diagnostics – 4 January 2019
  49. Short Circuiting Your Session – 5 January 2019
  50. Audit SQL Agent Jobs – 17 January 2019
  51. Execution Plans in Extended Events – 17 June 2015
  52. XEvents and the Data Collector – 21 December 2012
  53. Retention of XE Session Data in a Table – 3 Jan 2014
  54. Reading Extended Event File Session Data – 21 June 2015
  55. Trapping Online Index Operations – 29 Jan 2015
  56. Audit who Dropped the Database – 7 April 2015
  57. Extended Events and Data Types – 14 April 2015
  58. Energy Savings and Extended Events – 10 June 2015
  59. Database Drops in SQL 2012 – 1 July 2015
  60. New Extended Events for 2016 – 6 July 2015
  61. Database Settings Changes – 8 July 2015
  62. Extended Events Removed from 2016 – 22 July 2015
  63. Shredding XML in XEvents – 26 August 2015
  64. An Experiment with Deadlocks – 25 March 2019
  65. Database Recovery Monitoring with XE – 10 April 2019
  66. Event Log File Paths – 20 May 2019
  67. Mass Backup All Sessions – 22 May 2019
  68. Implicit Conversion Insights with XE – 05 June 2019
  69. Top 5 Methods to Easily Open Event Log Files – 07 June 2019
  70. Get the Source of PREEMPTIVE_OS_PIPEOPS Waits – 13 June 2019
  71. Audit DB File Sizes (Reboot) – 25 June 2019
  72. Database In Use – 3 July 2019
  73. Event Files on Linux – 9 July 2019
  74. Server 2008 – Audit Logons – 17 July 2019
  75. TBA
  76. TBA

Some rather advanced uses and topic concerning Extended Invents. These are a little more time consuming.

  1. TDE – TBA
  2. Encryption – TBA
  3. TLS – TBA
  4. NUMA / Schedulers – TBA
  5. TBA – TBA
«page 2 of 4»

Calendar
September 2019
M T W T F S S
« Jul    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Welcome , today is Monday, September 16, 2019