DBCC checkdb (repair)-- any way to split it up or watch progress?
We have a large database with a partitioned table (1.5 TB partitioned by year 2003 to 2014) that showed errors detected by dbcc checkdb (physical only) -- about 80 errors, all limited to TWO of the partitions. Because the database was running in simple recovery mode, we could not just replace damaged filetables or pages.
Running dbcc checkdb (repair_allow_data_loss) is taking forever (more than 36 hours), and it has failed 5 times so far, asking for expansions of different file groups-- most of which didn't have errors. Each time we have run it, it has run for a while longer (several hours longer) then crashes, asking for expansion of a different filegroup.
I can expand one file group, then two runs later, after it has crashed and asked for expansion of other file groups, it will come back and crash asking for expansion of a file group I have already expanded.
1. Why is it involving filegroups that were not detected as bad by dbcc checkdb originally
2. Every time it crashes, is it losing everything it accomplished in the hours it spent before the crash?
3. Is there some way to do this piecemeal, one partition at a time.
Running dbcc checkdb (repair_allow_data_loss) is taking forever (more than 36 hours), and it has failed 5 times so far, asking for expansions of different file groups-- most of which didn't have errors. Each time we have run it, it has run for a while longer (several hours longer) then crashes, asking for expansion of a different filegroup.
I can expand one file group, then two runs later, after it has crashed and asked for expansion of other file groups, it will come back and crash asking for expansion of a file group I have already expanded.
1. Why is it involving filegroups that were not detected as bad by dbcc checkdb originally
2. Every time it crashes, is it losing everything it accomplished in the hours it spent before the crash?
3. Is there some way to do this piecemeal, one partition at a time.
Can you post the error logs?
ASKER
They aren't very useful. The first just lists the pages and object IDs for the corruption; the second during repair states which filegroup is too small and asks me to make it larger.
DBCC-checkdb-fileonly-ExpertsExchange.tx
DBCC-crash-with-error-asking-for-space-E
DBCC-checkdb-fileonly-ExpertsExchange.tx
DBCC-crash-with-error-asking-for-space-E
You can check each filegroup at a time but for repairing the only command available is the DBCC CHECKDB.
DBCC CHECKFILEGROUP (1) -- Parameter is the filegroup numberASKER
OK-- But why is it touching filegroups that did not have corruption revealed by DBCC checkdb?
What could DBCC checkdb (repair) be doing to these non-corrupted filegroups.
These filegroups all involve clustered indexes. Is it rebuilding indexes that are not corrupted. How can I determine what DBCC checkdb (repair) is actually doing?
What could DBCC checkdb (repair) be doing to these non-corrupted filegroups.
These filegroups all involve clustered indexes. Is it rebuilding indexes that are not corrupted. How can I determine what DBCC checkdb (repair) is actually doing?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK. Now I get it.
Also, thanks for the link to Paul Randall's site. That is an important reference.
Also, thanks for the link to Paul Randall's site. That is an important reference.
That is an important reference.It's the Bible for DBCC CHECKDB ;)
Cheers