Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

CHECKDB Expand / Collapse
Author
Message
Posted Friday, January 15, 2010 1:04 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, October 21, 2010 1:18 PM
Points: 71, Visits: 380
I have a MPlan it was failing when i run the DBCC CHECKDB(dbname)with NO_INFOMSGS,ALL_ERRORMSGS,i got the error as below any solution?
Msg 8928, Level 16, State 1, Line 1
Object ID 873822225, index ID 1, partition ID 338741790048256, alloc unit ID 57266813337600 (type In-row data): Page (1:175852) could not be processed. See other errors for details.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 873822225, index ID 1, partition ID 338741790048256, alloc unit ID 57266813337600 (type In-row data). Page (1:175853) is missing a reference from previous page (1:175852). Possible chain linkage problem.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 873822225, index ID 1, partition ID 338741790048256, alloc unit ID 338741790048256 (type In-row data). Page (1:175852) was not seen in the scan although its parent (1:175747) and previous (1:175851) refer to it. Check any previous errors.
Msg 8944, Level 16, State 24, Line 1
Table error: Object ID 873822225, index ID 1, partition ID 338741790048256, alloc unit ID 338741790048256 (type In-row data), page (1:175852), row 40. Test (ColumnOffsets + (int)sizeof (UINT16) <= (nextRec - pRec)) failed. Values are 174 and 172.
Msg 8944, Level 16, State 24, Line 1
Table error: Object ID 873822225, index ID 1, partition ID 338741790048256, alloc unit ID 338741790048256 (type In-row data), page (1:175852), row 40. Test (ColumnOffsets + (int)sizeof (UINT16) <= (nextRec - pRec)) failed. Values are 174 and 172.
CHECKDB found 0 allocation errors and 5 consistency errors in table 'NOC' (object ID 873822225).
CHECKDB found 0 allocation errors and 5 consistency errors in database 'Med'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Med).
Post #848526
Posted Friday, January 15, 2010 1:13 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 10:17 PM
Points: 17,817, Visits: 15,744

repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Med).


Your output is suggesting that you run the above repair option at a minimum. Do you have any known good backups that do not have this corruption?




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #848533
Posted Friday, January 15, 2010 1:15 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, October 21, 2010 1:18 PM
Points: 71, Visits: 380
By running the dbcc checkdb() repair_allow_data_loss,the data will be lost.as i dont have the backup of DB
Post #848536
Posted Friday, January 15, 2010 1:32 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 10:17 PM
Points: 17,817, Visits: 15,744
dba_neo (1/15/2010)
By running the dbcc checkdb() repair_allow_data_loss,the data will be lost.as i dont have the backup of DB


Potentially lost. Data may be lost - it depends on how bad the corruption is. The potential of losing the data needs to be discussed with the business, and then a decision made to get it fixed.




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #848543
Posted Friday, January 15, 2010 1:42 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 3:27 PM
Points: 20,734, Visits: 32,505
So you are saying that you have no previous backups made before getting this CHECKDB error, correct?



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #848545
Posted Friday, January 15, 2010 1:55 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, October 21, 2010 1:18 PM
Points: 71, Visits: 380
yes,is there any other solution for this problem?
Post #848549
Posted Friday, January 15, 2010 1:59 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 3:27 PM
Points: 20,734, Visits: 32,505
Not really, your only choice is to run DBCC CHECKDB with repair_allow_data_loss option. The optimum solution would have been to restore from a previous database backup prior to the corruption, and if there where t-log backups to restore those as well up until the corruption.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #848553
Posted Friday, January 15, 2010 2:18 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, October 17, 2014 7:12 AM
Points: 1,030, Visits: 2,796
I''ll send you to Paul Randal's blog post here...
http://www.sqlskills.com/blogs/paul/post/checkdb-from-every-angle-emergency-mode-repair-the-very-very-last-resort.aspx

It may help, it may not, thats for you to decided.

What i don't understand is if you have setup a maint plan to run integrity checks why you don't have a job/plan to take a backup.


Gethyn Ellis

gethynellis.com
Post #848567
Posted Saturday, January 16, 2010 1:39 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:48 AM
Points: 40,193, Visits: 36,598
CirquedeSQLeil (1/15/2010)
Potentially lost. Data may be lost - it depends on how bad the corruption is.


Will be lost.

If the minimum level to repair is repair_allow_data_loss, it means that there will be data loss if that is run. There's only two cases that I know of (incorrect PFS pages and orphaned LOB pages) where repair allow_data_loss is required but data won't be lost.

In this case, there is a single damaged page in the clustered index. Repair will drop that page and fix the links. Hence, any data on that page will be lost.

http://sqlinthewild.co.za/index.php/2009/06/03/does-repair_allow_data_loss-cause-data-loss/



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #848699
Posted Saturday, January 16, 2010 1:42 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:48 AM
Points: 40,193, Visits: 36,598


In this case the database is not suspect or recovery_pending, hence there is no need to switch to emergency mode. That blog post deals with the case when the DB is suspect and cannot be opened, not the case of simple corruption.

A better link might be this: http://www.sqlservercentral.com/articles/65804/



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #848701
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse