SQL Server Error 845 and Error 5901: How to Troubleshoot Buffer Latch Timeouts and Checkpoint Failures

Introduction

SQL Server Error 845 and Error 5901 can indicate a serious underlying performance, storage, or database integrity problem.

A typical error sequence can look like this:

Error: 845, Severity: 17, State: 1.

Time-out occurred while waiting for buffer latch type 3
for page (3:180392778), database ID 7.

One or more recovery units belonging to database
'ApplicationDB' failed to generate a checkpoint.

Error: 5901, Severity: 16, State: 1.

Although Error 5901 may appear to be the main problem, it is often only a secondary symptom.

The more important error is frequently Error 845, which indicates that SQL Server waited too long for access to a database page.

In many environments, the underlying problem is related to:

• slow storage
• stalled I/O
• storage path problems
• SAN or VM disk latency
• overloaded infrastructure
• database page problems
• severe internal contention

The key is to identify the actual cause before making changes.

What Is SQL Server Error 845?

SQL Server Error 845 is commonly associated with:

BUFLATCH_TIMEOUT

An example is:

Error: 845, Severity: 17, State: 1.

Time-out occurred while waiting for buffer latch
for page (3:180392778), database ID 7.

SQL Server stores database pages in memory in the buffer pool.

Before SQL Server can safely read or modify certain page structures, it must obtain an internal synchronization mechanism known as a latch.

A simplified sequence looks like this:

Application query
       ↓
SQL Server requires a database page
       ↓
Page is requested from memory/storage
       ↓
SQL Server waits for required buffer latch
       ↓
Latch or I/O does not complete
       ↓
Timeout
       ↓
Error 845

This is different from normal SQL blocking.

Locks protect transactional data consistency.

Latches protect internal SQL Server memory and page structures.

Understanding the Page Number in Error 845

An error may contain something similar to:

page (3:180392778)
database ID 7

This means:

Database ID = 7
File ID     = 3
Page ID     = 180392778

This information is extremely valuable.

It allows the DBA to identify:

• which database experienced the problem
• which database data file contains the page
• which physical disk or storage volume hosts the file
• potentially which table or index owns the page

For example:

Database
   │
   ├── File 1 → E:\SQLData\ApplicationDB.mdf
   ├── File 2 → E:\SQLData\ApplicationDB_02.ndf
   │
   └── File 3 → F:\SQLData\ApplicationDB_03.ndf
                         ↑
                    Error occurred

If repeated errors consistently involve File ID 3, the underlying storage hosting that file deserves particular attention.

What Is SQL Server Error 5901?

Error 5901 commonly appears as:

Error: 5901, Severity: 16, State: 1.

One or more recovery units belonging to database
'ApplicationDB' failed to generate a checkpoint.

A SQL Server checkpoint writes modified, or dirty, pages from memory to database files.

Conceptually:

Modified pages in SQL Server memory
             ↓
         CHECKPOINT
             ↓
Write pages to .MDF / .NDF files
             ↓
Reduce crash-recovery work

Error 5901 means SQL Server was unable to complete this process successfully.

The important point is:

Error 5901 is frequently the result of another underlying problem rather than the primary cause.

For example:

Slow or stalled I/O
        ↓
Database page operation does not complete
        ↓
Buffer latch timeout
        ↓
Error 845
        ↓
Checkpoint cannot finish
        ↓
Error 5901

Therefore, always investigate the messages immediately preceding Error 5901.

Why Repeated Error 5901 Events Are Important

One isolated checkpoint failure may be transient.

Repeated failures are more concerning.

For example:

21 Sep   Error 5901
23 Sep   Error 5901
24 Sep   Error 5901
29 Sep   Error 845 + Error 5901

This pattern suggests an intermittent recurring problem.

Potential causes include:

• recurring storage latency
• backup or snapshot activity
• SAN snapshot operations
• antivirus scanning
• ETL workloads
• index maintenance
• VM backup activity
• storage replication
• insufficient memory
• disk queue saturation
• storage controller issues
• problematic database pages

The timing of the errors can provide important clues.

If errors consistently occur around the same time each night, check for scheduled activity during that period.

Step 1: Identify the Database

Start by confirming which database corresponds to the database ID reported in the error.

SELECT
    database_id,
    name,
    state_desc,
    recovery_model_desc,
    page_verify_option_desc
FROM sys.databases
WHERE database_id = 7;

Ideally, the database should show:

state_desc              ONLINE
page_verify_option_desc CHECKSUM

Using CHECKSUM for page verification is generally recommended because it allows SQL Server to detect certain forms of page corruption.

Step 2: Identify the Affected Database File

If the error reports:

page (3:180392778)

the first number is the file ID.

Run:

USE ApplicationDB;
GO

SELECT
    file_id,
    name,
    type_desc,
    physical_name,
    size * 8.0 / 1024 AS SizeMB,
    state_desc
FROM sys.database_files
ORDER BY file_id;

Locate:

file_id = 3

You can now determine which physical disk or mount point hosts the affected database page.

This is particularly important in environments using:

• SAN
• iSCSI
• VMware
• Hyper-V
• Azure VM managed disks
• AWS EBS
• clustered storage

Step 3: Search the SQL Server Error Log for Related I/O Errors

Error 845 should never be examined in isolation.

Search the SQL Server error log for:

823
824
825
833
845

Use:

EXEC sys.xp_readerrorlog 0, 1, N'823';
EXEC sys.xp_readerrorlog 0, 1, N'824';
EXEC sys.xp_readerrorlog 0, 1, N'825';
EXEC sys.xp_readerrorlog 0, 1, N'833';
EXEC sys.xp_readerrorlog 0, 1, N'845';

Also search for:

EXEC sys.xp_readerrorlog
    0,
    1,
    N'I/O requests taking longer';

These errors provide different clues.

Error 823

Typically indicates an operating-system or physical I/O problem.

Examples may include:

• device errors
• storage communication failures
• controller failures
• operating system write/read errors

Error 824

SQL Server received the page from storage but detected a logical consistency issue.

This can indicate:

• checksum failure
• torn page
• corrupted page structure

Error 824 should be treated very seriously.

Error 825

SQL Server had to retry an I/O operation before it succeeded.

An 825 may therefore be an early warning of unreliable or slow storage.

Error 833

Indicates excessively long I/O operations.

This often correlates strongly with storage latency problems.

Error 845

Indicates SQL Server waited too long for a buffer latch operation.

Step 4: Check SQL Server Suspect Pages

SQL Server records certain page-level errors in:

msdb.dbo.suspect_pages

Run:

SELECT
    DB_NAME(database_id) AS DatabaseName,
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
ORDER BY last_update_date DESC;

To check the affected database:

SELECT *
FROM msdb.dbo.suspect_pages
WHERE database_id = DB_ID('ApplicationDB')
ORDER BY last_update_date DESC;

If the page from Error 845 appears here, investigate it further.

For example:

File ID : 3
Page ID : 180392778

Step 5: Determine Which Object Owns the Page

Identifying the table or index associated with the affected page can help determine the scope of the problem.

Use:

USE ApplicationDB;
GO

SELECT
    OBJECT_SCHEMA_NAME(pa.object_id) AS SchemaName,
    OBJECT_NAME(pa.object_id) AS ObjectName,
    pa.object_id,
    pa.index_id,
    i.name AS IndexName,
    pa.partition_id,
    pa.allocation_unit_type_desc,
    pa.allocated_page_file_id,
    pa.allocated_page_page_id
FROM sys.dm_db_database_page_allocations
(
    DB_ID(),
    NULL,
    NULL,
    NULL,
    'DETAILED'
) AS pa
LEFT JOIN sys.indexes AS i
    ON pa.object_id = i.object_id
   AND pa.index_id = i.index_id
WHERE pa.allocated_page_file_id = 3
  AND pa.allocated_page_page_id = 180392778;

This may reveal whether the page belongs to:

• heap data
• clustered index
• nonclustered index
• LOB data
• internal allocation structures

This distinction can be important if corruption is later detected.

Step 6: Inspect the Page

For deeper troubleshooting, DBAs can inspect the page using DBCC PAGE.

DBCC TRACEON(3604);
GO

DBCC PAGE
(
    'ApplicationDB',
    3,
    180392778,
    3
);
GO

DBCC TRACEOFF(3604);
GO

This command is mainly intended for diagnostic use.

Do not attempt to modify the page manually.

If DBCC PAGE itself produces I/O errors or hangs while attempting to access the page, this is useful evidence for the investigation.

Step 7: Run DBCC CHECKDB

Database consistency should be checked as early as practical.

Start with:

DBCC CHECKDB ('ApplicationDB')
WITH PHYSICAL_ONLY,
     NO_INFOMSGS,
     ALL_ERRORMSGS;
GO

PHYSICAL_ONLY performs a faster physical consistency check.

If this completes successfully, schedule a full consistency check:

DBCC CHECKDB ('ApplicationDB')
WITH NO_INFOMSGS,
     ALL_ERRORMSGS;
GO

If errors are returned, retain the complete output.

Do not immediately execute:

REPAIR_ALLOW_DATA_LOSS

despite the name appearing in CHECKDB output.

Where a clean backup exists, restoration is normally preferable to destructive repair because REPAIR_ALLOW_DATA_LOSS may remove damaged pages or records in order to restore structural consistency.

Step 8: Measure SQL Server File I/O Latency

Use sys.dm_io_virtual_file_stats to compare storage latency between database files.

SELECT
    DB_NAME(vfs.database_id) AS DatabaseName,
    mf.file_id,
    mf.type_desc,
    mf.physical_name,

    vfs.num_of_reads,
    vfs.num_of_writes,

    CASE
        WHEN vfs.num_of_reads = 0 THEN 0
        ELSE
            vfs.io_stall_read_ms * 1.0 /
            vfs.num_of_reads
    END AS AvgReadLatencyMs,

    CASE
        WHEN vfs.num_of_writes = 0 THEN 0
        ELSE
            vfs.io_stall_write_ms * 1.0 /
            vfs.num_of_writes
    END AS AvgWriteLatencyMs

FROM sys.dm_io_virtual_file_stats(NULL,NULL) AS vfs

JOIN sys.master_files AS mf
    ON mf.database_id = vfs.database_id
   AND mf.file_id = vfs.file_id

WHERE vfs.database_id = DB_ID('ApplicationDB')

ORDER BY mf.file_id;

Compare the affected file with the other files.

For example:

File   Read Latency   Write Latency

1       4 ms           6 ms
2       5 ms           7 ms
3     190 ms         260 ms
4       5 ms           8 ms

A dramatic difference for File 3 would strongly suggest that the storage supporting that file requires investigation.

Remember that these statistics are cumulative since SQL Server started.

They are useful evidence, but they do not necessarily represent latency at the exact time of the incident.

Step 9: Check Pending I/O Requests

The following query can show SQL Server I/O requests that are currently waiting:

SELECT
    DB_NAME(mf.database_id) AS DatabaseName,
    mf.file_id,
    mf.physical_name,
    io.io_pending,
    io.io_pending_ms_ticks,
    io.io_type
FROM sys.dm_io_pending_io_requests AS io

JOIN sys.dm_io_virtual_file_stats(NULL,NULL) AS vfs
    ON io.io_handle = vfs.file_handle

JOIN sys.master_files AS mf
    ON mf.database_id = vfs.database_id
   AND mf.file_id = vfs.file_id

ORDER BY io.io_pending_ms_ticks DESC;

Large pending I/O times may indicate that requests are not being completed promptly by the underlying storage.

Step 10: Check Disk Capacity

A full or nearly full disk can also create database problems.

Check available space:

SELECT DISTINCT
    vs.volume_mount_point,
    vs.logical_volume_name,

    vs.total_bytes / 1024.0 / 1024 / 1024
        AS TotalGB,

    vs.available_bytes / 1024.0 / 1024 / 1024
        AS FreeGB,

    CAST(
        vs.available_bytes * 100.0 /
        NULLIF(vs.total_bytes,0)
        AS decimal(6,2)
    ) AS FreePercent

FROM sys.master_files AS mf

CROSS APPLY sys.dm_os_volume_stats
(
    mf.database_id,
    mf.file_id
) AS vs;

Check space for:

• database data files
• transaction log files
• tempdb
• SQL Server log directory
• backup destination
• Windows system volume

Step 11: Check Windows Event Logs

SQL Server may only be reporting the symptom.

The actual problem may exist at the operating-system or infrastructure layer.

Review the Windows System Event Log around the incident.

Look for sources such as:

Disk
Ntfs
StorPort
stornvme
storahci
volmgr
MPIO
iScsiPrt

Common suspicious messages include:

Reset to device
I/O request timed out
Device not ready
Controller error
Bad block
Multipath failover
Disk retry
Delayed write

If SQL Server is running in a virtual machine, also check:

VM host
hypervisor
storage array
SAN
HBA
iSCSI
cloud disk metrics

A guest VM may report a SQL Server timeout even though the real cause exists several infrastructure layers below it.

Step 12: Correlate the Time of the Error

Repeated errors occurring at approximately the same time can reveal the root cause.

For example:

21 Sep   02:19
23 Sep   02:42
24 Sep   02:50
29 Sep   02:52

This pattern should immediately prompt investigation into scheduled jobs.

Check for:

• SQL Server backups
• VM backups
• SAN snapshots
• VSS snapshots
• antivirus scanning
• index maintenance
• DBCC CHECKDB
• ETL batches
• reporting jobs
• data warehouse loads
• replication jobs
• storage replication
• cloud snapshots

Step 13: Review SQL Server Agent Jobs

Check jobs running around the incident time.

SELECT
    j.name AS JobName,

    msdb.dbo.agent_datetime
    (
        h.run_date,
        h.run_time
    ) AS RunDateTime,

    h.run_duration,
    h.run_status,
    h.message

FROM msdb.dbo.sysjobhistory AS h

JOIN msdb.dbo.sysjobs AS j
    ON h.job_id = j.job_id

WHERE h.step_id = 0

ORDER BY RunDateTime DESC;

Then compare job times against the Error 845/5901 timestamps.

A repeatable correlation is highly significant.

For example:

02:00 Backup starts
02:15 SAN snapshot starts
02:40 storage latency increases
02:52 Error 845
02:52 Error 5901
03:05 snapshot finishes
03:10 system returns to normal

This can transform what initially looks like a database issue into an infrastructure scheduling issue.

Step 14: Investigate Backups

An affected database should have recoverable backups available.

Check backup history:

SELECT TOP (20)
    bs.database_name,
    bs.type,
    bs.backup_start_date,
    bs.backup_finish_date,
    bs.has_backup_checksums,
    bs.is_damaged,
    bs.backup_size / 1024.0 / 1024 / 1024
        AS BackupSizeGB,
    bmf.physical_device_name

FROM msdb.dbo.backupset AS bs

JOIN msdb.dbo.backupmediafamily AS bmf
    ON bs.media_set_id = bmf.media_set_id

WHERE bs.database_name = 'ApplicationDB'

ORDER BY bs.backup_finish_date DESC;

Prefer backups using:

WITH CHECKSUM

where appropriate.

However, a successful backup job alone does not prove that the database is fully recoverable.

Step 15: Perform a Test Restore

One of the strongest database recovery checks is:

Backup
   ↓
Restore to another SQL Server
   ↓
Recover database
   ↓
Run DBCC CHECKDB

After restoring:

DBCC CHECKDB ('ApplicationDB_Restore')
WITH NO_INFOMSGS,
     ALL_ERRORMSGS;
GO

A successful restore combined with a clean CHECKDB provides far greater confidence than simply seeing a successful backup job.

Should SQL Server Be Restarted?

Restarting SQL Server should not normally be the first troubleshooting action.

Restarting can:

• clear useful diagnostic information
• reset cumulative I/O statistics
• remove evidence of waits and memory pressure
• trigger database crash recovery
• potentially expose additional problems if storage remains unstable

A restart may sometimes restore service temporarily, but it does not address the underlying cause.

Collect evidence first wherever operationally possible.

What Not to Do

During an Error 845/5901 investigation, avoid taking destructive actions without understanding the root cause.

Do not immediately:

Restart SQL Server
Detach and attach the database
Shrink database files
Rebuild every index
Run REPAIR_ALLOW_DATA_LOSS
Delete suspect database files
Clear the SQL Server cache
Move database files blindly
Ignore recurring 825/833 warnings

These actions may hide symptoms without solving the actual issue.

Could DBCC FREEPROCCACHE Cause Error 845?

You may also encounter messages such as:

SQL Server has encountered a cachestore flush
for the 'Object Plans' cachestore due to
'DBCC FREEPROCCACHE' or 'DBCC FREESYSTEMCACHE'.

This means SQL Server's execution-plan cache was explicitly cleared.

You can search SQL Agent jobs for commands such as:

SELECT
    j.name AS JobName,
    s.step_id,
    s.step_name,
    s.command

FROM msdb.dbo.sysjobs AS j

JOIN msdb.dbo.sysjobsteps AS s
    ON j.job_id = s.job_id

WHERE
       s.command LIKE '%FREEPROCCACHE%'
    OR s.command LIKE '%FREESYSTEMCACHE%';

While clearing the plan cache can temporarily increase CPU and compilation activity, it should not automatically be assumed to be the cause of an Error 845.

Treat it as additional evidence and correlate it with the timeline.

Recommended Troubleshooting Workflow

A practical troubleshooting sequence is:

1. Capture the exact Error 845 page information
                ↓
2. Identify the database
                ↓
3. Identify the database file
                ↓
4. Search for 823/824/825/833/845
                ↓
5. Check msdb.dbo.suspect_pages
                ↓
6. Run DBCC CHECKDB WITH PHYSICAL_ONLY
                ↓
7. Identify the affected table/index
                ↓
8. Review SQL file I/O latency
                ↓
9. Review Windows/storage events
                ↓
10. Correlate scheduled jobs
                ↓
11. Validate backups
                ↓
12. Perform test restore + CHECKDB

Common Root Causes

In real environments, Error 845 and subsequent checkpoint failures commonly fall into several categories.

Storage latency

This is one of the first areas to investigate.

Possible causes include:

SAN overload
Cloud disk throttling
Storage controller saturation
High disk queue depth
VM host storage contention
Backup snapshots
Storage replication
iSCSI congestion

Storage path failures

Intermittent storage path problems may cause long waits without permanently disconnecting the disk.

Examples include:

MPIO path failover
SAN fabric issue
HBA problem
iSCSI packet loss
Storage controller failover

Database corruption

If CHECKDB reports errors or suspect pages are recorded, database corruption becomes a major concern.

Restore from a known-good backup wherever practical.

Severe system resource pressure

Extreme memory, CPU or I/O pressure can sometimes prevent SQL Server internal operations from completing normally.

Scheduled maintenance conflicts

Running multiple heavy operations simultaneously can overwhelm storage.

For example:

02:00 SQL full backup
02:00 VM snapshot
02:10 index rebuild
02:15 antivirus scan
02:20 ETL process

Each job individually may be acceptable.

Together they may create severe I/O pressure.

Preventing Future Error 845 Incidents

After the immediate issue is resolved, implement proactive monitoring.

Monitor:

Database-file read latency
Database-file write latency
Disk queue length
IOPS
Storage throughput
Storage throttling
SQL Server Error 823
SQL Server Error 824
SQL Server Error 825
SQL Server Error 833
SQL Server Error 845
DBCC CHECKDB results
Backup health
Free disk space

You should also consider alerting whenever SQL Server logs:

823
824
825
833
845
5901

Early detection can help identify storage degradation before it becomes a database outage.

Final Takeaway

SQL Server Error 845 should not be treated simply as a query timeout.

When SQL Server reports:

Time-out occurred while waiting for buffer latch

and this is followed by:

Error 5901
failed to generate a checkpoint

the DBA should investigate the entire I/O path.

The most useful evidence usually comes from correlating:

SQL Server error logs
        +
Database page information
        +
DBCC CHECKDB
        +
SQL Server I/O statistics
        +
Windows event logs
        +
SAN / VM / cloud storage metrics
        +
Scheduled workload activity

In many cases the database engine is only exposing a problem occurring lower in the infrastructure stack.

Finding the actual root cause requires looking beyond SQL Server itself.

Quick DBA Checklist

When Error 845 appears:

• Record the database ID, file ID and page ID.
• Find the physical database file.
• Search for Errors 823, 824, 825 and 833.
• Check msdb.dbo.suspect_pages.
• Run DBCC CHECKDB ... WITH PHYSICAL_ONLY.
• Compare database-file I/O latency.
• Review Windows System events.
• Review SAN, VM or cloud-disk metrics.
• Check activity running at the same time.
• Verify backup health.
• Perform a test restore where possible.
• Avoid REPAIR_ALLOW_DATA_LOSS unless all safer recovery options have been considered.

A recurring Error 845 combined with Error 5901 should be treated as an infrastructure and database reliability warning, not simply dismissed because the database remains online.