In April of this year, the SQL Intersection conference is coming to Las Vegas. I'm speaking, along with Grant Fritchey and many others. It's a fun event, in a city with a huge variety of things to do in the evenings after a full day of SQL Server sessions. At night I tend to look for networking chances to met new people and catch up with friends at night, though there have been a few times a comedy show has enticed me away from my hotel. I like Las Vegas, though I'm not a gambler. Despite the fact that most people think of visitors looking for their chance to sit at a table with dice or cards, there are many of us that go for other activities.
I was at in a session recently and heard a speaker recommend that the audience run DBCC checks regularly. That's good advice, and it's what I recommend in my sessions as well. A person in the audience raised their hand and politely disagreed, saying that they almost never run DBCC CHECKDB. This person found it to be a waste of resources since they'd never encountered corruption in their career, and hadn't known anyone in over a decade that had experienced on a SQL Server system. This person asked the speaker how many times the speaker had seen corruption (five was the answer) and then said across thousands of days of backups, it just wasn't worth the resources to run DBCC CHECDB.
If you feel that way, then you're a gambler. You are accepting a higher level of risk than I do, and higher than I recommend. Consistency checks are designed to help us catch corruption. Since we never know when it will occur, we want to detect is ASAP so that we avoid, or at least minimize, data loss. If you run those checks and never experience corruption, those checks are insurance payments you've made and never needed to file a claim. However if you don't run those checks, and experience corruption, you've placed a bet you've lost. Whether or not that cleans you out depends on the data loss your organization experiences and their tolerance for that loss. I'd seriously consider this a career limiting, or employment terminating, event, especially if the best practice recommendation from Microsoft and many experts is to run DBCC checks.
I don't recommend skipping your DBCC checks, but if that's how you feel, think about coming to SQL Intersection (register with the code "Jones" to support me). You might enjoy that gaming tables at night, and I know the other speakers and myself would welcome the chance to change your mind about skipping DBCC checks during the day.
Steve Jones
The Voice of the DBA Podcasts
We publish three versions of the podcast each day for you to enjoy.
- Watch the Windows Media Podcast - 17.4MB WMV
- Watch the iPod Video Podcast - 20.3MB MP4
- Listen to the MP3 Audio Podcast - 4.2MB MP3
The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there. Overall RSS Feed: 
or now on iTunes! 
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
You can also follow Steve Jones on Twitter:
