BAD_PAGE_PROCESS Wait Type in SQL Server

---

Microsoft’s definition: it occurs when the background suspect page logger is trying to avoid running more than every five seconds, and excessive suspect pages make the logger run frequently. You will see it at most once per 823 or 824 error, the I/O errors SQL Server raises when a page cannot be read or fails its checks. That makes it the rare wait whose count is the message.

---

Is It a Problem?

Any presence is a corruption signal, not a performance discussion. Repeated waits mean repeated 823 or 824 errors: either widespread damage, or a workload hitting the same damaged pages over and over. This is one wait where filtering it out would be exactly wrong. It was zero on our SQL Server 2025 lab, as it should be. Get Wait Statistics does not filter it out, so if it ranks, you will see it.

The baseline to monitor is zero rows added to msdb.dbo.suspect_pages.

---

Common Causes

• Storage faults damaging pages: controllers, firmware, drivers, the SAN path.
• A damaged page that the workload keeps reading.
• Memory faults that write bad pages, which then fail their checks when read back.

---

The Check To Run

Read the suspect page list:

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

Then read the error log for the 823 and 824 messages, which name the file, page and error. Get Suspect Pages and Integrity Checks combines this with the last clean DBCC CHECKDB per database.

---

What To Do

1. Run DBCC CHECKDB on the affected databases to see how far the damage goes; DBCC CHECKDB Found Corruption walks through reading the output.
2. Restore from backups where you can: page restore for a few isolated pages, a full restore for wider damage. Do not reach for REPAIR_ALLOW_DATA_LOSS before restore options are exhausted.
3. Bring in the storage team at the same time; corruption that keeps coming back will not stop until its cause does.

---

The IO Family

These are I/O waits outside the page latch families: bulk file operations, file growth, backups and throttling. The main page is IO_COMPLETION; for reads and writes of data pages, see PAGEIOLATCH_SH.

• IO_COMPLETIONSynchronous I/O. Waiting for I/O to finish, generally I/O that is not for data pages.The main page for this family
• ASYNC_IO_COMPLETIONAsynchronous I/O. Bulk file work such as backups reading data files and checkpoints.Worth investigating
• WRITE_COMPLETIONWrites. A write operation in progress.Worth a look when it climbs
• FGCB_ADD_REMOVEFile growth. A latch class rather than a wait type, taken for file add, drop, grow and shrink.Worth investigating
• IO_QUEUE_LIMITI/O throttle. Documented as internal use only; an I/O governance limit.Worth investigating
• BAD_PAGE_PROCESSSuspect pages. The suspect page logger pacing itself; a corruption signal when present.Worth a look when it climbs. This page.
• DISKIO_SUSPENDSnapshot backup. Waiting to access a file while an external backup is active.Worth a look when it climbs
• REPLICA_WRITESSnapshot writes. Page writes to database snapshots or DBCC replicas.Worth a look when it climbs
• FCB_REPLICA_READ / WRITESnapshot file sync. Synchronised reads from, and page pushes into, a snapshot sparse file.Usually noise
• IMPPROV_IOWAITBulk load I/O. Waiting for a bulk load I/O to finish.Worth a look when it climbs
• ASYNC_DISKPOOL_LOCKFile creation. Synchronising parallel threads that create or initialise a file.Worth a look when it climbs

---

Where To Go Next