Article ID: 319357 - View products that this article applies to.
This article was previously published under Q319357
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 102199 (SQLBUG_70)
SQL Server 7.0 DBCC CHECKDB and DBCC CHECKALLOC do not report the following allocation inconsistencies:
8904 - Extent X in database ID Y is allocated by more than one allocation object.
8913 - Extent X is allocated to X and at least one other object.
During testing of this problem, the only situation in which 8904 and 8913 errors were reported involved a server that experienced hardware problems.
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 7.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
301511SQL Server 7.0 Service Pack 4 (SP4) contains new code that performs additional checks for Index Allocation Map (IAM) consistency. After you install SQL Server 7.0 SP4, DBCC CHECKDB and DBCC CHECKALLOC do report the 8904 and 8913 error messages.
(https://support.microsoft.com/kb/301511/EN-US/ )INF: How to Obtain the Latest SQL Server 7.0 Service Pack
DBCC CHECKDB and DBCC CHECKALLOC will report that REPAIR_ALLOW_DATA_LOSS is the minimum level of repair required to correct these errors.
If you have another server that is running a SQL Server 7.0 service pack that is earlier than SQL Server 7.0 SP4, you can backup and restore the database to that server, and then run DBCC CHECKDB. If DBCC CHECKDB on the restored database on the backup server does not report any errors and does not have any other signs of corruption or inconsistency, you can run DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS option on the original database that only reports the 8904 and/or 8913 errors with no risk of data loss.
If DBCC CHECKDB or DBCC CHECKALLOC reports any errors other than 8904 or 8913, then you must either restore from an earlier good clean backup, or run DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS option and accept the potential for data to be lost. For more information, see the "DBCC CHECKDB" topic in SQL Server Books Online.
Before you perform a repair with DBCC CHECKDB, always backup your database first. The backup serves as a fallback contingency plan in case any critical data is unexpectedly deleted by the repair action.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft SQL Server 7.0 Service Pack 4.