A faster DBCC CHECKDB?

  • have not tested this but in case someone already knows the answer, wouldn't this miss items like data purity, filestream and others mentioned specifically in BOL?

    http://msdn.microsoft.com/en-us/library/ms176064.aspx

  • DBCC rule... thank Ian and Paul too

    😎

  • sqlmashup (8/23/2011)


    have not tested this but in case someone already knows the answer, wouldn't this miss items like data purity, filestream and others mentioned specifically in BOL?

    http://msdn.microsoft.com/en-us/library/ms176064.aspx

    Yes - it will only find IO subsystem corruptions.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • "By clearing the buffer pool, using the command DBCC DROPCLEANBUFFERS, we ensure any data is read from the underlying physical disks, and this is where we want to find any errors."

    This sentence is enough to dissuade it's use for me. On a production system that is running 24/7 dropping the data buffers would be terrible for performance. My understanding of DBCC CHECKDB is that it doesn't pollute the data buffers with its reads. Those reads are marked as 'can go away first' so the memory is reused as needed. Obviously Paul knows more on the workings of this but beware of DROPCLEANBUFFERS on a production system.

  • How would you title this article to make it more innocuous?

    A Non-Production Index Error Checker?

  • Grant Fritchey (8/23/2011)


    Excellent code. Nice article. Well explained.

    But I have to say, articles like this really do make me nervous. It seems like a very healthy percentage of our fellow database professionals are missing a few fundamentals. Suggesting a way to avoid something as important as DBCC CHECKDB seems rife with potential for disaster. I'd just hate to hear "I was following your advice and now we've lost our production system."

    This.

    Also, the only way for DBCC CHECKDB to be faster is for Microsoft to fix tempdb so that DBAs can allocate filegroups to temporary storage on a per database (or perhaps even more granular) basis. A global tempdb database used for everything is simply the biggest design flaw in SQL Server today, period.

  • Come on guys, this is not recommended as an alternative or replacement.

    It has to be better than doing nothing inbetween the usual 7 days to a month gap DBCC runs on large DB's

    Credit to you Ian!!

  • yemi_aderele (9/9/2011)


    Come on guys, this is not recommended as an alternative or replacement. It has to be better than doing nothing inbetween the usual 7 days to a month gap DBCC runs on large DB's

    Credit to you Ian!!

    I agree with Yemi, although I will also not use it because of the DBCC DROPCLEANBUFFERS.

    Especially liked the idea of the whole check stopping early when an error is detected.

  • Paul Randal (8/22/2011)


    Nice - but really only the equivalent of BACKUP DATABASE ... WITH CHECKSUM.

    I would strongly advise not using this for the same reasons I strongly advise not using BACKUP DATABASE ... WITH CHECKSUM as an alternative to DBCC CHECKDB - it will not detect errors introduced by memory problems, SQL Server bugs, or IO subsystem corruptions of pages using torn-page detection.

    Bottom line - you can't avoid running DBCC CHECKDB - don't fall into the trap of running something faster. Offload your checks to a non-production server but continue running DBCC CHECKDB - it's the only thing that will find all corruptions.

    Thanks

    I know this is really old post, would it be help if i run DBCC CHeckdb on a different server where databases are SAN replicated from the production? Would it find all the errors like as if i ran on prod db?

  • No - running DBCC CHECKDB on any copy of the database that is maintained by SAN replication, log shipping, mirroring, etc is not good enough. That tells you nothing about the I/O subsystem on the main system. Only doing a full backup+copy+restore is a substitute for DBCC CHECKDB on the main server.

    Cheers

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • Paul Randal (6/18/2014)


    No - running DBCC CHECKDB on any copy of the database that is maintained by SAN replication, log shipping, mirroring, etc is not good enough. That tells you nothing about the I/O subsystem on the main system. Only doing a full backup+copy+restore is a substitute for DBCC CHECKDB on the main server.

    Cheers

    Thanks. While i have your attention here, does DBCC cause any blocking?

  • Not unless you say WITH TABLOCK.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • Paul Randal (6/18/2014)


    Not unless you say WITH TABLOCK.

    Hmmm......one last question....all my data files are sitting on same drive....i know DBCC very high intensive.....i was thinking to let DBCC run in serial fashion not to cause any IO contention ( which might take longer)....would DBCC run faster if i have it executing against all the database in parallel Vs serial?

  • No - don't run it in parallel - you'll overload your server and I/O subsystem.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

Viewing 14 posts - 16 through 28 (of 28 total)

You must be logged in to reply to this topic. Login to reply