The Perils of Running Database Repair

Question

Post reply

The Perils of Running Database Repair

Paul Randal

One Orange Chip

Points: 29544
More actions
June 24, 2012 at 11:30 pm

#258036

Comments posted to this topic are about the item The Perils of Running Database Repair
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 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic. Login to reply

M&M SSC-Insane Points: 21700 More actions · Answer 1

Thanks for taking your time in writing this useful article. By the by, in which language is the coding done.

M&M

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 2

If you're talking about the SQL Server database engine, Paul's said before on Twitter that it's mostly C++ with some assembler

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Geoff A SSChampion Points: 11511 More actions · Answer 3

this is a great article about the perils of using the ALLOW_DATA_LOSS command, but i would be curious to know what Pauls recommendation are for a backup strategy.

when is the best time to run DBCC checks vs when you take a full backup?

and based on the timing of those, how does one ensure not to incur data loss?

Paul Randal One Orange Chip Points: 29544 More actions · Answer 4

Glad you like the article.

Backup strategy is dictated by what restores you want to be able to do, what the data volume is, what storage space you have, and so on. If you have an RTO of 8 hours with a zer data-loss RPO, you need to be able to restore from your most recent full backup and all the way up to the most recent log backup in 8 hours. Depending on the amount of change in the database, you're likely going to be using differential backups as well. Answering this question is an entire series of articles in itself.

As far as consistency checks are concerned, if you're able to, run them on the production system as often as you can. The quicker you can find that you have corruption, the more likely you'll be able to recover with the minimum downtime and data loss. If you can't run them in production, take your full backup, restore it somewhere, and run consistency checks on it. If its clean, you know the production database was clean at the time the backup was taken. This is another article-sized answer, but I hope that helps.

Thanks

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

Geoff A SSChampion Points: 11511 More actions · Answer 5

thanks Paul,

so i take daily fulls at 2 am. I take logs every 15 minutes.

I run DBCC checks daily at 8pm and have processes in place to email me when DBCC CHECKDB encounters errors.....

so if at 8 pm, i receive an error, how does one know what logs i can restore up to?

doesn't a corrupted DB backup corrupted?

Paul Randal One Orange Chip Points: 29544 More actions · Answer 6

You don't know which logs you can restore up to. If you want to guarantee zero data loss you can't rely on just backups - you need to have a redundant copy of the database that is synchronously updating from the production database - either using synchronous database mirroring or some kind of synchronous I/O subsystem replication/mirroring. Defense in depth - just like with security.

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

Geoff A SSChampion Points: 11511 More actions · Answer 7

again, thank for clarifying that Paul...

so unless you have some hardcore redundancy, you most likely will always incur some data loss....

you can mitigate that loss by running DBCC CHECKDB often.

i have seen some recommendations on the web that you run it once a week and i was always puzzled by that strategy :hehe:

Paul Randal One Orange Chip Points: 29544 More actions · Answer 8

No, you're not guaranteed that you'll have data loss, but it's more likely. As long as you're doing frequent log backups, and you're able to do a tail-of-the-log backup, you should be able to get away without data loss as long as your full and diff backups don't contain corruption. But there's no guarantee.

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

Thomas LeBlanc SSCrazy Eights Points: 8085 More actions · Answer 9

Excellent article and thanks for answering the questions posted. It took me a couple of years and hard experience to finally upstanding the concepts of backup and restore plus database mirroring after coming from a development background. I still do not comprehend a lot of the disk mirror/replication, have to leave that to the networking/SAN group.

Thanks,

Thomas

Thomas LeBlanc, MVP Data Platform Consultant

jswong05 Hall of Fame Points: 3553 More actions · Answer 10

I still do not comprehend a lot of the disk mirror/replication

Using software like doubletake, you can replicate (copy) disk array at data-block level to another environment and keep them in synch. Only the changed data-blocks will be copied.

Jason
http://dbace.us
😛

kevin77 SSCarpal Tunnel Points: 4118 More actions · Answer 11

...we created a test system that took a known database, corrupted it randomly..

How do you manually corrupt the database?

Paul Randal One Orange Chip Points: 29544 More actions · Answer 12

There are test hooks inside SQL Server that the product group can use.

There are plenty of blog posts out there describing how to do it yourself using a hex editor - Google for me and XVI32 and you'll find one.

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

M&M SSC-Insane Points: 21700 More actions · Answer 13

...we created a test system that took a known database, corrupted it randomly..
How do you manually corrupt the database?

How to Create a Corrupt SQL Server Database [/url]

M&M

jwbrown65 Valued Member Points: 59 More actions · Answer 14

Thanks Paul. You are extremely gracious with your time on these matters. You helped me a few years ago on a discussion board covering this very topic. We used the REPAIR_ALLOW_DATA_LOSS on a db with more torn pages than an eighth grade math book (ok, not that many). We recovered and restored an old copy of the db as you've suggested here to determine the problem data was outdated. Thanks again.