What can cause DBCC CheckDB to take longer than usual? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

I have a maintenance task, which do a DBCC CHECKDB WITH PHYSICAL_ONLY on the Databases on my server (SQL Server 2016 Standard Edition).

This usually takes about 7h30 for about 120 databases and it is an acceptable time. But once in a while (like yesterday), it took 10 hours to do this operation on the same amount of databases.

From the logs, I know that every DBCC CHECKDB took longer than usual to run. It's not only one DBCC CHECKDB that took 3 hours more. It's all individual CHECKDB that took a few minutes more.
The CHECKDB are running during the night, when clients are still using the Database, but where there's less activity.The databases have increased in size, but not that much that it would cause a 3 hours increase.

Other than client's activity on the Database, which can cause some delays, what can cause DBCC CHECKDB to take a much longer time than usual? I need to at least have an explanation to give to my boss as to why once in a while it does this and then reverts back to a normal time.

Thanks

Answer 1

Lots of options, kind of hard to speculate:

• Slower IO to disks, perhaps due to activity elsewhere on the SAN?
• Other activity on the box interfering (user activity, maintenance jobs, other databases, etc.)
• Memory or CPU pressure on the box (admin logged on locally leaving things running, big SSIS packages eating up CPU or local memory)

Narrowing down which of these it might be won't be easy, you'll probably have to turn on some long-running perfmon logs and do some trending over time.