Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

A faster DBCC CHECKDB? Expand / Collapse
Author
Message
Posted Thursday, September 1, 2011 9:20 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, June 6, 2014 1:24 PM
Points: 49, Visits: 189
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.
Post #1168751
Posted Friday, September 9, 2011 4:55 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: 2 days ago @ 9:07 AM
Points: 1, Visits: 151
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!!
Post #1172389
Posted Monday, September 12, 2011 9:02 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 8:17 AM
Points: 11, Visits: 59
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.
Post #1173524
Posted Wednesday, June 18, 2014 10:43 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, August 21, 2014 10:33 AM
Points: 1,283, Visits: 2,959
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?
Post #1583137
Posted Wednesday, June 18, 2014 11:09 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Sunday, August 3, 2014 11:47 AM
Points: 2,038, Visits: 1,664
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
Post #1583164
Posted Wednesday, June 18, 2014 11:13 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, August 21, 2014 10:33 AM
Points: 1,283, Visits: 2,959
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?
Post #1583169
Posted Wednesday, June 18, 2014 11:43 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Sunday, August 3, 2014 11:47 AM
Points: 2,038, Visits: 1,664
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
Post #1583226
Posted Wednesday, June 18, 2014 11:48 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, August 21, 2014 10:33 AM
Points: 1,283, Visits: 2,959
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?
Post #1583239
Posted Wednesday, June 18, 2014 11:50 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Sunday, August 3, 2014 11:47 AM
Points: 2,038, Visits: 1,664
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
Post #1583247
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse