January 7, 2013 at 9:59 am
DBCC CheckDB job failed last night. This is SQL Server 2005 Enterprise Edition 64 bit environment. The message / solution indicated running "DBCC UPDATEUSAGE".
This is a first for me, should the command be run against the database? Or against the table listed? I'm assuming this should be run during a maintenance window.
Error message is as follows:
Progress: 2013-01-06 12:00:05.17 Source: Execute T-SQL Statement Task
Executing query "USE [xxx] ".: 50% complete End Progress
Error: 2013-01-06 12:01:21.03 Code: 0xC002F210 Source: Execute T-SQL Statement Task Execute SQL Task
Description: Executing the query "DBCC CHECKDB WITH ALL_ERRORMSGS" failed with the following error: "The In-row data USED page count for object "Project_SubFees",
index ID 9, partition ID 2544946730696704, alloc unit ID 2544946730696704 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE. The In-row data RSVD page count for object "Project_SubFees", index ID 9, partition...The package execution fa... The step failed.
Any comments would be appreciated - thank you.
January 7, 2013 at 10:33 am
Just run exactly what the error says - DBCC UPDATEUSAGE. Doesn't usually take that long
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 7, 2013 at 12:32 pm
"take long" is quite relative. In the enviroment I know we lose data if a table is locked for more than 30 seconds. As far as I have seen the UPDATE-USAGE-command places a lot of locks and on tables with some million records the command runs much longer than 30 seconds.
Maybe - and I really mean MAYBE - you can solve the problem by rebuilding the indexe mentioned in the error message. Depending on the SQLServer-version you use you can do an online rebuild which should hold only minimal locks. I don't believe an index reorg will work but it would be another try.
January 7, 2013 at 12:44 pm
WolfgangE (1/7/2013)
Maybe - and I really mean MAYBE - you can solve the problem by rebuilding the indexe mentioned in the error message.
Dropping and recreating should solve this particular corruption.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 8, 2013 at 8:36 am
I ran the DBCC UPDATEUSAGE command without incident. The DBCC CheckDB runs fine. I don't have any experience dropping and recreating an index. What I've done is take a backup of the database (with the corruption) and will attempt this in a test environment. Learning process continues...
Thank you both for responding.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply