New Tip at MSSQLTips

Linked server configurations are often overlooked when it comes to environmental baselines. I don’t know of too many people who go out of their way to track such details. And I have often been surprised by vendor software packages that claim to track system changes but do not include linked server information.

One thing about linked servers is that they use a common set of providers. That means you can have a dozen linked servers all relying on one provider. If you change one option on that provider you are changing the structure of all linked servers that use that provider. While I am certain that you can always find one person who says “I don’t care about anyone else, just change the provider so my stuff will run”, ideally you won’t be making any such changes. And, if you do, you will do so only after carefully communicating the change so that others can take notice."I'll just turn this one little knob and no one else will notice..."

But let’s say that a change is made, and someone notices an issue with a query, days after the configuration change. How would you know if their issues with the linked server is the result of the change that was made earlier? Well, first thing you need to do is find out if (and when) a changes was made, right?

Well, that is my tip today: find out the last time your linked server was modified. In the tip I use Policy Based Management as a way to get the job done. The tip shows how you can find out the information for one server, but through the use of a Central Management Server you could also run the policy against all your servers, or as many as desired.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.