DBCC CHECKTABLE taking 15+ minutes to run on an empty table

Question

I have a database where DBCC CHECKTABLE on a number of small or empty tables taking over 15 minutes to run. When it finishes there are no failures or errors. The performance on everything else on the server is at a very acceptable form. There was nothing else running at the same time.

I have also tried DBCC CLEANTABLE and updated stats with fullscan.

I'm using SQL Server 2016 Enterprise Edition (13.0.5201.2)

Example table:

CREATE TABLE [Schema1].[Table1](
    [col1] [int] NOT NULL,
    [col2] [nvarchar](100) NOT NULL,
    [col3] [xml] NOT NULL,
 CONSTRAINT [PK_1] PRIMARY KEY CLUSTERED 
(
    [col1] ASC,
    [col2] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Answer 1

I ended up opening an incident with Microsoft and it was determined that the sys.sysrscols (that can only be accessed via DAC) had over 200 million rows. After they did a review it was found as part of DBCC SQL Server always does checks on system tables even for DBCC CHECKTABLE. From the DBCC CHECKTABLE manual:

Integrity checks are always performed on all system table indexes.

My understanding is sys.sysrscols does some column tracking and the reason for the large size is a number of tables (200+) we have that have 2,000+ partitions and 163 columns. Almost all of them were temporary working tables that should have been dropped by the application but were not. I cleared them out and the process returned to a normal response time for an empty table of less than 1 minute.

They also noted it is listed in the documentation that partitions can impact DBCC checks. From Partitioned Tables and Indexes:

DBCC Commands

With a larger number of partitions, DBCC commands could take longer to execute as the number of partitions increases.