Does not writing a checkpoint record damage anything?

Question

I got an alert

Event ID: 3619. Could not write a checkpoint record in database 'ID ####' because the log is out of space

I know why it happened, I have addressed the issue, backed up the t-logs, shrunk the log that overgrew and other wise done my best to ensure it does not occur again. The issue that caused the logs to fill was an index rebuild.

Other than checkpoint not getting written and the specific index rebuild not finishing, I don't see anything else going wrong.

Does the failed checkpoint write (by its self) cause any damage that I might need to address?

Reference CHECKPOINT (Transact-SQL)

Answer 1

The checkpoint process writes a record into the log to allow the database recovery process, used when starting a database, as a base point-in-time. In other words, the recovery process only looks at log records since the last checkpoint record that exists in the log. The items recorded in the log allow SQL Server to either roll-back or roll-forward transactions that weren't fully committed at the point of shutdown or failure of the SQL Server instance.

I would take a full database backup, and a log backup, to ensure there is a recent checkpoint in your backup chain.

From the MSDN page on checkpoint:

A checkpoint creates a known good point from which the SQL Server Database Engine can start applying changes contained in the log during recovery after an unexpected shutdown or crash.

For automatic, manual, and internal checkpoints, only modifications made after the latest checkpoint need to be rolled forward during database recovery. This reduces the time required to recover a database.

So, to directly answer your question; if the checkpoint cannot be written, an earlier checkpoint that is contained in the log will be used as the base point for recovery. Essentially, the error you got should be treated as a warning that you've run out of log space.

Answer 2

Does the failed checkpoint write (by its self) cause any damage that I might need to address?

There would be no damage as such, what checkpoint does is it writes dirty pages from buffer pool to the disk reducing the amount of recovery time and amount of work SQL Server has to do after restart or crash recovery. In extreme case if database goes under crash recovery the amount of time taken to recover database would increase.

In your case it is good you found out that it was actually the index rebuild which produced some good amount of logs and eventually failed because of low disk space on log drive. This would just rollback the operation and would bring fragmentation as it was before the rebuild