We might not hear so much of SQL Server database corruption anymore, but they are still happening across data centers. Companies that keep their data only in the cloud might be protected from it, but others still cannot really afford to let their guards down. If you have SQL server databases, it’s critical that you run consistency checks now and again to avoid corruption.
A simple storage failure can corrupt your database in the SQL server. And given that an SQL server natively has no way of isolating a corrupt database from a good one, it will backup both without prompting. Now there are a bunch of solutions in the market that will tell you that they can fix the issue, but most of them don’t live up to the expectations.
So what’s the way around SQL database corruption? Like with all databases, metadata management is pivotal with SQL server databases. Ideally, one should run consistency checks while loading data and as frequently as backups are taken. Retain backups at the frequency of 6 months at least and you should be good.
Joey D’Antoni, a Field Day delegate, talks about this in details on his blog “Fixing SQL Server Database Corruption (when you get lucky)” where he shines light on database corruption and how to get out of one. He writes,
First things first–if you are reading this, and not regularly running consistency checks on your SQL Server databases, you should drop everything you are doing and go do that. What do I mean by regularly? In my opinion, based on years of experience, you should run DBCC CHECKDB at least as frequently as you take a full backup.
To learn how to avoid and fix SQL databases, read the rest of his article- Fixing SQL Server Database Corruption (when you get lucky) on The SQL Herald.
