First things first: I don't think trace flag 2549 does anything in SQL Server 2016 SP1 Enterprise Edition.
Last time I said that, I was wrong :grinning:. I was tricked by trace flag 2549 needing to be enabled globally in order to change behavior - I was testing with it enabled at session level. But... after opening a ticket with Microsoft the kb article was updated to note that T2549 must be enabled globally :grinning:.
*This* time I made sure to enable T2549 globally. But I didn't see any difference in behavior although all 8 of my database filegroup data files were in directories under mount points of a single drive letter. Checkdb reads were *really* aggressive either way. Like - more aggressive than previously when T2549 did make a difference. My execution times were within 5% of each other. I'll scrutinize the perfmon and session waits more later. But for now, I'm assuming that behavior is the same and expected performance the same with or without T2549.
Now on to the good stuff. As I mentioned, checkdb with physical_only reads are quite aggressive in SQL Server 2016 SP1. The system I tested on is an 8 vcpu vm with 64 GB RAM. Aggregate database data footprint - across 8 files in a single filegroup - is 3335GB. (Summing the fileproperty('spaceused') across the 8 files).
Let's see some graphs!!!
Look at that read throughput in a vanilla checkdb with physical_only! These perfmon captures are using 1 second intervals - nearly saturating bandwidth for a considerable amount of time during its execution.
Image may be NSFW.
Clik here to view.
Hard to see because of the scale, but there's a rise and and fall in memory grant usage corresponding to the "batches" that checkdb is using. Way less than 10 gb of Tempdb is used at peak, for less than 6 minutes out of the roughly 60 minute execution time.
Let's take a look at CPU utilization. Ohhh yeahh! Most of the time there were 16 checkdb parallel threads in use for this 8 vcpu VM. The only break in fairly heavy CPU utilization came during the processing of that large batch in the middle.
Image may be NSFW.
Clik here to view.
OK. Recall that trace flag 2562 instructs checkdb to use a single large "batch" for all of its checking. This can lead to a significant speedup - especially on spinning disk. The cost is more use of tempdb. The next test - checkdb with physical_only + T2562 -demonstrates both the benefit and cost of this behavior.
Hooo doggie!! It only took about 48 minutes and 30 seconds now! Look at that fascinating step function of tempdb use!! Notice how the read bytes/sec plummet briefly before each new step of tempdb use. If only I had enough time to dig into the mechanics of that! Maybe another day...
Image may be NSFW.
Clik here to view.
All right - lets take a look at CPU utilization. CPU also drops at the beginning of each new step of tempdb use. What a teaser!
Image may be NSFW.
Clik here to view.
But there you have it. Pretty aggressive checkdb with physical_only in SQL Server 2016 SP1. Even a little bit more aggressive with trace flag 2562 enabled. (I enabled it globally for these tests.)
When planning for checkdb with physical_only in SQL Server 2016 SP1, you may want to stick it into its own Resource Governor workload group so you can independently control DOP, maybe tinker with its max memory grant, and maybe even use IOPs governance. I hope to return to those matters sometime soon here. But first gotta also test T2528 (disable parallel checks) and full checkdb.
I should note that these checkdb tests were run in isolation. If there is another concurrent workload on the system, not only will it be effected by checkdb, but that workload will impact checkdb performance. Even moreso if that concurrent workload contains DML (because the internal snapshot for checkdb must be maintained).
Ciao for now!