Checkpointing in SQL Server can have an impact on performance. Most of the time, DBAs don’t bother to think about checkpoints or their behavior. This isn’t necessarily a bad thing. It’s just a fact of life.

Much like the DBA, most of the time, checkpoints have no reason to be in the foreground of thought. This just simply means that things are running smoothly and we can occupy ourselves with other tasks.

When odd behaviors start to pop up such as the dreaded checkpoint io storm or the Flushcache (here or here) error, you need to have some tools to help you try and troubleshoot the issue. This article will help you add at least one more tool to your SuperStar DBA Toolbox.

Let’s start with a bit of background on what a checkpoint is.

Checkpoint Primer

A checkpoint is basically the last known good mark (or point) from which SQL Server can start applying changes registered in the transaction log during recovery after an unexpected shutdown or crash.

What is it that the checkpoint does? The checkpoint process is the means by which the dirty pages (modified data pages in memory) are written and persisted to disk. This process also takes the transaction log information and persists that to disk, while also adding a note to the transaction log of what was done.

The post Checkpoint Analysis: Your Exclusive How-To with XEvents appeared first on SQL XEvents.

There is a lot of science and art that is mixed together to help performance tune. Performance tuning is rather enjoyable because the rewards are usually very satisfying. There is nothing like the feeling of making a query go turbo speed.

When I say turbo speed, there is a bit of a tongue in cheek there. However, there is some truth to it. The causes of slow performance vary from query to query but the results of tuning usually all result in significantly faster query performance.

One such example of this happened when I encountered a query with a 118GB memory grant. I had to double check that figure multiple times just to make sure. Clearly there was a complaint that the query was way too slow. Sadly, the client only recognized the pain of the query when trying to migrate to AWS. Prior to the migration, they had oversized bare metal servers with top-shelf hardware that could conceal the worst of performance issues.

Memory – You’ll understand what happiness is

Digging into this particular query, I found a great deal of wrong with how it was written. I won’t digress into all of the bad anti-patterns, suffice it say there were plenty. These anti-patterns helped contribute to the 118GB memory grant. When tuning was sufficient and the query was within acceptable performance timings, the memory grant was

The post Memory – How to Find when Excess is a Bad Thing appeared first on SQL XEvents.

Something that was recently requested of me was a means to help audit these statistics in SQL Server. Why? Well, as it turns out, it could prove very useful in determining who, why, and when statistics might have been changed.

One would think there should be no need to audit the statistics in SQL Server. Alas, you would be gravely wrong. I have seen so many weird things that it makes absolute sense to audit changes. You may be surprised to learn that there is a DBA on staff that is adding, dropping, changing, or updating stats out of cycle without communicating the changes.

How do we go about auditing these changes? Easy Peezee! We need only to employ the use and power of Extended Events (XEvents).

For the sake of posterity, I am also adding this to the MASSIVE collection of Extended Events articles.

XEvents to Audit your Statistics

Here comes the tricky part. Auditing your statistics is not quite as easy as auditing other traditional objects (like tables or indexes). Wait, I just mentioned indexes and stats are tightly coupled to indexes, right? True! Indexes and stats are very tightly coupled. So much so, that stats and indexes use the same identity increment for their id.

The post Statistics Auditing to make you Omniscient appeared first on SQL XEvents.

Granted there are times when a linked server makes a lot of sense. When choosing to use a linked server, it must be understood what the purpose of the linked server will be and to not abuse the linked server. Restrict the use of the linked server to a small scope and hopefully an infrequent use. For instance, I have demonstrated good uses of linked servers in my poor mans audit presentation and in my database restore solutions article.

Do you know if you have linked servers? Now is a good time to check. Furthermore, if you do have linked servers do you know the extent of use on these linked servers? It is a quick and painless check to determine if linked servers have invaded your environment.

Linked Server Invasion?

If you need to check for the existence of linked servers in your environment, this quick tutorial can catch you up to speed and help with that task. As a short-cut here is a query that can help as well.

…

The post Powerful Monitoring for Your Linked Servers with XEvents appeared first on SQL XEvents.