I have a busy 50GB database which takes ~24 hours to DBCC CHECKDB because it has many persisted/computed columns, and this triggers slowness which Paul Randal has blogged about in the past. It's busy in that it seems lots of simple INSERT statements but nothing in the way of explicit transactions.Last week I restored a full backup from production in a testing environment and it took only a few minutes. Today I attempted to restore another full backup (but one that occurred near the end of the 24-hour DBCC CHECKDB window) in another testing environment and it has been going for > 40 minutes.I restored with REPLACE, STATS and was watching the wait stats, so I could see:- An initial pause with ASYNC_IO wait stat as it zero-initialized the files.- The progress print statements 10-100% and "Processed XXXX pages" for the data and log file.- And then 35+ minutes of PAGEIOLATCH_SH waits and random pages in this database as the resource.- I can also observe the disk stats for the server are going crazy with reads and writes on that mount point.My only guess is that it is rolling forward transactions that were committed during the DBCC CHECKDB, because I know that DBCC CHECKDB takes an internal snapshot while it is running. But I never thought it would have an impact like this - and these extremely slow DBCC CHECKDBs and any impact they have aren't documented very well :-)Am I on the right track?
↧