SQL Server misunderstanding: About 21st days of data corruption can be solved by restarting SQL Server

Misunderstanding #21: database corruption can be solved by restarting SQL Server or Windows, or attaching and detaching a database

Error

No operation in SQL Server can repair data corruption. Damaged pages must be repaired or restored through some mechanism, but they must not be restarted by means of SQL Server, Windows, or the additional database.

In fact, if the damage to your database cannot be Crash Recovery (questioning the status), separating the additional database will be the worst decision you have made. This principle is because the attached database contains the Crash Recovery step. If the Crash Recovery fails, the addition will also fail. So the following skills are what you need: TechEd Demo: Creating, detaching, re-attaching, and fixing a suspect database. Remember, never separate corrupt databases.
The following errors may be solved through restart:

• If the pages in the memory are damaged but the pages on the disk are good, restart to solve the damage problem.
• If the page is no longer allocated due to a certain step during the restart process, the page may be damaged. The problem is solved through restart. I have already published a blog post on this issue: misconceptions und extends uptions: can they disappear?
• If I/O sub-systems are also restarted and SQL Server's I/O requirements are "stuck" by I/O sub-systems, the restart seems to be able to solve the problem, but in fact this is not a repair fault, instead, it only restores the problematic IO sub-system. I only met three or four such cases.

In any case, you should at least have a corresponding backup policy or easily implement system recovery and failover. Restarting is not a solution, which will only waste time.