Validating your server setup is an integral component of your duties as a SQL Server DBA. When performing those validations, it is possible to run into an intriguing difference in reported port values.
The trick here is to find a way to search thousands of files quickly and filter easily the bad from the good. Sounds like an opportunity for an automation or script.
Migrating Extended Event Sessions from one server to another should be a simple task. So simple, one would think there was no need to give it a second thought, right?
How does one consistently find the correct path to the Extended Event Log file (XEL file)? This article shows a thorough method to capture that information for all sessions on the server.
Do you know that your Server logs 300 million deprecation events a week? Do you know if code needs to be updated or how to find deprecated uses in SQL Server?
Within the world of SQL Server there are a few things one can be certain of – things will change. This is true of the features in SQL Server. Additionally, Extended Events is constantly evolving which underscores this constant change.
What is this gaping hole in the coverage of Extended Events? To be honest, it is not a very complicated topic or very difficult gap to fill. It’s just something that has been overlooked. The gap boils down to this: how does one consistently find the correct path to the Extended Event Log file (XEL file)?
Parsing XML is the epitome of salt in a wound for a DBA. Parsing the XML from Extended Events need not be so painful. Read further to discover how to remove the pain from the task of XML parsing.
Are you rolling the dice with your love/hate relationship with XML? Tune in to see how you can ease your XML frustration along with increasing your free time to do more important things.
One of the biggest pains with Extended Events is the thing we love to hate – XML. XML is so foreign to many DBAs. It’s not relational and often brings nightmares of parsing and performance issues.