InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 10:29:03 GMT20http://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote][b]rspskumar-704119 (1/17/2010)[/b][hr]plese set db status to emerngy mode and export data and run repair[/quote]Absolutely not. Totally unnecessary and frankly in this case stupid things to suggest.Emergency mode is a last resort for when the database is in suspect or recovery pending mode. Not for when the database is online and usable with minor corruption.Export (and subsequent re-import) is for when there's irreparable corruption, like damaged allocation pages. This corruption is perfectly repairable (albeit with minor data loss) and hence there is no need whatsoever for something as extreme as export and reimport.Sun, 17 Jan 2010 14:04:54 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxplese set db status to emerngy mode and export data and run repairSun, 17 Jan 2010 13:25:34 GMTrspskumar-704119http://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote][b]GilaMonster (1/16/2010)[/b][hr][quote][b]CirquedeSQLeil (1/15/2010)[/b][hr]Potentially lost. Data may be lost - it depends on how bad the corruption is. [/quote]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.[url]http://sqlinthewild.co.za/index.php/2009/06/03/does-repair_allow_data_loss-cause-data-loss/[/url][/quote]Thanks for correcting that Gail and explaining more precisely.Sat, 16 Jan 2010 12:26:09 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote][b]GRE-452109 (1/15/2010)[/b][hr]I''ll send you to Paul Randal's blog post here...[url]http://www.sqlskills.com/blogs/paul/post/checkdb-from-every-angle-emergency-mode-repair-the-very-very-last-resort.aspx[/url][/quote]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: [url]http://www.sqlservercentral.com/articles/65804/[/url]Sat, 16 Jan 2010 01:42:39 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote][b]CirquedeSQLeil (1/15/2010)[/b][hr]Potentially lost. Data may be lost - it depends on how bad the corruption is. [/quote]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.[url]http://sqlinthewild.co.za/index.php/2009/06/03/does-repair_allow_data_loss-cause-data-loss/[/url]Sat, 16 Jan 2010 01:39:42 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxI''ll send you to Paul Randal's blog post here...[url]http://www.sqlskills.com/blogs/paul/post/checkdb-from-every-angle-emergency-mode-repair-the-very-very-last-resort.aspx[/url]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.Fri, 15 Jan 2010 14:18:43 GMTGRE (Gethyn Ellis)http://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxNot 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.Fri, 15 Jan 2010 13:59:23 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxyes,is there any other solution for this problem?Fri, 15 Jan 2010 13:55:15 GMTdba_neohttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxSo you are saying that you have no previous backups made before getting this CHECKDB error, correct?Fri, 15 Jan 2010 13:42:51 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote][b]dba_neo (1/15/2010)[/b][hr]By running the dbcc checkdb() repair_allow_data_loss,the data will be lost.as i dont have the backup of DB[/quote]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.Fri, 15 Jan 2010 13:32:00 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxBy running the dbcc checkdb() repair_allow_data_loss,the data will be lost.as i dont have the backup of DBFri, 15 Jan 2010 13:15:54 GMTdba_neohttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspx[quote]repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Med).[/quote]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?Fri, 15 Jan 2010 13:13:03 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic848526-146-1.aspxI 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 1Object 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 1Table 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 1Table 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 1Table 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 1Table 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).Fri, 15 Jan 2010 13:04:08 GMTdba_neo