Inconsistencies Errors 8904 8913 8928 8906

Is there any possibility to correct such type of allocation problems without
data loss?
After correction with ALLOW_DATA_LOSS option, is there any tool to check for
referential integrity to discover witch records on witch tables disppeared
with deallocations?
Thanks you allI'm sorry, I searched in the newsgroup and I found in many cases there is
nothing to do even with the ALLOW_DATA_LOSS option (I still didn't try it).
For the moment I'm waiting for a CHECKTABLE REPAIR_REBUILD to end (it takes
hours...)
"Argo" wrote:

> Is there any possibility to correct such type of allocation problems witho
ut
> data loss?
> After correction with ALLOW_DATA_LOSS option, is there any tool to check f
or
> referential integrity to discover witch records on witch tables disppeared
> with deallocations?
> Thanks you all
>|||If DBCC reports that REPAIR_ALLOW_DATA_LOSS is the repair level required to
fix these errors, then a REPAIR_REBUILD will not completely remove the
problem. These are allocation errors, and will likely not be affected by a
REPAIR_REBUILD. Your best bet is always to restore from a backup. Do you
have one available?
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"Argo" <falk62@.yahoo.com> wrote in message
news:9BE9595C-FD19-4557-969D-F46B56985D36@.microsoft.com...[vbcol=seagreen]
> I'm sorry, I searched in the newsgroup and I found in many cases there is
> nothing to do even with the ALLOW_DATA_LOSS option (I still didn't try
> it).
> For the moment I'm waiting for a CHECKTABLE REPAIR_REBUILD to end (it
> takes
> hours...)
> "Argo" wrote:
>|||Regarding your question about checking constraints, the only tool in SQL
Server is DBCC CHECKCONSTRAINTS which will validate FOREIGN KEY and CHECK
constraints. There's nothing that will validate referential integrity
constraints.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:OCSCHmuCFHA.2608@.TK2MSFTNGP10.phx.gbl...
> If DBCC reports that REPAIR_ALLOW_DATA_LOSS is the repair level required
to
> fix these errors, then a REPAIR_REBUILD will not completely remove the
> problem. These are allocation errors, and will likely not be affected by
a
> REPAIR_REBUILD. Your best bet is always to restore from a backup. Do you
> have one available?
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Argo" <falk62@.yahoo.com> wrote in message
> news:9BE9595C-FD19-4557-969D-F46B56985D36@.microsoft.com...
is[vbcol=seagreen]
check[vbcol=seagreen]
>|||Now I executed CHECKTABLE repair_rebuild on all the three tables indicated b
y
the checkdb (they repaired all the inconsistencies). It has taken 10 hours
because the tables are very big. Now I started a CHECKDB repair_rebuild and
I
would like to show you the results without all the inconsistencies fixed by
the checktable commands.
The good backup should be of january 14 because the HW problem occurred on
15 but everything looked OK up to these days. (It is a SAP R/3 Production
System).
I think the possibility to reapply all the logs since then should be
avoided. In this period we had a tremendous activity on this system.(closing
of 2004 accounting)
Isn't it?
"Ryan Stonecipher [MSFT]" wrote:

> If DBCC reports that REPAIR_ALLOW_DATA_LOSS is the repair level required t
o
> fix these errors, then a REPAIR_REBUILD will not completely remove the
> problem. These are allocation errors, and will likely not be affected by
a
> REPAIR_REBUILD. Your best bet is always to restore from a backup. Do you
> have one available?
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Argo" <falk62@.yahoo.com> wrote in message
> news:9BE9595C-FD19-4557-969D-F46B56985D36@.microsoft.com...
>
>|||I analysed the CHECKDB log. There are 89 consistency errors that have been
fixed with the subsequent CHECKTABLE repair_rebuild commands. But there are
these 5 allocation errors:
Server: Msg 8904, Level 16, State 1, Line 1
Extent (3:1488776) in database ID 7 is allocated by more than one allocation
object.
Server: Msg 8913, Level 16, State 1, Line 1
Extent (3:1488776) is allocated to 'SGAM' and at least one other object.
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 0, index ID 0: Page (3:1488782) could not be processed. See other
errors for details.
Server: Msg 8913, Level 16, State 1, Line 1
Extent (3:1488776) is allocated to 'BSAD' and at least one other object.
Server: Msg 8906, Level 16, State 1, Line 1
Page (3:1488782) in database ID 7 is allocated in the SGAM (3:1022465) and
PFS (3:1488192), but was not allocated in any IAM. PFS flags 'IAM_PG
MIXED_EXT ALLOCATED 0_PCT_FULL'.
they all relate to just one extent and one page as I can see. Does the
allow_data_loss level eliminates the problem? In this case I have lost 9
pages of data (8+1=72K)?
Thank you all for your help
p.s. I'm testing the checkconstraints behaviour
"Ryan Stonecipher [MSFT]" wrote:

> If DBCC reports that REPAIR_ALLOW_DATA_LOSS is the repair level required t
o
> fix these errors, then a REPAIR_REBUILD will not completely remove the
> problem. These are allocation errors, and will likely not be affected by
a
> REPAIR_REBUILD. Your best bet is always to restore from a backup. Do you
> have one available?
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Argo" <falk62@.yahoo.com> wrote in message
> news:9BE9595C-FD19-4557-969D-F46B56985D36@.microsoft.com...
>
>