check sql licence: allocation

Showing posts with label allocation. Show all posts

Thursday, March 8, 2012

checktable error

I receive the following after running checktable:
CHECKTABLE found 0 allocation errors and 2 consistency errors in table
'RequestWords' (object ID 910678342).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (synergy.dbo.RequestWords ).
I have a backup and would like to know the best way to proceed to correct
the consistency errors...also where can I find the sp_repair_allow_data_loss?
Thanks> I have a backup and would like to know the best way to proceed to correct
> the consistency errors...also where can I find the
> sp_repair_allow_data_loss?
Restoring from your last known good backup is usually the best option rather
than allowing data loss. There may be other methods depending on the
specific types of corruption and affected object types.
REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC CHECKTABLE
commands. See the Books online for details.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>I receive the following after running checktable:
> CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> 'RequestWords' (object ID 910678342).
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> I have a backup and would like to know the best way to proceed to correct
> the consistency errors...also where can I find the
> sp_repair_allow_data_loss?
> Thanks|||Not sure when my last known good is and it could take quite awhile to try and
find it...is there a way to see what data would be lost first before running
REPAIR_ALLOW_DATA_LOSS ?
"Dan Guzman" wrote:
> > I have a backup and would like to know the best way to proceed to correct
> > the consistency errors...also where can I find the
> > sp_repair_allow_data_loss?
> Restoring from your last known good backup is usually the best option rather
> than allowing data loss. There may be other methods depending on the
> specific types of corruption and affected object types.
> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC CHECKTABLE
> commands. See the Books online for details.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >I receive the following after running checktable:
> >
> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> > 'RequestWords' (object ID 910678342).
> > repair_allow_data_loss is the minimum repair level for the errors found by
> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >
> > I have a backup and would like to know the best way to proceed to correct
> > the consistency errors...also where can I find the
> > sp_repair_allow_data_loss?
> >
> > Thanks
>|||> Not sure when my last known good is and it could take quite awhile to try
> and
> find it...is there a way to see what data would be lost first before
> running
> REPAIR_ALLOW_DATA_LOSS ?
The DBCC CHECKTABLE output should specify the problem pages and error
details. You can use DBCC PAGE (google is your friend) to examine the page
contents and get an idea of data might be affected. I don't believe it's
possible to provide exact details of lost data beforehand; I would think
DBCC could recover the data without loss if that were possible.
You might try posting the DBCC error details in case we can provide an
alternate solution. You could also try running the DBCC CHECKTABLE WITH
REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
the problem and identify lost data.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> Not sure when my last known good is and it could take quite awhile to try
> and
> find it...is there a way to see what data would be lost first before
> running
> REPAIR_ALLOW_DATA_LOSS ?
> "Dan Guzman" wrote:
>> > I have a backup and would like to know the best way to proceed to
>> > correct
>> > the consistency errors...also where can I find the
>> > sp_repair_allow_data_loss?
>> Restoring from your last known good backup is usually the best option
>> rather
>> than allowing data loss. There may be other methods depending on the
>> specific types of corruption and affected object types.
>> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> CHECKTABLE
>> commands. See the Books online for details.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >I receive the following after running checktable:
>> >
>> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
>> > 'RequestWords' (object ID 910678342).
>> > repair_allow_data_loss is the minimum repair level for the errors found
>> > by
>> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >
>> > I have a backup and would like to know the best way to proceed to
>> > correct
>> > the consistency errors...also where can I find the
>> > sp_repair_allow_data_loss?
>> >
>> > Thanks|||Dan, I am going to paste the following detail, the table is a simple 2 column
that is used by a full text indexing job, it seems, the first field is just
text and the second is a guid...I went to record 128, but saw nothing
funny.....appreciate all your help
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 910678342, index ID 0: Page (1:369538) could not be processed. See
other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 910678342, index ID 0, page (1:369538), row 125. Test
(ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
DBCC results for 'RequestWords'.
There are 1313272 rows in 11072 pages for object 'RequestWords'.
CHECKTABLE found 0 allocation errors and 2 consistency errors in table
'RequestWords' (object ID 910678342).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (synergy.dbo.RequestWords ).
"Dan Guzman" wrote:
> > Not sure when my last known good is and it could take quite awhile to try
> > and
> > find it...is there a way to see what data would be lost first before
> > running
> > REPAIR_ALLOW_DATA_LOSS ?
> The DBCC CHECKTABLE output should specify the problem pages and error
> details. You can use DBCC PAGE (google is your friend) to examine the page
> contents and get an idea of data might be affected. I don't believe it's
> possible to provide exact details of lost data beforehand; I would think
> DBCC could recover the data without loss if that were possible.
> You might try posting the DBCC error details in case we can provide an
> alternate solution. You could also try running the DBCC CHECKTABLE WITH
> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
> the problem and identify lost data.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> > Not sure when my last known good is and it could take quite awhile to try
> > and
> > find it...is there a way to see what data would be lost first before
> > running
> > REPAIR_ALLOW_DATA_LOSS ?
> >
> > "Dan Guzman" wrote:
> >
> >> > I have a backup and would like to know the best way to proceed to
> >> > correct
> >> > the consistency errors...also where can I find the
> >> > sp_repair_allow_data_loss?
> >>
> >> Restoring from your last known good backup is usually the best option
> >> rather
> >> than allowing data loss. There may be other methods depending on the
> >> specific types of corruption and affected object types.
> >>
> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
> >> CHECKTABLE
> >> commands. See the Books online for details.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >> >I receive the following after running checktable:
> >> >
> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> >> > 'RequestWords' (object ID 910678342).
> >> > repair_allow_data_loss is the minimum repair level for the errors found
> >> > by
> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >> >
> >> > I have a backup and would like to know the best way to proceed to
> >> > correct
> >> > the consistency errors...also where can I find the
> >> > sp_repair_allow_data_loss?
> >> >
> >> > Thanks
> >>
>|||The DBCC error indicates bad column offsets, which will prevent the problem
row from being parsed. I think DBCC will need to delete that row to remove
the error. You can probably fix the error with a normal delete command if
you can identify the key value of the problem row from the raw DBCC PAGE
output.
If you haven't already done so, you might try DBCC PAGE print option 3
(http://support.microsoft.com/kb/83065) to print the individual column
values (example below). I don't know how this will behave with bad column
offsets but I'm curious to find out, if you don't mind giving that a try.
The DBCC PAGE dump is probably the only data you'll have to salvage the
deleted row, unless you contact Microsoft PSS.
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
> Dan, I am going to paste the following detail, the table is a simple 2
> column
> that is used by a full text indexing job, it seems, the first field is
> just
> text and the second is a guid...I went to record 128, but saw nothing
> funny.....appreciate all your help
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 910678342, index ID 0: Page (1:369538) could not be processed.
> See
> other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
> Test
> (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
> DBCC results for 'RequestWords'.
> There are 1313272 rows in 11072 pages for object 'RequestWords'.
> CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> 'RequestWords' (object ID 910678342).
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>
>
> "Dan Guzman" wrote:
>> > Not sure when my last known good is and it could take quite awhile to
>> > try
>> > and
>> > find it...is there a way to see what data would be lost first before
>> > running
>> > REPAIR_ALLOW_DATA_LOSS ?
>> The DBCC CHECKTABLE output should specify the problem pages and error
>> details. You can use DBCC PAGE (google is your friend) to examine the
>> page
>> contents and get an idea of data might be affected. I don't believe it's
>> possible to provide exact details of lost data beforehand; I would think
>> DBCC could recover the data without loss if that were possible.
>> You might try posting the DBCC error details in case we can provide an
>> alternate solution. You could also try running the DBCC CHECKTABLE WITH
>> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
>> the problem and identify lost data.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
>> > Not sure when my last known good is and it could take quite awhile to
>> > try
>> > and
>> > find it...is there a way to see what data would be lost first before
>> > running
>> > REPAIR_ALLOW_DATA_LOSS ?
>> >
>> > "Dan Guzman" wrote:
>> >
>> >> > I have a backup and would like to know the best way to proceed to
>> >> > correct
>> >> > the consistency errors...also where can I find the
>> >> > sp_repair_allow_data_loss?
>> >>
>> >> Restoring from your last known good backup is usually the best option
>> >> rather
>> >> than allowing data loss. There may be other methods depending on the
>> >> specific types of corruption and affected object types.
>> >>
>> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> >> CHECKTABLE
>> >> commands. See the Books online for details.
>> >>
>> >> --
>> >> Hope this helps.
>> >>
>> >> Dan Guzman
>> >> SQL Server MVP
>> >>
>> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >> >I receive the following after running checktable:
>> >> >
>> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
>> >> > table
>> >> > 'RequestWords' (object ID 910678342).
>> >> > repair_allow_data_loss is the minimum repair level for the errors
>> >> > found
>> >> > by
>> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >> >
>> >> > I have a backup and would like to know the best way to proceed to
>> >> > correct
>> >> > the consistency errors...also where can I find the
>> >> > sp_repair_allow_data_loss?
>> >> >
>> >> > Thanks
>> >>|||Dan, sorry took so long to get back...
I was able to locate the corrupt record in the referenced table...it was a
null id that had a guid assigned to it from another table...very weird...the
delete statement would not work on it....had to finally run
repair_allow_data_loss and then repair_fast. I lost 132 records but they
were all bogus references to the corruption...so it turned out all good.
Thanks for your assistance.
"Dan Guzman" wrote:
> The DBCC error indicates bad column offsets, which will prevent the problem
> row from being parsed. I think DBCC will need to delete that row to remove
> the error. You can probably fix the error with a normal delete command if
> you can identify the key value of the problem row from the raw DBCC PAGE
> output.
> If you haven't already done so, you might try DBCC PAGE print option 3
> (http://support.microsoft.com/kb/83065) to print the individual column
> values (example below). I don't know how this will behave with bad column
> offsets but I'm curious to find out, if you don't mind giving that a try.
> The DBCC PAGE dump is probably the only data you'll have to salvage the
> deleted row, unless you contact Microsoft PSS.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
> > Dan, I am going to paste the following detail, the table is a simple 2
> > column
> > that is used by a full text indexing job, it seems, the first field is
> > just
> > text and the second is a guid...I went to record 128, but saw nothing
> > funny.....appreciate all your help
> >
> > Server: Msg 8928, Level 16, State 1, Line 1
> > Object ID 910678342, index ID 0: Page (1:369538) could not be processed.
> > See
> > other errors for details.
> > Server: Msg 8944, Level 16, State 1, Line 1
> > Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
> > Test
> > (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
> > DBCC results for 'RequestWords'.
> > There are 1313272 rows in 11072 pages for object 'RequestWords'.
> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> > 'RequestWords' (object ID 910678342).
> > repair_allow_data_loss is the minimum repair level for the errors found by
> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >
> >
> >
> >
> > "Dan Guzman" wrote:
> >
> >> > Not sure when my last known good is and it could take quite awhile to
> >> > try
> >> > and
> >> > find it...is there a way to see what data would be lost first before
> >> > running
> >> > REPAIR_ALLOW_DATA_LOSS ?
> >>
> >> The DBCC CHECKTABLE output should specify the problem pages and error
> >> details. You can use DBCC PAGE (google is your friend) to examine the
> >> page
> >> contents and get an idea of data might be affected. I don't believe it's
> >> possible to provide exact details of lost data beforehand; I would think
> >> DBCC could recover the data without loss if that were possible.
> >>
> >> You might try posting the DBCC error details in case we can provide an
> >> alternate solution. You could also try running the DBCC CHECKTABLE WITH
> >> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
> >> the problem and identify lost data.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> >> > Not sure when my last known good is and it could take quite awhile to
> >> > try
> >> > and
> >> > find it...is there a way to see what data would be lost first before
> >> > running
> >> > REPAIR_ALLOW_DATA_LOSS ?
> >> >
> >> > "Dan Guzman" wrote:
> >> >
> >> >> > I have a backup and would like to know the best way to proceed to
> >> >> > correct
> >> >> > the consistency errors...also where can I find the
> >> >> > sp_repair_allow_data_loss?
> >> >>
> >> >> Restoring from your last known good backup is usually the best option
> >> >> rather
> >> >> than allowing data loss. There may be other methods depending on the
> >> >> specific types of corruption and affected object types.
> >> >>
> >> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
> >> >> CHECKTABLE
> >> >> commands. See the Books online for details.
> >> >>
> >> >> --
> >> >> Hope this helps.
> >> >>
> >> >> Dan Guzman
> >> >> SQL Server MVP
> >> >>
> >> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >> >> >I receive the following after running checktable:
> >> >> >
> >> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
> >> >> > table
> >> >> > 'RequestWords' (object ID 910678342).
> >> >> > repair_allow_data_loss is the minimum repair level for the errors
> >> >> > found
> >> >> > by
> >> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >> >> >
> >> >> > I have a backup and would like to know the best way to proceed to
> >> >> > correct
> >> >> > the consistency errors...also where can I find the
> >> >> > sp_repair_allow_data_loss?
> >> >> >
> >> >> > Thanks
> >> >>
> >>
>|||I'm glad you were able to get your database fixed.
--
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:8525A1AF-4A88-47B3-AA8F-1144B9814DA8@.microsoft.com...
> Dan, sorry took so long to get back...
> I was able to locate the corrupt record in the referenced table...it was
> a
> null id that had a guid assigned to it from another table...very
> weird...the
> delete statement would not work on it....had to finally run
> repair_allow_data_loss and then repair_fast. I lost 132 records but they
> were all bogus references to the corruption...so it turned out all good.
> Thanks for your assistance.
> "Dan Guzman" wrote:
>> The DBCC error indicates bad column offsets, which will prevent the
>> problem
>> row from being parsed. I think DBCC will need to delete that row to
>> remove
>> the error. You can probably fix the error with a normal delete command
>> if
>> you can identify the key value of the problem row from the raw DBCC PAGE
>> output.
>> If you haven't already done so, you might try DBCC PAGE print option 3
>> (http://support.microsoft.com/kb/83065) to print the individual column
>> values (example below). I don't know how this will behave with bad
>> column
>> offsets but I'm curious to find out, if you don't mind giving that a try.
>> The DBCC PAGE dump is probably the only data you'll have to salvage the
>> deleted row, unless you contact Microsoft PSS.
>>
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
>> > Dan, I am going to paste the following detail, the table is a simple 2
>> > column
>> > that is used by a full text indexing job, it seems, the first field is
>> > just
>> > text and the second is a guid...I went to record 128, but saw nothing
>> > funny.....appreciate all your help
>> >
>> > Server: Msg 8928, Level 16, State 1, Line 1
>> > Object ID 910678342, index ID 0: Page (1:369538) could not be
>> > processed.
>> > See
>> > other errors for details.
>> > Server: Msg 8944, Level 16, State 1, Line 1
>> > Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
>> > Test
>> > (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
>> > DBCC results for 'RequestWords'.
>> > There are 1313272 rows in 11072 pages for object 'RequestWords'.
>> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
>> > 'RequestWords' (object ID 910678342).
>> > repair_allow_data_loss is the minimum repair level for the errors found
>> > by
>> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >
>> >
>> >
>> >
>> > "Dan Guzman" wrote:
>> >
>> >> > Not sure when my last known good is and it could take quite awhile
>> >> > to
>> >> > try
>> >> > and
>> >> > find it...is there a way to see what data would be lost first before
>> >> > running
>> >> > REPAIR_ALLOW_DATA_LOSS ?
>> >>
>> >> The DBCC CHECKTABLE output should specify the problem pages and error
>> >> details. You can use DBCC PAGE (google is your friend) to examine the
>> >> page
>> >> contents and get an idea of data might be affected. I don't believe
>> >> it's
>> >> possible to provide exact details of lost data beforehand; I would
>> >> think
>> >> DBCC could recover the data without loss if that were possible.
>> >>
>> >> You might try posting the DBCC error details in case we can provide an
>> >> alternate solution. You could also try running the DBCC CHECKTABLE
>> >> WITH
>> >> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to
>> >> correct
>> >> the problem and identify lost data.
>> >>
>> >> --
>> >> Hope this helps.
>> >>
>> >> Dan Guzman
>> >> SQL Server MVP
>> >>
>> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
>> >> > Not sure when my last known good is and it could take quite awhile
>> >> > to
>> >> > try
>> >> > and
>> >> > find it...is there a way to see what data would be lost first before
>> >> > running
>> >> > REPAIR_ALLOW_DATA_LOSS ?
>> >> >
>> >> > "Dan Guzman" wrote:
>> >> >
>> >> >> > I have a backup and would like to know the best way to proceed to
>> >> >> > correct
>> >> >> > the consistency errors...also where can I find the
>> >> >> > sp_repair_allow_data_loss?
>> >> >>
>> >> >> Restoring from your last known good backup is usually the best
>> >> >> option
>> >> >> rather
>> >> >> than allowing data loss. There may be other methods depending on
>> >> >> the
>> >> >> specific types of corruption and affected object types.
>> >> >>
>> >> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> >> >> CHECKTABLE
>> >> >> commands. See the Books online for details.
>> >> >>
>> >> >> --
>> >> >> Hope this helps.
>> >> >>
>> >> >> Dan Guzman
>> >> >> SQL Server MVP
>> >> >>
>> >> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >> >> >I receive the following after running checktable:
>> >> >> >
>> >> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
>> >> >> > table
>> >> >> > 'RequestWords' (object ID 910678342).
>> >> >> > repair_allow_data_loss is the minimum repair level for the errors
>> >> >> > found
>> >> >> > by
>> >> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >> >> >
>> >> >> > I have a backup and would like to know the best way to proceed to
>> >> >> > correct
>> >> >> > the consistency errors...also where can I find the
>> >> >> > sp_repair_allow_data_loss?
>> >> >> >
>> >> >> > Thanks
>> >> >>
>> >>

Tuesday, February 14, 2012

CHECKDB found 0 allocation errors and 2 consistency errors in data

Hi,
SQL 2000, SP4
Getting CHECKDB found 0 allocation errors and 2 consistency errors in
database after running dbcc checkdb:
Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState' (ID
327672215) (index ID 2). Extra or invalid key for the keys:
Server: Msg 8956, Level 16, State 1, Line 1
Index row (1:677:2) with values (Id = 3 and ServerConfigId = 0 and Type = 'DevMgmtServerConfigHistoryId') points to the data row identified by ().
Also seeing in SQL error log:
Could not find the index entry for RID
'3600000000020000010044004400650076004d0067006d00740053006500720076006500720043006f006e00660069006700' in index page (1:152369),
help would be apperciated
thxTry rebuilding those indexes and you should be fine as they are
nonclustered.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"stoney" <stoney@.discussions.microsoft.com> wrote in message
news:388A8392-1139-4315-9911-38607DB51AD6@.microsoft.com...
> Hi,
> SQL 2000, SP4
> Getting CHECKDB found 0 allocation errors and 2 consistency errors in
> database after running dbcc checkdb:
> Server: Msg 8952, Level 16, State 1, Line 1
> Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState'
> (ID
> 327672215) (index ID 2). Extra or invalid key for the keys:
> Server: Msg 8956, Level 16, State 1, Line 1
> Index row (1:677:2) with values (Id = 3 and ServerConfigId = 0 and Type => 'DevMgmtServerConfigHistoryId') points to the data row identified by ().
> Also seeing in SQL error log:
> Could not find the index entry for RID
> '3600000000020000010044004400650076004d0067006d00740053006500720076006500720043006f006e00660069006700'
> in index page (1:152369),
> help would be apperciated
> thx|||Hi,
I am looking at manage index window and it says that it is Clustered,
"stoney" wrote:
> Hi,
> SQL 2000, SP4
> Getting CHECKDB found 0 allocation errors and 2 consistency errors in
> database after running dbcc checkdb:
> Server: Msg 8952, Level 16, State 1, Line 1
> Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState' (ID
> 327672215) (index ID 2). Extra or invalid key for the keys:
> Server: Msg 8956, Level 16, State 1, Line 1
> Index row (1:677:2) with values (Id = 3 and ServerConfigId = 0 and Type => 'DevMgmtServerConfigHistoryId') points to the data row identified by ().
> Also seeing in SQL error log:
> Could not find the index entry for RID
> '3600000000020000010044004400650076004d0067006d00740053006500720076006500720043006f006e00660069006700' in index page (1:152369),
> help would be apperciated
> thx|||This definately says the index ID is 2. The index ID has to be 1 for it to
be a clustered index.
Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState' (ID
327672215) (index ID 2). Extra or invalid key for the keys:
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"stoney" <stoney@.discussions.microsoft.com> wrote in message
news:B4EE6885-40EE-4842-9188-F02B61CCEE38@.microsoft.com...
> Hi,
> I am looking at manage index window and it says that it is Clustered,
> "stoney" wrote:
>> Hi,
>> SQL 2000, SP4
>> Getting CHECKDB found 0 allocation errors and 2 consistency errors in
>> database after running dbcc checkdb:
>> Server: Msg 8952, Level 16, State 1, Line 1
>> Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState'
>> (ID
>> 327672215) (index ID 2). Extra or invalid key for the keys:
>> Server: Msg 8956, Level 16, State 1, Line 1
>> Index row (1:677:2) with values (Id = 3 and ServerConfigId = 0 and Type =>> 'DevMgmtServerConfigHistoryId') points to the data row identified by ().
>> Also seeing in SQL error log:
>> Could not find the index entry for RID
>> '3600000000020000010044004400650076004d0067006d00740053006500720076006500720043006f006e00660069006700'
>> in index page (1:152369),
>> help would be apperciated
>> thx|||thx Andrew, I have rebuilt the index and all seems to be working fine.
Allthough I see in the errorlog 'Skipping startup of clean database id 5' and
that is the id of the db that I rebuilt the inex on.
Any thoughts
"Andrew J. Kelly" wrote:
> Try rebuilding those indexes and you should be fine as they are
> nonclustered.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "stoney" <stoney@.discussions.microsoft.com> wrote in message
> news:388A8392-1139-4315-9911-38607DB51AD6@.microsoft.com...
> > Hi,
> >
> > SQL 2000, SP4
> > Getting CHECKDB found 0 allocation errors and 2 consistency errors in
> > database after running dbcc checkdb:
> >
> > Server: Msg 8952, Level 16, State 1, Line 1
> > Table error: Database 'abc', index 'SyncServerState.PK_SyncServerState'
> > (ID
> > 327672215) (index ID 2). Extra or invalid key for the keys:
> >
> > Server: Msg 8956, Level 16, State 1, Line 1
> > Index row (1:677:2) with values (Id = 3 and ServerConfigId = 0 and Type => > 'DevMgmtServerConfigHistoryId') points to the data row identified by ().
> >
> > Also seeing in SQL error log:
> >
> > Could not find the index entry for RID
> > '3600000000020000010044004400650076004d0067006d00740053006500720076006500720043006f006e00660069006700'
> > in index page (1:152369),
> >
> > help would be apperciated
> >
> > thx
>

CHECKDB allocation error

Hello all,
I've got this error as result of CHECKDB command:
CHECKDB found 1 allocation errors and 4 consistency errors in database
'Data'.
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKDB (Data ).
It looks like the CHECKDB with repair_allow_data_loss can solve the problem.
Is there any way to know beforehand, what data will be lost?
Thanks,
petiHi Peti
It would be useful to see the exact errors, but you may want to look at DBCC
PAGE, googling for "DBCC CHECKDB" AND "DBCC PAGE" comes up with quite a few
results including http://tinyurl.com/y9rk25 and http://tinyurl.com/yjabup
Reading "Inside SQL Server 2000" by Kalen Delany ISBN 0-7356-0998-5 and "The
Guru's Guide to Transact-SQL" by Ken Henderson ISBN 0-201-61576-2 will give
you useful information on these as well.
John
"peti" wrote:
> Hello all,
> I've got this error as result of CHECKDB command:
> CHECKDB found 1 allocation errors and 4 consistency errors in database
> 'Data'.
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKDB (Data ).
> It looks like the CHECKDB with repair_allow_data_loss can solve the problem.
> Is there any way to know beforehand, what data will be lost?
> Thanks,
> peti
>
>|||Thank you John,
I've read those posts but I'm still confused - for the error 8981, if the
dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what data is
missing?
DBCC CHECKDB outcome:
DBCC results for 'conflict_edu_Script_tab'.
Server: Msg 8979, Level 16, State 1, Line 1
Table error: Object ID 772614241, index ID 1. Page (1:482455) is missing
references from parent (unknown) and previous (page (1:482777)) nodes.
Possible bad root entry in sysindexes.
There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
...................
DBCC results for 'cse_CaseFolder_tab'.
Server: Msg 8981, Level 16, State 1, Line 1
Table error: Object ID 772614241, index ID 1. The next pointer of (1:482455)
refers to page (1:482776). Neither (1:482776) nor its parent were
encountered. Possible bad chain linkage.
Server: Msg 8981, Level 16, State 1, Line 1
Table error: Object ID 772614241, index ID 1. The next pointer of (1:493336)
refers to page (1:482778). Neither (1:482778) nor its parent were
encountered. Possible bad chain linkage.
There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
CHECKDB found 0 allocation errors and 3 consistency errors in table
'cse_Case_tab' (object ID 772614241).
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
..........
There are 29 rows in 1 pages for object 'cse_Note_tab'.
Server: Msg 8952, Level 16, State 1, Line 1
Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
1520633106) (index ID 7). Extra or invalid key for the keys:
Server: Msg 8956, Level 16, State 1, Line 1
Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId = 1
and CFId = 1049716 and CaseId = 1) points to the data row identified by ().
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
/peti
"peti" <bpetigaspar@.gmail.com> wrote in message
news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> Hello all,
> I've got this error as result of CHECKDB command:
> CHECKDB found 1 allocation errors and 4 consistency errors in database
> 'Data'.
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKDB (Data ).
> It looks like the CHECKDB with repair_allow_data_loss can solve the
problem.
> Is there any way to know beforehand, what data will be lost?
> Thanks,
> peti
>|||Hi Peti
If there are a large number of errors the most likely cause would be a
hardware fault you would first need to eliminate what caused it before trying
to repair the database. You can always drop and re-create indexes to try and
remove any inconsistencies, what does the NOINDEX option for CHECKDB return?
John
"peti" wrote:
> Thank you John,
> I've read those posts but I'm still confused - for the error 8981, if the
> dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what data is
> missing?
> DBCC CHECKDB outcome:
>
> DBCC results for 'conflict_edu_Script_tab'.
> Server: Msg 8979, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. Page (1:482455) is missing
> references from parent (unknown) and previous (page (1:482777)) nodes.
> Possible bad root entry in sysindexes.
> There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
> http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
> ...................
> DBCC results for 'cse_CaseFolder_tab'.
> Server: Msg 8981, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. The next pointer of (1:482455)
> refers to page (1:482776). Neither (1:482776) nor its parent were
> encountered. Possible bad chain linkage.
> Server: Msg 8981, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. The next pointer of (1:493336)
> refers to page (1:482778). Neither (1:482778) nor its parent were
> encountered. Possible bad chain linkage.
> There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
> CHECKDB found 0 allocation errors and 3 consistency errors in table
> 'cse_Case_tab' (object ID 772614241).
> http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
> ...........
> There are 29 rows in 1 pages for object 'cse_Note_tab'.
> Server: Msg 8952, Level 16, State 1, Line 1
> Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
> 1520633106) (index ID 7). Extra or invalid key for the keys:
> Server: Msg 8956, Level 16, State 1, Line 1
> Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId = 1
> and CFId = 1049716 and CaseId = 1) points to the data row identified by ().
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
> /peti
>
>
> "peti" <bpetigaspar@.gmail.com> wrote in message
> news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> > Hello all,
> >
> > I've got this error as result of CHECKDB command:
> >
> > CHECKDB found 1 allocation errors and 4 consistency errors in database
> > 'Data'.
> > repair_allow_data_loss is the minimum repair level for the errors found by
> > DBCC CHECKDB (Data ).
> >
> > It looks like the CHECKDB with repair_allow_data_loss can solve the
> problem.
> > Is there any way to know beforehand, what data will be lost?
> >
> > Thanks,
> > peti
> >
> >
>
>|||It was a power failure.
In my case the clustered index is corupt (Object ID 772614241, index ID 1).
Does it mean data loss?
What means data loss - only one row or the entire table?
/peti
"peti" <bpetigaspar@.gmail.com> wrote in message
news:eh5qb1$s3r$1@.news.al.sw.ericsson.se...
> Thank you John,
> I've read those posts but I'm still confused - for the error 8981, if the
> dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what data
is
> missing?
> DBCC CHECKDB outcome:
>
> DBCC results for 'conflict_edu_Script_tab'.
> Server: Msg 8979, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. Page (1:482455) is missing
> references from parent (unknown) and previous (page (1:482777)) nodes.
> Possible bad root entry in sysindexes.
> There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
> http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
> ...................
> DBCC results for 'cse_CaseFolder_tab'.
> Server: Msg 8981, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. The next pointer of
(1:482455)
> refers to page (1:482776). Neither (1:482776) nor its parent were
> encountered. Possible bad chain linkage.
> Server: Msg 8981, Level 16, State 1, Line 1
> Table error: Object ID 772614241, index ID 1. The next pointer of
(1:493336)
> refers to page (1:482778). Neither (1:482778) nor its parent were
> encountered. Possible bad chain linkage.
> There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
> CHECKDB found 0 allocation errors and 3 consistency errors in table
> 'cse_Case_tab' (object ID 772614241).
> http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
> ..........
> There are 29 rows in 1 pages for object 'cse_Note_tab'.
> Server: Msg 8952, Level 16, State 1, Line 1
> Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
> 1520633106) (index ID 7). Extra or invalid key for the keys:
> Server: Msg 8956, Level 16, State 1, Line 1
> Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId = 1
> and CFId = 1049716 and CaseId = 1) points to the data row identified by
().
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
> /peti
>
>
> "peti" <bpetigaspar@.gmail.com> wrote in message
> news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> > Hello all,
> >
> > I've got this error as result of CHECKDB command:
> >
> > CHECKDB found 1 allocation errors and 4 consistency errors in database
> > 'Data'.
> > repair_allow_data_loss is the minimum repair level for the errors found
by
> > DBCC CHECKDB (Data ).
> >
> > It looks like the CHECKDB with repair_allow_data_loss can solve the
> problem.
> > Is there any way to know beforehand, what data will be lost?
> >
> > Thanks,
> > peti
> >
> >
>|||Hi
The index page is missing it's parent reference it does not necessarily mean
that it contains data. Examples of the syntax and using DBCC PAGE can be
found at http://www.sql-server-performance.com/dbcc_commands.asp and
http://www.sql-server-performance.com/gv_index_data_structures.asp. I assume
that you are persuing this route because you don't have a good backup that
you can roll forward? make sure you backup before correcting the database,
and you may want to compare what you have against the last good backup you
have with something like SQL Data Compare from Red Gate www.red-gate.com, or
compare the pre-repared database to the post-repaired database (which may
only confirm that you have already lost the data!).
John
"peti" wrote:
> It was a power failure.
> In my case the clustered index is corupt (Object ID 772614241, index ID 1).
> Does it mean data loss?
> What means data loss - only one row or the entire table?
> /peti
> "peti" <bpetigaspar@.gmail.com> wrote in message
> news:eh5qb1$s3r$1@.news.al.sw.ericsson.se...
> > Thank you John,
> >
> > I've read those posts but I'm still confused - for the error 8981, if the
> > dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what data
> is
> > missing?
> >
> > DBCC CHECKDB outcome:
> >
> >
> >
> > DBCC results for 'conflict_edu_Script_tab'.
> > Server: Msg 8979, Level 16, State 1, Line 1
> > Table error: Object ID 772614241, index ID 1. Page (1:482455) is missing
> > references from parent (unknown) and previous (page (1:482777)) nodes.
> > Possible bad root entry in sysindexes.
> > There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
> > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
> >
> > ...................
> >
> > DBCC results for 'cse_CaseFolder_tab'.
> > Server: Msg 8981, Level 16, State 1, Line 1
> > Table error: Object ID 772614241, index ID 1. The next pointer of
> (1:482455)
> > refers to page (1:482776). Neither (1:482776) nor its parent were
> > encountered. Possible bad chain linkage.
> > Server: Msg 8981, Level 16, State 1, Line 1
> > Table error: Object ID 772614241, index ID 1. The next pointer of
> (1:493336)
> > refers to page (1:482778). Neither (1:482778) nor its parent were
> > encountered. Possible bad chain linkage.
> > There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
> > CHECKDB found 0 allocation errors and 3 consistency errors in table
> > 'cse_Case_tab' (object ID 772614241).
> >
> > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
> >
> > ..........
> >
> > There are 29 rows in 1 pages for object 'cse_Note_tab'.
> > Server: Msg 8952, Level 16, State 1, Line 1
> > Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
> > 1520633106) (index ID 7). Extra or invalid key for the keys:
> > Server: Msg 8956, Level 16, State 1, Line 1
> > Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId = 1
> > and CFId = 1049716 and CaseId = 1) points to the data row identified by
> ().
> >
> >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
> >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
> >
> > /peti
> >
> >
> >
> >
> >
> > "peti" <bpetigaspar@.gmail.com> wrote in message
> > news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> > > Hello all,
> > >
> > > I've got this error as result of CHECKDB command:
> > >
> > > CHECKDB found 1 allocation errors and 4 consistency errors in database
> > > 'Data'.
> > > repair_allow_data_loss is the minimum repair level for the errors found
> by
> > > DBCC CHECKDB (Data ).
> > >
> > > It looks like the CHECKDB with repair_allow_data_loss can solve the
> > problem.
> > > Is there any way to know beforehand, what data will be lost?
> > >
> > > Thanks,
> > > peti
> > >
> > >
> >
> >
>
>|||Hello John,
This is the result of DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS :
......
CHECKDB found 1 allocation errors and 6 consistency errors in database
'Data'.
CHECKDB fixed 1 allocation errors and 6 consistency errors in database
'Data'.
.......
Then, the CHECKDB command reported only consistency errors:
.........
Server: Msg 8951, Level 16, State 1, Line 1
Table error: Table 'cse_Case_tab' (ID 1520633106). Missing or invalid
key in index 'cse_Case_ind7' (ID 7) for the row:
Server: Msg 8955, Level 16, State 1, Line 1
Data row (1:401723:0) identified by (RID = (1:401723:0) CenterId = 1 and
CaseFolderId = 1049723 and CaseId = 1) has index values (CaseTypeId = 10 and
ToCaseTypeArea = ').
CHECKDB found 0 allocation errors and 4 consistency errors in table
'cse_Case_tab' (object ID 1520633106).
CHECKDB found 0 allocation errors and 4 consistency errors in database
'Data'.
repair_fast is the minimum repair level for the errors found by DBCC
CHECKDB (Data ).
........
Repair fast didn't solved the consistency errors so I run DBCC DBREINDEX
against cse_Case_ind7 index. Then CHECKDB reported no errors.
Red Gate still reports "differences" between databases. Some rows are
reported as being only in the old DB but the same number of rows with the
same content are reported as being present only in the new DB. So the same
data is logically in both databases. I consider this no problem!?
The transactional replication is still in place. Should I stop the
replication before DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS ? I suppose yes
because of single user mode requirement.
regards,
peti
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:CB6FA2CE-02D0-4095-8DF7-B7ED410D7FEE@.microsoft.com...
> Hi
> The index page is missing it's parent reference it does not necessarily
mean
> that it contains data. Examples of the syntax and using DBCC PAGE can be
> found at http://www.sql-server-performance.com/dbcc_commands.asp and
> http://www.sql-server-performance.com/gv_index_data_structures.asp. I
assume
> that you are persuing this route because you don't have a good backup that
> you can roll forward? make sure you backup before correcting the database,
> and you may want to compare what you have against the last good backup you
> have with something like SQL Data Compare from Red Gate www.red-gate.com,
or
> compare the pre-repared database to the post-repaired database (which may
> only confirm that you have already lost the data!).
> John
> "peti" wrote:
> > It was a power failure.
> >
> > In my case the clustered index is corupt (Object ID 772614241, index ID
1).
> > Does it mean data loss?
> >
> > What means data loss - only one row or the entire table?
> >
> > /peti
> >
> > "peti" <bpetigaspar@.gmail.com> wrote in message
> > news:eh5qb1$s3r$1@.news.al.sw.ericsson.se...
> > > Thank you John,
> > >
> > > I've read those posts but I'm still confused - for the error 8981, if
the
> > > dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what
data
> > is
> > > missing?
> > >
> > > DBCC CHECKDB outcome:
> > >
> > >
> > >
> > > DBCC results for 'conflict_edu_Script_tab'.
> > > Server: Msg 8979, Level 16, State 1, Line 1
> > > Table error: Object ID 772614241, index ID 1. Page (1:482455) is
missing
> > > references from parent (unknown) and previous (page (1:482777)) nodes.
> > > Possible bad root entry in sysindexes.
> > > There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
> > > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
> > >
> > > ...................
> > >
> > > DBCC results for 'cse_CaseFolder_tab'.
> > > Server: Msg 8981, Level 16, State 1, Line 1
> > > Table error: Object ID 772614241, index ID 1. The next pointer of
> > (1:482455)
> > > refers to page (1:482776). Neither (1:482776) nor its parent were
> > > encountered. Possible bad chain linkage.
> > > Server: Msg 8981, Level 16, State 1, Line 1
> > > Table error: Object ID 772614241, index ID 1. The next pointer of
> > (1:493336)
> > > refers to page (1:482778). Neither (1:482778) nor its parent were
> > > encountered. Possible bad chain linkage.
> > > There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
> > > CHECKDB found 0 allocation errors and 3 consistency errors in table
> > > 'cse_Case_tab' (object ID 772614241).
> > >
> > > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
> > >
> > > ..........
> > >
> > > There are 29 rows in 1 pages for object 'cse_Note_tab'.
> > > Server: Msg 8952, Level 16, State 1, Line 1
> > > Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
> > > 1520633106) (index ID 7). Extra or invalid key for the keys:
> > > Server: Msg 8956, Level 16, State 1, Line 1
> > > Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId
= 1
> > > and CFId = 1049716 and CaseId = 1) points to the data row identified
by
> > ().
> > >
> > >
> > >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
> > >
> > >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
> > >
> > > /peti
> > >
> > >
> > >
> > >
> > >
> > > "peti" <bpetigaspar@.gmail.com> wrote in message
> > > news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> > > > Hello all,
> > > >
> > > > I've got this error as result of CHECKDB command:
> > > >
> > > > CHECKDB found 1 allocation errors and 4 consistency errors in
database
> > > > 'Data'.
> > > > repair_allow_data_loss is the minimum repair level for the errors
found
> > by
> > > > DBCC CHECKDB (Data ).
> > > >
> > > > It looks like the CHECKDB with repair_allow_data_loss can solve the
> > > problem.
> > > > Is there any way to know beforehand, what data will be lost?
> > > >
> > > > Thanks,
> > > > peti
> > > >
> > > >
> > >
> > >
> >
> >
> >|||Hi Peti
I don't use replication, but I would stop it to avoid potentially a
significant number of changes being passed over the network. If you are
replicating in full any of the tables that have shown errors then you may
want to see if comparing the replicated database and the current live
database shows any differences.
John
"peti" wrote:
> Hello John,
> This is the result of DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS :
> ......
> CHECKDB found 1 allocation errors and 6 consistency errors in database
> 'Data'.
> CHECKDB fixed 1 allocation errors and 6 consistency errors in database
> 'Data'.
> ........
> Then, the CHECKDB command reported only consistency errors:
> ..........
> Server: Msg 8951, Level 16, State 1, Line 1
> Table error: Table 'cse_Case_tab' (ID 1520633106). Missing or invalid
> key in index 'cse_Case_ind7' (ID 7) for the row:
> Server: Msg 8955, Level 16, State 1, Line 1
> Data row (1:401723:0) identified by (RID = (1:401723:0) CenterId = 1 and
> CaseFolderId = 1049723 and CaseId = 1) has index values (CaseTypeId = 10 and
> ToCaseTypeArea = ').
> CHECKDB found 0 allocation errors and 4 consistency errors in table
> 'cse_Case_tab' (object ID 1520633106).
> CHECKDB found 0 allocation errors and 4 consistency errors in database
> 'Data'.
> repair_fast is the minimum repair level for the errors found by DBCC
> CHECKDB (Data ).
> .........
> Repair fast didn't solved the consistency errors so I run DBCC DBREINDEX
> against cse_Case_ind7 index. Then CHECKDB reported no errors.
> Red Gate still reports "differences" between databases. Some rows are
> reported as being only in the old DB but the same number of rows with the
> same content are reported as being present only in the new DB. So the same
> data is logically in both databases. I consider this no problem!?
> The transactional replication is still in place. Should I stop the
> replication before DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS ? I suppose yes
> because of single user mode requirement.
> regards,
> peti
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:CB6FA2CE-02D0-4095-8DF7-B7ED410D7FEE@.microsoft.com...
> > Hi
> >
> > The index page is missing it's parent reference it does not necessarily
> mean
> > that it contains data. Examples of the syntax and using DBCC PAGE can be
> > found at http://www.sql-server-performance.com/dbcc_commands.asp and
> > http://www.sql-server-performance.com/gv_index_data_structures.asp. I
> assume
> > that you are persuing this route because you don't have a good backup that
> > you can roll forward? make sure you backup before correcting the database,
> > and you may want to compare what you have against the last good backup you
> > have with something like SQL Data Compare from Red Gate www.red-gate.com,
> or
> > compare the pre-repared database to the post-repaired database (which may
> > only confirm that you have already lost the data!).
> >
> > John
> >
> > "peti" wrote:
> >
> > > It was a power failure.
> > >
> > > In my case the clustered index is corupt (Object ID 772614241, index ID
> 1).
> > > Does it mean data loss?
> > >
> > > What means data loss - only one row or the entire table?
> > >
> > > /peti
> > >
> > > "peti" <bpetigaspar@.gmail.com> wrote in message
> > > news:eh5qb1$s3r$1@.news.al.sw.ericsson.se...
> > > > Thank you John,
> > > >
> > > > I've read those posts but I'm still confused - for the error 8981, if
> the
> > > > dbbcc checkdb REPAIR_ALLOW_DATA_LOSS works fine, how can I find what
> data
> > > is
> > > > missing?
> > > >
> > > > DBCC CHECKDB outcome:
> > > >
> > > >
> > > >
> > > > DBCC results for 'conflict_edu_Script_tab'.
> > > > Server: Msg 8979, Level 16, State 1, Line 1
> > > > Table error: Object ID 772614241, index ID 1. Page (1:482455) is
> missing
> > > > references from parent (unknown) and previous (page (1:482777)) nodes.
> > > > Possible bad root entry in sysindexes.
> > > > There are 0 rows in 0 pages for object 'conflict_edu_Script_tab'.
> > > > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=53072
> > > >
> > > > ...................
> > > >
> > > > DBCC results for 'cse_CaseFolder_tab'.
> > > > Server: Msg 8981, Level 16, State 1, Line 1
> > > > Table error: Object ID 772614241, index ID 1. The next pointer of
> > > (1:482455)
> > > > refers to page (1:482776). Neither (1:482776) nor its parent were
> > > > encountered. Possible bad chain linkage.
> > > > Server: Msg 8981, Level 16, State 1, Line 1
> > > > Table error: Object ID 772614241, index ID 1. The next pointer of
> > > (1:493336)
> > > > refers to page (1:482778). Neither (1:482778) nor its parent were
> > > > encountered. Possible bad chain linkage.
> > > > There are 4622077 rows in 91565 pages for object 'cse_CaseFolder_tab'.
> > > > CHECKDB found 0 allocation errors and 3 consistency errors in table
> > > > 'cse_Case_tab' (object ID 772614241).
> > > >
> > > > http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=63537
> > > >
> > > > ..........
> > > >
> > > > There are 29 rows in 1 pages for object 'cse_Note_tab'.
> > > > Server: Msg 8952, Level 16, State 1, Line 1
> > > > Table error: Database 'DB', index 'cse_Case_tab.cse_Case_ind7' (ID
> > > > 1520633106) (index ID 7). Extra or invalid key for the keys:
> > > > Server: Msg 8956, Level 16, State 1, Line 1
> > > > Index row (1:24702:1) with values (CTId = 10 and ToCTA = NULL and CCId
> = 1
> > > > and CFId = 1049716 and CaseId = 1) points to the data row identified
> by
> > > ().
> > > >
> > > >
> > > >
> > >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f7a.asp
> > > >
> > > >
> > >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_6f76.asp
> > > >
> > > > /peti
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "peti" <bpetigaspar@.gmail.com> wrote in message
> > > > news:eh59ee$j2v$3@.news.al.sw.ericsson.se...
> > > > > Hello all,
> > > > >
> > > > > I've got this error as result of CHECKDB command:
> > > > >
> > > > > CHECKDB found 1 allocation errors and 4 consistency errors in
> database
> > > > > 'Data'.
> > > > > repair_allow_data_loss is the minimum repair level for the errors
> found
> > > by
> > > > > DBCC CHECKDB (Data ).
> > > > >
> > > > > It looks like the CHECKDB with repair_allow_data_loss can solve the
> > > > problem.
> > > > > Is there any way to know beforehand, what data will be lost?
> > > > >
> > > > > Thanks,
> > > > > peti
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
>
>

Thursday, March 8, 2012

checktable error

Tuesday, February 14, 2012

CHECKDB found 0 allocation errors and 2 consistency errors in data

CHECKDB allocation error

CHECKDB allocation error

CHECKDB allocation error

check sql licence

Blog Archive

About Me