March 13, 2013 at 9:46 pm
Comments posted to this topic are about the item The Gambler
March 13, 2013 at 10:51 pm
It's a good point Steve, just like insurance. I hate paying exorbitant premiums but am always grateful that I did for the rare circumstance, where I need to make a claim.
Running checks on your database is insurance against loss of profit or even loss of the entire business. If you hope that your db is not corrupted and it is, you may also find that your backups are corrupt as well.
So ask yourself what impact total data loss will have on your business. If the impact is trivial then maybe you don't need to worry.
March 14, 2013 at 12:35 am
Very good point Steve. Checkdb is insurance. I just ran into two clients (new) in the same day with some level of corruption in their databases. Neither had been running checkdb against the databases in question. And neither had a corruption free backup (one had no backups since 2008 for the database). Those were the types of things I got to remedy today. The lack of checkdb and lack of backup is a gamble that could cripple an organization - depending on the criticality of data in the database.
Don't take that risk - just not worth it.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 14, 2013 at 1:42 am
Slight hitch in the analogy - insurance payments cost something. Running DBCC checks costs nothing. What did this clown think he was saving by avoiding DBCC checks? A couple seconds of his own time to glance at the results? A few milliwatts of processor power? Wear and tear on his drives from some disk reads?
Claiming that "we've never had a problem" is pretty lame reasoning when part of the job is the ensure that problems don't crop up. I'm with you, Steve - I'd likely fire someone who displayed such a cavalier attitude towards system safety. Shitcanning a lax DBA is a sound problem-prevention technique on the part of a careful and conscientious manager, just like running DBCC is problem-prevention technique on the part of a good DBA.
March 14, 2013 at 1:53 am
Hi Steve,
We also almost never run CHECKDB.
This is because it takes tooooooo long.
I'm taking something above 50 hours.
When we restore a backup onto our test system, the normal procedure is to run CHECKDB, if time permits.
I would like to be able to run something that does the same thing as CHECKDB, but concurrently with the normal daily processing.
Do you know of such a thing?
Best regards,
Henrik Staun Poulsen
Stovi Software
March 14, 2013 at 3:12 am
With most of the people here - just because you haven't seen it doesn't mean it can't / won't happen to you.
I wonder if they would take the same approach to backups?
-------------------------------Posting Data Etiquette - Jeff Moden [/url]Smart way to ask a question
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand (the world). There is no such thing as a dumb question. ― Carl Sagan
I would never join a club that would allow me as a member - Groucho Marx
March 14, 2013 at 5:30 am
henrik staun poulsen (3/14/2013)
Hi Steve,We also almost never run CHECKDB.
This is because it takes tooooooo long.
I'm taking something above 50 hours.
When we restore a backup onto our test system, the normal procedure is to run CHECKDB, if time permits.
I would like to be able to run something that does the same thing as CHECKDB, but concurrently with the normal daily processing.
Do you know of such a thing?
Best regards,
Henrik Staun Poulsen
Stovi Software
I believe SQL Skills http://www.sqlskills.com provide consultancy on tailoring checks on VLDB systems. Gail Shaw aka Gilamonster and http://www.brentozar.com/ also provide consultancy and training for VLDB, although I'm not sure about this specific topic
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
March 14, 2013 at 8:09 am
Our DB2/LUW DBAs laughed at our hours of consistency checks, thinking it was an artifact of MSSQL.
Unfortunately, vindication came early this year, when their entire data warehouse had to be restored to recover a table lost to corruption.
March 14, 2013 at 8:27 am
You guys are concentrating on the wrong thing here. it is not running DBCC consistency checks regularly on your database that is the real issue of importancy here. Most competent and veteran DBA's are doing this anyway. It is the rash and foolish actions that many take after they see the results of running DBCC checks that make things much much worse. First thing. don't panic and do something stupid after looking at the results of a DBCC command!!! Paul Randal talks about this constsntly ad nauseum in his seminars and on his blogs. He wrote DBCC CHECKDB so believe me he would know. DBCC CHECKDB is a powerful tool, but it is also very dangerous in the wrong hands. There is a great article below on the use and abuse of DBCC. Also, to the VLDB issue, you can run DBCC CHECKFILEGROUP on the INDIVIDUAL filegroups (which you should be using on a VLDB anyway) which cuts that VLDB up into smaller more manageable chunks..Justifying not performing a DBCC check because the database is just too big and takes too long is foolish and lazy IMHO. HTH. 😀
http://www.sql-server-pro.com/dbcc-checkdb.html
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
March 14, 2013 at 9:19 am
henrik staun poulsen (3/14/2013)
Hi Steve,We also almost never run CHECKDB.
This is because it takes tooooooo long.
I'm taking something above 50 hours.
When we restore a backup onto our test system, the normal procedure is to run CHECKDB, if time permits.
I would like to be able to run something that does the same thing as CHECKDB, but concurrently with the normal daily processing.
Do you know of such a thing?
Best regards,
Henrik Staun Poulsen
Stovi Software
You can run physical only, which does some checks, but not all of it.
The only solution is to really get a good second box and throw some horsepower on it. I'd try to run it every week.
The other thing which is a "cheap" check, but is semi-safe for me, is to run a SELECT * from all tables and if they all complete, at least you have all your data accessible.
March 14, 2013 at 9:49 am
Everyone's way is right in their own eyes, but every man pays the price for their lack of vision. If there are protections to take advantage of and one chooses not to take them, their lack of wisdom is only slightly larger then their pride. 🙂
Not all gray hairs are Dinosaurs!
March 14, 2013 at 10:53 am
TravisDBA (3/14/2013)
Also, to the VLDB issue, you can run DBCC CHECKFILEGROUP on the INDIVIDUAL filegroups (which you should be using on a VLDB anyway) which cuts that VLDB up into smaller more manageable chunks..J
Will checking individual filegroups reduce the 50 hours that he currently needs?
March 14, 2013 at 11:30 am
johnbrown105 56149 (3/14/2013)
TravisDBA (3/14/2013)
Also, to the VLDB issue, you can run DBCC CHECKFILEGROUP on the INDIVIDUAL filegroups (which you should be using on a VLDB anyway) which cuts that VLDB up into smaller more manageable chunks..JWill checking individual filegroups reduce the 50 hours that he currently needs?
The idea of using DBCC CHECKFILEGROUP instead of using DBCC CHECKDB at one time is to use a "divide and conquer" approach to check the integrity of one file group each night of the week, for example. In this way, you address the issue of a DBCC checkdb taking all day to complete and the "sum of the whole" times is probably in most cases going to take a lot less total time. But even if it didn't, let's just say for argument sake, that is still no reason, not to do it at all.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
March 14, 2013 at 1:14 pm
A lot of good points here. But there is always the option of running DBCC on a mirror or restored copy of the database. Now this is going to cost money, for the storage, server and license. But here is where the DBA can prove his/her value to the business by identifying the cost, and presenting the information to his/her management.
March 14, 2013 at 1:34 pm
Hello,
We run DBCC everywhere.... but I guess it's not enough to run it if we don't look at the results.
My group provides outsourcing IT services, and we support over 1,500 databases on 100 serves, across different domains and networks for this single customer.
We use the Maintenance Plans to run DBCC, as part of the standard plans, but I'm pretty sure we don't look at the results.
Does anyone know how to automate the sending of any errors on DBCC?
How can I create a test database that has corruption to test it out?
Thanks
Miguel
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply