- Error number
- 823
- Severity
- 24 (fatal: the connection ends; may indicate a serious problem)
- State
- 2
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
- Category
- Corruption & Consistency
- Last reviewed
- 23 October 2026
On this page
What it means
Error 823 means Windows itself reported that a read or write of a database file failed, so SQL Server could not get or save the page; the cause is in the disk, controller, driver or network path to the storage.
SQL Server reads and writes database files through Windows file APIs. When one of those calls fails with an operating system error, SQL Server raises 823 at severity 24 (a hardware or media error): the statement fails and the connection is closed. For reads, Microsoft documents that SQL Server retries four times before giving up; if a retry succeeds, the query carries on and error 825 is written to the error log as a warning instead.
The message tells you where to look: the operating system error in brackets (for example 1117, an I/O device error, or 21, device not ready), whether it was a read or a write, the file, and the byte offset. Dividing the offset by 8,192 gives the page number. Unlike error 824, where Windows reported success but the page content was wrong, 823 means the I/O itself failed.
Common causes
- A failing disk, controller, HBA or storage array, or outdated firmware.
- A faulty or outdated storage driver, multipath software or virtual disk driver.
- A volume or LUN that went offline, or an unstable network path to SAN or NAS storage (OS error 21 means the device is not ready).
- Filter drivers in the I/O path, such as antivirus or backup agents, interfering with database files.
- File system inconsistencies on the volume that holds the database files.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Which pages are recorded as suspect?
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; Event type 1 rows are 823 errors (and 824 errors other than checksum and torn page). Pages in several databases on the same volume point to the storage, not to one database.
Find every 823 and 825 in the error log
EXEC sp_readerrorlog 0, 1, N'The operating system returned error';
EXEC sp_readerrorlog 0, 1, N'succeeded after failing'; Each failed I/O with its file, offset and operating system error, and any reads that only succeeded after retrying (825). A pattern of one file or one volume narrows down the device.
Which files live on the affected volume?
SELECT DB_NAME(mf.database_id) AS database_name, mf.physical_name,
vs.volume_mount_point, vs.logical_volume_name
FROM sys.master_files AS mf
CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) AS vs
ORDER BY vs.volume_mount_point, database_name; Every database with files on the same volume as the file in the message. Check all of them, not only the one that failed.
Run a consistency check
DBCC CHECKDB without a repair option only reads and reports. It is heavy, so run it off-peak or on a restored copy on other hardware. Microsoft notes that if it reports nothing, the problem was probably intermittent in the I/O path.
DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS; No output means no consistency errors. Otherwise the damage it lists and the minimum repair level tell you how much is affected; use that to plan a restore, not as an instruction to repair.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Fix the I/O path with your storage team or vendor
Client or network sideLook for disk, controller and driver errors in the Windows System event log at the same time as the 823, update firmware and drivers, and review filter drivers (fltmc filters). Microsoft SQLIOSim, installed in the SQL Server Binn folder, can show whether the storage fails outside SQL Server too. Until the path is reliable, more errors and damage can follow.
Move the database to healthy storage and restore
Changes database stateIf CHECKDB reports damage, restore from the last good backup onto storage that works, then roll forward with log backups. For a few damaged pages, a page restore is possible. Run DBCC CHECKDB on the result.
Caution: RESTORE with REPLACE overwrites the current database. Back up the tail of the log first (BACKUP LOG ... WITH NO_TRUNCATE) so committed work is not lost, and restore onto healthy storage.
RESTORE DATABASE AppDb
FROM DISK = N'D:\Backups\AppDb_full.bak'
WITH NORECOVERY, REPLACE,
MOVE N'AppDb' TO N'F:\SqlData\AppDb.mdf',
MOVE N'AppDb_log' TO N'F:\SqlLogs\AppDb_log.ldf';
-- then RESTORE LOG ... WITH NORECOVERY for each log backup, finishing WITH RECOVERY
Alert on 823, 824 and 825 so the next one is seen at once
Changes configurationSQL Server Agent alerts on these message numbers notify an operator the moment an I/O problem is logged, including 825 retries that never fail a query. Add a notification to an operator with sp_add_notification after creating each alert.
EXEC msdb.dbo.sp_add_alert @name = N'Error 823 I/O failure', @message_id = 823, @severity = 0, @include_event_description_in = 1;
EXEC msdb.dbo.sp_add_alert @name = N'Error 824 page check failure', @message_id = 824, @severity = 0, @include_event_description_in = 1;
EXEC msdb.dbo.sp_add_alert @name = N'Error 825 read retry', @message_id = 825, @severity = 0, @include_event_description_in = 1;
Examples
A read fails on a failing disk
Shown as documented by Microsoft; not reproduced here because it needs a failing disk or I/O path. The query fails and the connection is closed. The same message is written to the error log as Error: 823, Severity: 24, State: 2.
SELECT * FROM dbo.Orders;
Msg 823, Level 24, State 2, Line 1 The operating system returned error 1117(The request could not be performed because of an I/O device error.) to SQL Server during a read at offset 0x0000002d460000 in file 'E:\SqlData\AppDb.mdf'. Additional messages in the SQL Server error log and operating system error log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
How to prevent it
Treat error 825 as the early warning it is: alert on 823, 824 and 825 with SQL Server Agent alerts, and investigate the storage as soon as 825 appears rather than waiting for reads to fail outright.
Keep storage firmware and drivers current, exclude database files from antivirus scanning, run DBCC CHECKDB regularly and test restores, so an I/O failure ends in a planned restore rather than data loss.
Common questions
Is error 823 a SQL Server bug?
Almost never. SQL Server reports what Windows told it: the read or write failed. The fix is in the storage path, which is why the operating system error in the message matters.
How do I find the page from the offset?
Divide the byte offset by 8,192. For example, offset 0x2d460000 is 759,562,240 bytes, which is page 92,720 of that file.
The error went away after a restart. Am I safe?
No. The device that failed once is likely to fail again, and the failed write may already have damaged data. Run DBCC CHECKDB and investigate the storage.
Learn more on CodeWithSQL
Official documentation
- MSSQLSERVER_823 (Microsoft Learn)
- Manage the suspect_pages table
- Restore pages (SQL Server)
- DBCC CHECKDB (Transact-SQL)
Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.