Auto-generated statistics names can seem like they are entirely random, but there is a method to the madness. With a little effort and a bit of TSQL trickery, we can decode those names and reveal what the names really mean.
When looking for an easy method to audit Index changes, one of the first technologies to try really should be Extended Events (xevents).
This article shows a method to audit for index changes. The weak link in a solution such as this really boils down to the requirement that the solution needs to be in place before the index change occurs.
This article shows a quick script to help determine indexes that were created recently. This script will help you out of rough spot and help reduce the chance of rework.
A quick way to have your day turned upside down and rip your gut out with nerves and anxiety is to come in one day to find that users are panicked, applications are not working and the HelpDesk team is curled up in the fetal position in the corner. Why? The sky is falling and everybody thinks the database has blown up. You appear to have a corrupt database and nasty IO errors.
Considering this “feature” for everything that is SQL Server related, does this mean that all Extended Events related messages are accessible in sys.messages?
Some view the permissions for Extended Events as a limitation. I see the required permissions as an appropriate set and recommend all to work with XE and permissions to provide higher efficiency to their environment.
If an application vendor has something built into their code to perform index maintenance, unbeknownst to you, that is a near-worst case scenario.
A linked server is a fabulous feature in SQL Server to help accomplish various data tasks between local and remote servers. There is a time and a place for the use of linked servers.
When you need to figure out how indexes are contributing to the overall size of a table within a database, this script will help you!