Attempt to fetch logical page %S_PGID in database %d failed. It belongs to allocation unit %I64d not to %I64d.

This error generally signifies page or allocation corruption in the specified database. SQL Server detects corruption when reading pages belonging to a table either by following the page linkages or by using the Index Allocation Map (IAM). All pages allocated to a table must belong to one of the allocation units associated with the table. If the allocation unit ID contained in the page header does not match an allocation unit ID associated with the table, this exception is raised. The first allocation unit ID listed in the error message is the ID present in the page header, the second allocation unit value is the ID associated with the table.

Data Corruption Errors

A severity level of 21 indicates potential data corruption. Possible causes are a damaged page chain, a corrupt IAM, or an invalid entry in the sys.objects catalog view for that object. These errors are often caused by hardware or disk device driver failure.

Transient Errors

A severity level of 12 indicates a potential transient error; that is, it occurs in the cache and does not indicate damage to data on disk. Transient 605 errors can be caused by the following conditions:

• The operating system prematurely notifies SQL Server that an I/O operation has completed; the error message is displayed even though no actual data corruption exists.

• Running a query with the Optimizer hint NOLOCK or setting the transaction isolation level to READ UNCOMMITTED. When a query that is using NOLOCK or READ UNCOMMITTED tries to read data that is being moved or changed by another user, a 605 error occurs. To verify that it is a transient 605 error, rerun the query later. For more information, see this
  KB articlehttp://support.microsoft.com/kb/235880/en-us
  .

In general, if the error occurs during data access but subsequent DBCC CHECKDB operations complete without error, the 605 error was probably transient.

1. Identify the tables associated with the allocation units specified in the message by running the following query. Replace with the allocation units specified in the error message.

   USE ;
   GO
   SELECT au.allocation_unit_id, OBJECT_NAME(p.object_id) AS table_name, fg.name AS filegroup_name,
   au.type_desc AS allocation_type, au.data_pages, 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 = OR au.allocation_unit_id =
   ORDER BY au.allocation_unit_id;
   GO

2. Execute DBCC CHECKTABLE without a REPAIR clause on the table associated with the second allocation unit ID specified in the error message.

3. Execute DBCC CHECKDB without a REPAIR clause as soon as possible to determine the full extent of the corruption in the entire database.

4. Check the error log for other errors that often accompany a 605 error and examine the Windows Event Log for any system or hardware related issues. Fix any hardware-related problems that are contained in the logs.

5. If the 605 error is not transient, the problem is severe and must be corrected by performing one of the following tasks:

   1. If the problem is not hardware related and a known clean backup is available, restore the database from the backup. You can leverage the page restore backup feature to restore just the damaged pages.

   2. Run DBCC CHECKDB with the REPAIR clause recommended by the DBCC CHECKDB operation performed in step 2 to repair the corruption.

   Caution:

   If you are not sure what effect DBCC CHECKDB with a REPAIR clause has on your data, contact your primary support provider before running this statement.

   1. If running DBCC CHECKDB with one of the REPAIR clauses does not correct the problem, contact your primary support provider. Have the output from DBCC CHECKDB available for review.