SQL Server

Reasons to Run DBCC UPDATEUSAGE1 min read

One e-mail alert that we all dread receiving is an alert stating that DBCC CHECKDB found issues.

Before I go any further, this is a good time to make a public service announcement to verify you do not have these types of alerts filtered into e-mail folders you never check. Rummaging through old e-mail during some downtime and finding CHECKDB errors for the last month is a good way to turn a good day into a bad day.




You’re welcome. Now, back to our regularly scheduled programming.

Once when moving and upgrading some older databases, multiple databases came back with the same type of alert after running DBCC CHECKDB:

Msg 2508, Level 16, State 3, Line 1

The In-row data RSVD page count for object “table_name”, index ID 0, partition ID 57682760205822,
alloc unit ID 57682760205822 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.

It was nice to have a starting point knowing that the suggestion was to run DBCC UPDATEUSAGE. First, I wanted to research exactly what that meant.

DBCC UPDATEUSAGE is used to correct inaccuracies with rows, pages, and data page counts. Microsoft recommends only running it as needed because it will lock tables that are being worked on and can take a long time to run on “large” tables or databases. I thought my databases were “large” but when I ran DBCC UPDATEUSAGE it finished in seconds. It probably helped that there was not much activity at the time.

I ran DBCC CHECKDB again on the databases that had reported issues and everything came back clean!

Time to go double check those e-mail filters…

Thanks for reading!

Leave a Comment