August 23, 2011 at 5:16 pm
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?
August 23, 2011 at 5:16 pm
DBCC rule... thank Ian and Paul too
😎
August 23, 2011 at 5:33 pm
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?
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
August 24, 2011 at 7:00 am
"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.
August 26, 2011 at 8:22 pm
How would you title this article to make it more innocuous?
A Non-Production Index Error Checker?
September 1, 2011 at 9:20 am
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.
September 9, 2011 at 4:55 am
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!!
September 12, 2011 at 9:02 am
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'sCredit 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.
June 18, 2014 at 10:43 am
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?
June 18, 2014 at 11:09 am
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
June 18, 2014 at 11:13 am
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?
June 18, 2014 at 11:43 am
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
June 18, 2014 at 11:48 am
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?
June 18, 2014 at 11:50 am
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