SQL Server misunderstanding 30th about the 16th day of data damage and repair _mssql

Misunderstanding #16: Multiple data corruption and repair errors

Many of the popular versions are incorrect.

I've heard a lot about what data fixes can do, what not to do, what can cause data corruption, and whether the damage can go away on its own. In fact, I have written a lot of posts for this kind of problem, so this blog can be a "gossip Terminator" to make a summary, I hope you can reap.

First of all, I've written a blog post about what you can and can't do with data repair misconceptions around database repair covers 13 myths-never use DBCC CHECKDB to fix errors (of course not) to Repair_ Whether Allow_data_loss will cause data loss (the name is really confusing).

Second, many people complain that the errors displayed by DBCC CHECKDB the first time they run will disappear on their own. This is a good explanation: the error page that was detected by DBCC CHECKDB for the first time is no longer part of the page allocation set and is therefore not displayed when the DBCC is run the second time. I have a blog post to explain this in detail: misconceptions around Corruptions:can they disappear?

There is also a widespread rumor that long-running operations (such as index rebuilding, bulk data insertion, database or file shrinkage) can cause page corruption. In fact, unless there is a bug in SQL Server (very rare). There are no T-SQL statements that can cause data errors. I wrote an article a few years ago to explain this in detail: Search Engine q&a #26: Myths around causing corruption.

I hope this article will help to clarify this concept.