- Error number
- 605
- Severity
- 21 (fatal: the connection ends; may indicate a serious problem)
- State
- Not documented by Microsoft (not reproduced here)
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
- Category
- Corruption & Consistency
- Last reviewed
- 24 October 2026
On this page
What it means
Error 605 means SQL Server followed a page link or allocation map to a page whose header says it belongs to a different table or index; at severity 21 that is corruption, at severity 12 it is a transient read under NOLOCK.
Every page header records the allocation unit (the storage of one index or heap partition) it belongs to. When a scan follows a page chain or the Index Allocation Map (IAM) to the next page and finds a different allocation unit ID in the header, it raises 605. In the message, the first allocation unit ID is the one found in the page header and the second is the one the query expected; the page number and database ID tell you where.
The severity decides what it means. Microsoft documents severity 21 as potential corruption: a damaged page chain, a corrupt IAM or bad metadata, usually caused by hardware or drivers, which fails the query and closes the connection. Severity 12 is transient: the page in memory was being moved by another session while a NOLOCK or READ UNCOMMITTED query read it (or Windows reported an I/O complete too early), and nothing is wrong on disk. If DBCC CHECKDB later finds no errors, the 605 was transient. Check the level in the full message or in the error log before deciding.
Common causes
- Severity 21: a damaged page chain or IAM page, usually from a failing disk, controller, storage driver or firmware.
- Severity 21: an invalid metadata entry for the object, so the query expects the wrong allocation unit.
- Severity 12: a query using
WITH (NOLOCK)or READ UNCOMMITTED read a page that another transaction was moving or deallocating (the same mechanism as error 601). - Severity 12: the operating system reported an I/O as complete before the data was in memory, which Microsoft lists as a transient cause.
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 tables do the two allocation unit IDs belong to?
Microsoft's query, run in the database named by the database ID. Put both IDs from the message in the WHERE clause.
SELECT au.allocation_unit_id, OBJECT_NAME(p.object_id) AS table_name,
p.index_id, fg.name AS filegroup_name, au.type_desc AS allocation_type,
au.data_pages, p.partition_number
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
JOIN sys.filegroups AS fg ON fg.data_space_id = au.data_space_id
WHERE au.allocation_unit_id IN (72057594045792256, 72057594044678144)
ORDER BY au.allocation_unit_id;The table the query was reading (second ID) and the table the page actually belongs to (first ID). A first ID that matches nothing suggests a damaged or reused page.
Check the table named by the second allocation unit
DBCC CHECKTABLE (N'dbo.Orders') WITH NO_INFOMSGS, ALL_ERRORMSGS;No output means the table is consistent. If the 605 was at severity 12 and this is clean, the error was transient.
Check the whole database
Read-only without a repair option. Heavy on I/O: run it off-peak or on a restored copy.
DBCC CHECKDB (N'AppDb') WITH NO_INFOMSGS, ALL_ERRORMSGS;The full extent of any corruption and the minimum repair level, which tells you how bad it is (not an instruction to repair).
What severity was logged, and with which other errors?
EXEC sp_readerrorlog 0, 1, N'Error: 605';
EXEC sp_readerrorlog 0, 1, N'I/O error';
SELECT DB_NAME(database_id) AS database_name, file_id, page_id, event_type, last_update_date
FROM msdb.dbo.suspect_pages;Severity: 21 next to the error, 823 or 824 errors, or rows in suspect_pages point to real damage. Severity: 12 with nothing else points to the transient case.
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.
Transient (severity 12): rerun, then stop reading uncommitted data
Client or network sideRerun the query and confirm with DBCC CHECKTABLE that nothing is damaged. Then remove the NOLOCK hint or READ UNCOMMITTED from the query and use READ COMMITTED with row versioning or SNAPSHOT isolation, as described for error 601.
Corruption (severity 21): fix the storage path first
Client or network sideCheck the Windows System event log and the SQL Server error log for disk, controller and driver errors, update firmware and drivers, and review filter drivers and antivirus exclusions. Until the cause is fixed, new damage can appear.
Corruption (severity 21): restore from a clean backup
Changes database stateRestore the database, or only the damaged pages with a page restore, from a backup taken before the damage, then roll forward with log backups and run DBCC CHECKDB on the result. Microsoft lists DBCC repair only as the alternative when restore is not possible; repair with data loss deletes what it cannot fix and is a last resort, not a fix.
Caution: RESTORE with REPLACE overwrites the current database. Back up the tail of the log first (BACKUP LOG ... WITH NO_TRUNCATE if the database is damaged) and rehearse on a copy if you can.
-- Example: restore the damaged page, then roll forward with log backups
RESTORE DATABASE AppDb PAGE = '1:2241'
FROM DISK = N'D:\Backups\AppDb_full.bak'
WITH NORECOVERY;
-- then RESTORE LOG ... WITH NORECOVERY for each log backup,
-- take a new log backup, restore it, and finish WITH RECOVERY.Examples
A scan reaches a page owned by another allocation unit
Shown as documented by Microsoft; not reproduced here. The page number, database ID and allocation unit IDs are illustrative. The level depends on the cause (21 for corruption, 12 for the transient case) and the state was not observed, so only the message text is shown.
SELECT OrderId, Amount FROM dbo.Orders;Attempt to fetch logical page (1:2241) in database 7 failed. It belongs to allocation unit 72057594045792256 not to 72057594044678144.
How to prevent it
Keep PAGE_VERIFY CHECKSUM on, run DBCC CHECKDB on a schedule (or on restored copies), alert on errors 605, 823, 824 and 825, and test restores so a severity 21 605 becomes a page restore rather than data loss.
Avoid NOLOCK and READ UNCOMMITTED on busy tables; row versioning gives non-blocking reads without transient 605 and 601 errors.
Common questions
How do I know if a 605 is corruption or transient?
Look at the level: 21 is potential corruption, 12 is transient. Then run DBCC CHECKTABLE on the table and DBCC CHECKDB on the database. Microsoft notes that if later checks complete without error, the 605 was probably transient.
Which allocation unit ID is which?
The first ID is the one in the page header (who the page actually belongs to); the second is the one associated with the table the query was reading.
Should I run REPAIR_ALLOW_DATA_LOSS?
Not as a first step. Restore from a clean backup. Repair with data loss deletes damaged data and is only a last resort when no usable backup exists; work on a copy first.
Learn more on CodeWithSQL
Official documentation
Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.