SQL Server attached Database Error 823 Solution

1. An error occurred while attaching the database to SQL Server.
1. Exception: when the server is running normally, a sudden power failure causes damage to the database file. The specific performance is as follows: the database name is followed by the word "(suspect.
2. Exception analysis: help on the 823 error SQL-SERVER:
======================================

Error 823
Severity Level 24
Message Body
In File "% 4! "Offset % 3! % 2! I/O error % 1! was detected during the process !.

Explanation
Microsoft SQL Server encounters an I/O error when reading or writing requests to a device. This error usually indicates a disk issue. However, other core messages recorded before error 823 in the error log should indicate the device involved.
3. solution:
In the SQL-Server Enterprise Manager, after creating a database with the same name (test is assumed here), stop the database and corrupt the database file data. MDF and test_log.ldf overwrite the data under the newly created database directory. MDF and test_log.ldf, and delete the test_log.ldf file at the same time. Start the Database Service and find that the database name "test" is followed by "Doubt. It doesn't matter. Open the SQL built-in query analyzer and execute the following SQL statements:
First,
Exec sp_configure 'Allow updates', 1 reconfigure with override/* Turn on the system table modification switch */
Second,
Update sysdatabases set status = 32768 where name = 'database name'/* set database status */
Third,
DBCC rebuild_log ('database name', 'd: \ database \ test_log.ldf')/* rebuilding the LDF file */
Fourth,
Update sysdatabases set status = 0 where name = 'database name'/* reset database status */
Fifth,
Restore database name with recovery/* Restore database */
Sixth,
Exec sp_configure 'Allow updates', 0 reconfigure with override/* disable the system table modification switch */
Follow these steps to restore normal database access. If the problem persists, the most stupid method is to create another database and export the data of each table in the original database (TEST) to the new database table.
========================================================== ================================
Note: The above six steps have solved the problem of database doubt, but there is still a corrupted table (inf_gdscode) in the database table, and the export of bad tables fails. Finally, run the following command in the query Analyzer:

Use nmgbt_hcxuexipos (database name)
Go
DBCC checktable ('inf _ gdscode', repair_allow_data_loss)
Go