Comments (3)

  1. An explanation of your results:

    Firstly, running DBCC against the tables to load the data into memory does nothing – DBCC uses 100 buffers in the buffer pool and marks them for disfavoring. You can’t preload data into memory using DBCC.

    The runs against the snapshot are so much faster because DBCC doesn’t need to create the underlying database snapshot, nothing to do with DBCC itself. There’s nothing different in the DBCC algorithms or the I/O it does – it just doesn’t have to create the snapshot itself. When running against a snapshot, you still have to take the time and disk space to create the snapshot.

    I would never advocate running DBCC in parallel EXCEPT on a snapshot, as each parallel DBCC run against the database has to create its own snapshot in that case. If there is activity in the database, running in parallel NOT against the snapshot will likely bring the system to it’s knees quickly. You really need to make that recommendation clear.


    1. Thanks for the additional information, Paul!

      I discounted the first run of DBCC CHECKTABLE because the first run always took significantly longer to run than follow-up runs. And when when I run it against the very large table, SQL Server’s memory usage increases my almost 7 GB, which is the size of the table. I’m not disagreeing, I’m just saying that this was my observation.

Leave a Reply