General SQL Server database recovery steps after doubt

-- General SQL Server database recovery steps after doubt
-- 1. Recovery steps:
-- A. Back up the smlog_log.ldf file to another directory;
-- B. Rename the smlog_log.ldf file in the source directory to smlog_log_bak.ldf;
-- C. Execute the following statement to modify the database status:
Use master
Go
Update sysdatabases set status = 32768 where name = 'database name' -- modify the status and set it to emergency
Go
Shutdown with Nowait -- stop the Database Server
Go
-- D. Exit the SQL statement and run the following command in command line mode: Code Restart SQL:
Sqlservr-C-t3608-t4022 -- enable SQL Server in Safe Mode
-- E. Execute the following statement in the query analyzer to view the database status that has just been modified:
Select name, status from sysdatabases where name = 'database name done'
-- F. Run the following code to create a log file:
DBCC traceon (3604) -- tracking
DBCC rebuild_log ('database name', 'Log file full path') -- the file name must have a full path and extension.
-- DBCC rebuild_log ('prs _ MSC ', 'd: \ mscsql \ MSSQL \ data \ prs_msc_log.ldf
-- G. Set the database back to normal:
Update sysdatabases set status = 0 where name = 'database name'
-- H. Run the following statement to check the database after restarting the database:
DBCC checkdb -- if an error occurs after execution, use the following statement to fix it:
-- I. To fix the database, you must change the database to the single-user mode:
Exce sp_dboption 'database name', 'single user', 'true' --- ('false' restores multiple users)
-- J. Execute the following statement to restore the database:
DBCC checkdb ('database name', repair_allow_data_loss)
Repair_allow_data_loss: a relatively advanced repair method.
Repair_fast: A simple and quick solution.
/*

The processing status is a "suspicious" database.
Back up the data file and follow these steps:
1. Create a database with the same name (the data file must be consistent with the original one)
2. Stop SQL server again (do not detach the database)
3. overwrite the new database with the data file of the original database.
4. Restart SQL Server.
5. When you open the Enterprise Manager, there will be a doubt. Ignore it and execute the following statement (note that you must modify the database name)
6. after completion, You can generally access the data in the database. In this case, the database itself is still problematic. The solution is to create a new database using the database script, and export the data.

*/
Use master
Go
Sp_configure 'Allow updates', 1
Go
Reconfigure with override
Go
Update sysdatabases set status = 32768 where name = 'suspicious database name'
Go
Sp_dboption 'questionable database name', 'single user', 'true'
Go
DBCC checkdb ('questionable database name ')
Go
Update sysdatabases set status = 28 where name = 'questionable database name'
Go
Sp_configure 'Allow updates', 0
Go
Reconfigure with override
Go
Sp_dboption 'questionable database name', 'single user', 'false'
Go