Following on from my post a couple of weeks ago (https://blogs.msdn.com/sqlserverstorageengine/archive/2007/01/24/how-long-will-checkdb-take-to-run.aspx), I'm very interested to know how long it takes for your CHECKDBs to run, so I can get an idea of the distribution of run-times on various kinds of hardware for various size databases.
So, if you have a couple of minutes, I'd be grateful if you could c&p the following into an email to me, prandal@microsoft.com, and answer the questions for one or more of your databases. I'd especially like to hear from those of you who work for Microsoft and look after multiple customers. If I get a worthwhile number of responses (say 100 or so) then I'll collate the responses and post a summary. I'd love to hear about databases larger than 1TB.
For the first 10 Microsoft and the first 10 non-Microsoft people to respond, I'll send you the Always-On DVD loaded with Hands-On Labs that walk you through a bunch of the various HA/DR technologies. (I'll let you know whether you win and you need to send me your address).
Many thanks!
- How large is the database?
- What's the size of the largest table?
- Do you have any indexed views?
- Which command do you run, including options?
- How long does the command take to run?
- How often do you run it?
- Which version & edition of SQL Server are you running?
- (If SQL Server 2005, did you notice an increase or decrease in runtime?)
- How many CPUs/cores does the server have?
- How much memory does the server have?
- What platform is the server?
- Describe your IO subsystem?
- Any comments?
Anonymous comments are disabled
About Paul Randal - MSFT
Paul started in the industry in 1994 working for DEC on the VMS file system and check/repair tools.
In 1999 he moved to Microsoft to work on SQL Server, specifically on DBCC. For SQL Server 2000, he concentrated on index fragmentation (writing DBCC INDEXDEFRAG and DBCC SHOWCONTIG) plus various algorithms in DBCC CHECKDB. During SQL Server 2005 development Paul was the lead developer/manager of one the core dev teams in the Storage Engine, responsible for data access and storage (DBCC, allocation, indexes & heaps, pages/records, text/LOB storage, snapshot isolation, etc). He also spent several years rewriting DBCC CHECKDB and repair. For SQL Server 2008, Paul managed the Program Management team for the core Storage Engine to become more focused on customer/partner engagement and feature set definition.
In 2007, after 8.5 years on the SQL Server team, Paul left Microsoft to join his wife, Kimberly Tripp, running SQLskills.com and pursuing his passion for presenting and consulting.
Paul regularly presents at conferences and user groups around the world on high-availability, disaster recovery and Storage Engine internals. His popular blog is at http://www.sqlskills.com/blogs/paul/.