Symptoms
Consider the following scenario in Microsoft SQL Server 2008 or in Microsoft SQL Server 2008 R2. A database includes a table that has one or more binary large object (BLOB) columns (such as text, ntext, or image data type columns). You perform the following actions on this table:
-
Enable the table for FileStream storage
-
Add a filestream column to the table (for example, [column name] [varbinary](max) FILESTREAM NULL)
-
Move the data from the existing binary large object column to the new filestream column
-
Drop the existing binary large object column
-
Rebuild the indexes on the table
After you perform these actions, you execute the DBCC CHECKDB command on the database. The DBCC CHECKDB report that is returned contains an error message that resembles the following message:
Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:158) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057594039828480 (type Unknown), but it was not detected in the scan.
Note This scenario applies to your situation only if the following conditions are true:
-
The error message that is mentioned in this section is the only error message that is included in the DBCC CHKECKDB report.
-
The reported type for the allocation unit is Unknown.
-
You migrate all the existing binary large object data to the FileStream columns so that no binary large object columns remain in the table after you complete this process. If the table has multiple binary large object columns, and you perform this sequence of actions over only one of the columns, this problem does not occur.
Cause
The sequence of actions that is described in the "Symptoms" section leaves the first IAM page of the allocation unit for the dropped binary large object column in an orphaned state. This condition generates the 2576 error message.
Resolution
After you have verified that the 2576 error is the only error that is reported by DBCC CHECKDB, you can use the DBCC CHECKDB command together with the REPAIR_ALLOW_DATA_LOSS option to remove the orphaned IAM page.
This repair process deallocates the orphaned IAM page and generates the following message:
Repair: The page (1:158) has been deallocated from object ID 0, index ID -1, partition ID 0, alloc unit ID 72057594039828480 (type Unknown).
More Information
Microsoft is investigating this problem. We will update this article when a fix is available. This specific problem does not represent actual database corruption. DBCC CHECKDB is reporting the presence of an orphaned IAM page that currently does not belong to any object. Therefore, this problem does not cause any data loss or actual data inconsistency.
