DBCC UPDATEUSAGE in SQL Server: What It Does, When to Run It, and When Not To

On This Page

DBCC UPDATEUSAGE is one of those SQL Server commands that many DBAs encounter during migrations, upgrades, or troubleshooting but may rarely need during normal database administration.

A common question is:

Should I run DBCC UPDATEUSAGE after restoring or migrating a database to a new SQL Server?

Usually, the answer is no — not automatically.

Let’s understand why.

1. What Does DBCC UPDATEUSAGE Do?

DBCC UPDATEUSAGE checks and corrects inaccuracies in SQL Server’s metadata related to page and row counts.

These counts are used when SQL Server reports information such as:

Incorrect metadata can cause commands such as sp_spaceused to report inaccurate information.

A basic execution against the current database is:

DBCC UPDATEUSAGE (0);

Here, 0 means the current database.

2. Basic Syntax

The general syntax is:

DBCC UPDATEUSAGE
(
    { database_name | database_id | 0 }
    [ , { table_name | table_id | view_name | view_id }
    [ , { index_name | index_id } ] ]
)
[ WITH NO_INFOMSGS ];

You can therefore run the command against:

3. Running It Against an Entire Database

For example:

USE YourDatabase;
GO

DBCC UPDATEUSAGE (0);
GO

To suppress informational messages:

DBCC UPDATEUSAGE (0)
WITH NO_INFOMSGS;
GO

For a large production database, remember that processing the entire database can take time.

4. Running It Against a Specific Table

If you suspect the problem is limited to one table, you don’t necessarily need to process the entire database.

For example:

DBCC UPDATEUSAGE
(
    YourDatabase,
    'dbo.YourTable'
);
GO

This can be preferable when troubleshooting a specific object.

5. Why Would Page or Row Counts Become Incorrect?

SQL Server normally maintains this metadata automatically.

However, incorrect counts can sometimes exist, particularly with older databases or unusual metadata conditions.

Symptoms can include:

The important point is that DBCC UPDATEUSAGE is primarily a metadata correction command.

It is not a general-purpose performance tuning command.

6. How Does DBCC CHECKDB Relate to UPDATEUSAGE?

DBCC CHECKDB performs integrity checks against a database.

For example:

DBCC CHECKDB ('YourDatabase')
WITH NO_INFOMSGS;
GO

If SQL Server detects certain incorrect page or row counts, DBCC CHECKDB can report the issue and recommend running DBCC UPDATEUSAGE.

In that situation, running DBCC UPDATEUSAGE is appropriate.

For example:

USE YourDatabase;
GO

DBCC UPDATEUSAGE (0)
WITH NO_INFOMSGS;
GO

You can then run DBCC CHECKDB again:

DBCC CHECKDB ('YourDatabase')
WITH NO_INFOMSGS;
GO

7. Should DBCC UPDATEUSAGE Be Part of Regular Maintenance?

Generally, no.

SQL Server normally maintains page and row count metadata itself.

Therefore, running this command every day or after every maintenance operation is usually unnecessary.

A better approach is to run it when:

Avoid treating it as a routine “just in case” maintenance command.

8. Should You Run It After Restoring a Database?

This is an important DBA question.

Suppose you perform:

SQL Server
    ↓
Full Backup
    ↓
Restore to another SQL Server

Do you automatically need:

DBCC UPDATEUSAGE (0);

No.

A normal backup and restore does not by itself mean that the database’s usage metadata is incorrect.

Instead, perform normal post-restore validation.

For example:

DBCC CHECKDB ('YourDatabase')
WITH NO_INFOMSGS;
GO

If DBCC CHECKDB reports no relevant metadata problem, there is normally no reason to run DBCC UPDATEUSAGE simply because the database was restored.

9. What About a SQL Server Version Upgrade?

Consider a migration such as:

SQL Server 2016
        ↓
SQL Server 2025

Again, I would not automatically run DBCC UPDATEUSAGE solely because the database moved to a newer SQL Server version.

Instead, validate the database systematically.

A post-migration process should include:

  1. Confirm the database is online.
  2. Run appropriate integrity checks.
  3. Validate application connectivity.
  4. Validate SQL Server Agent jobs.
  5. Validate logins and permissions.
  6. Review application performance.
  7. Check for SQL Server errors or warnings.
  8. Investigate any metadata discrepancies.

Run DBCC UPDATEUSAGE if the validation process indicates that it is needed.

10. DBCC UPDATEUSAGE Is Not UPDATE STATISTICS

This distinction is very important.

These commands solve different problems.

DBCC UPDATEUSAGE

Corrects metadata related to things such as:

Example:

DBCC UPDATEUSAGE (0);

UPDATE STATISTICS

Updates optimizer statistics used for query optimization.

Example:

UPDATE STATISTICS dbo.YourTable;

Or:

EXEC sys.sp_updatestats;

Therefore:

DBCC UPDATEUSAGE
        ≠
UPDATE STATISTICS

Running DBCC UPDATEUSAGE should not be considered a replacement for statistics maintenance.

11. DBCC UPDATEUSAGE Is Not DBCC CHECKDB

These commands also serve different purposes.

DBCC CHECKDB

Checks the logical and physical integrity of database objects.

DBCC CHECKDB ('YourDatabase');

DBCC UPDATEUSAGE

Corrects inaccurate page and row count metadata.

DBCC UPDATEUSAGE (0);

A useful way to remember the difference is:

CHECKDB
   ↓
Database integrity

UPDATEUSAGE
   ↓
Usage metadata

12. Using sp_spaceused

If you’re investigating space usage, you might start with:

EXEC sys.sp_spaceused;
GO

For a particular table:

EXEC sys.sp_spaceused
    @objname = N'dbo.YourTable';
GO

If the reported values appear incorrect, usage metadata may need investigation.

sp_spaceused also provides an option that can update usage information:

EXEC sys.sp_spaceused
    @updateusage = N'true';
GO

However, this should also be used deliberately rather than automatically on production databases.

13. What Does COUNT_ROWS Do?

DBCC UPDATEUSAGE supports the COUNT_ROWS option.

For example:

DBCC UPDATEUSAGE (0)
WITH COUNT_ROWS;
GO

This causes SQL Server to update the row-count information using the current number of rows.

Be careful with this option on large databases because obtaining row counts can increase the amount of work required.

14. Production Considerations

Before running DBCC UPDATEUSAGE across a large production database, consider:

If only one table has a problem, target that object rather than automatically processing the entire database.

15. A Practical DBA Decision Process

A simple decision process can look like this:

Are space/page/row counts suspicious?
                |
           No --+--> Don't run UPDATEUSAGE
                |
               Yes
                |
                v
       Validate the problem
                |
                v
     Run DBCC CHECKDB if appropriate
                |
                v
Does CHECKDB recommend UPDATEUSAGE
or is metadata clearly incorrect?
                |
           No --+--> Investigate further
                |
               Yes
                |
                v
       Run DBCC UPDATEUSAGE
                |
                v
          Validate again

The key principle is:

Use DBCC UPDATEUSAGE because you have a reason to use it, not simply because a database was restored or migrated.

16. Recommended Post-Migration Approach

For a migration from SQL Server 2016 to SQL Server 2025, a reasonable high-level validation sequence is:

-- Confirm database status

SELECT
    name,
    state_desc,
    compatibility_level
FROM sys.databases
WHERE name = 'YourDatabase';
GO

Then perform an appropriate integrity check:

DBCC CHECKDB ('YourDatabase')
WITH NO_INFOMSGS;
GO

Validate the application and monitor the environment.

If DBCC CHECKDB reports incorrect page or row counts and recommends DBCC UPDATEUSAGE, then run:

USE YourDatabase;
GO

DBCC UPDATEUSAGE (0)
WITH NO_INFOMSGS;
GO

Then validate again.

Best Practices

Final Thoughts

DBCC UPDATEUSAGE is a useful SQL Server administration command, but it is not something that needs to run after every backup, restore, migration, or upgrade.

SQL Server normally maintains usage metadata automatically.

The command becomes useful when page or row counts are incorrect, space reporting is suspicious, or SQL Server specifically identifies a usage metadata problem.

For a SQL Server 2016 to SQL Server 2025 migration, focus first on integrity checks, application validation, security, dependencies, and performance testing.

Run DBCC UPDATEUSAGE when the evidence tells you it is necessary — not simply because the database moved to a new server.