Checkpoint Analysis: Your Exclusive How-To with XEvents

Checkpoints are essential in SQL Server to help with the durability and reliability of data persisted in the database. When done right, you barely even notice them and performance is groovy. Sadly, checkpoints can be a symptom of a problem and poor performance.

Checkpoints are essential in SQL Server to help with the durability and reliability of data persisted in the database. When done right, you barely even notice the checkpoint and performance is groovy. Sadly, checkpoints can be a symptom of a problem and poor performance.

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. Use of the checkpoint and writing to disk in this fashion is done in favor of performance since writes to disk would be far more costly if every transaction went straight to disk.

Types of Checkpoints

checkpointTo help with the various needs for checkpointing, there are four types of checkpoints in SQL Server. These types are:

  1. Automatic – issued automatically in the background to meet the upper bound of the “recovery interval” server configuration. By default this is roughly every minute for active databases. This can be throttled if there are io issues are too many pending writes.
  2. Indirect – provide an user configurable alternative for each database over the automatic checkpoint option. This typically provides faster more predictable recovery times.
  3. Manual – issued by user for the current database connection. (Does require elevated permissions such as dbo, sysadmin, or backupoperator role membership.)
  4. Internal – performed during such operations as backups or snapshots to ensure consistency and recoverability.

Of these four types, we will be primarily focused on the first two types of checkpoints. Both of these are technically automatic background checkpoints, but with some potential performance impacts we would want to occasionally monitor (e.g. io storm and FlushCache issues).

Tracking and Monitoring

In order to capture checkpoint events, and begin to understand their impact on the system, we need to use Extended Events. To create such a session to capture the necessary events is rather easy.

Checkpoint Tracking Results

When running this session, I can expect to be able to track checkpoint run times as well as extra data related to indirect checkpoints. Depending on the version of SQL Server, your results may vary slightly due to what is delivered in the event payloads. In the following images, I will show some of the interesting payload and differences between SQL 2017 and SQL 2019.

And now for SQL 2019.

The is_trivial and last_oldest_page_lsn attributes in the event payload are highlighted in green. These are new in SQL 2019! The last_oldest_oage_lsn is an interesting tidbit of information as it relates to the oldest_page status in the log_reuse_wait_desc column that can indicate a growing log file. There will be more on that in a future article.

Checkpoint Monitor Session Parsing

If you don’t have much desire to try to figure out the total time for each checkpoint by manual calculations from the “View Target Data” output grid gui, here is a script to do that work for you!

Using this script, I have been enabled to easily find checkpoint hotspots and problem databases. One recent client was experiencing 13 second plus checkpoints. Through the use of this session and parse script, I could identify the problems and then use that to leverage the need to change to indirect checkpoints.

While still using this session, I could then show the client that the indirect checkpoint improved checkpoint performance down to 20ms or faster. That is a huge win, especially when considering the checkpoints were triggering every 60-70 seconds. OUCH!

Put a Bow on It

In this article, once again have demonstrated the power of Extended Events. And no, you cannot do this with that tool called Profiler. You need the power of XEvents in order to reveal the issues related to the database checkpoint process.

Not only will you be able to see the performance issues, but you will also be able to justify changes that will resolve those problems. Furthermore, you will then be able to demonstrate that the change was the correct thing to do!

For more uses of Extended Events, I recommend my series of articles designed to help you learn XE little by little.

Interested in seeing the power of XE over Profiler? Check this one out!

This is twelfth post in the 2021 “12 Days of Christmas” series. All articles in the series (for all years) is available via this page.

Leave a Reply

Your email address will not be published.

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