SQL SERVER 2000 suspicious database processing

Due to the SERVER's unexpected power failure, the database on the SQL SERVER is "uncertain" and cannot be used. search online to find the following solution. Record it here:
When a database is in doubt, both the database file and the log file exist. If the database file does not exist, it must be processed separately.
1. Stop the database server and copy and back up the MDF and LDF files of the database.
2. Start the database server and delete the suspicious Database
3. Only use the backup database MDF file to append the database. sp_attach_db or sp_attach_single_file_db can append the database. The following message is displayed:
Device activation error. The physical file name 'C: \ Program Files \ Microsoft SQL Server \ MSSQL \ data \ mydb_log.ldf' may be incorrect.
You have created a new log file named 'C: \ Program Files \ Microsoft SQL Server \ MSSQL \ Data \ myDb_log.LDF.
This indicates that the database has been attached successfully and the problem has been solved. If the problem is solved successfully, congratulations. Anyway, I failed to add it, and the following error message is displayed:
The new database 'mydb' cannot be opened '. Create database will be terminated.
Device activation error. The physical file name 'E: \ www \ mydb_log.ldf' may be incorrect.
At this time, I used the following methods to solve the problem (refer to the online method ).
A. Create A database of the same name for recovery in SQL SERVER Enterprise Manager (note: the same name as the problematic database, in this example myDb ).
B. Stop the database server.
C. delete the log file myDb_log.ldf of the database you just generated (in this example, the name of the database is shown in the column and your own database name is used ), overwrite the newly generated database data file myDb_data.mdf with the mdf file of the database you just backed up.
D. Start the database server. The status of myDb in the database is "questionable ". At this time, you cannot perform any operations on this database.
E. Set the database to allow direct operation of system tables. In SQL Server Enterprise Manager, select the database Server, press the right -- key, and select "properties ", on the "Server Settings" Page, select "allow direct modification to System directories. You can also use the following statement. Use master
Go
Sp_configure 'Allow updates', 1
Go
Reconfigure with override
Go

F. Set myDb to Emergency Repair Mode
Set the following command in the query Manager: Update sysdatabases set status =-32768 where dbid = DB_ID ('mydb ')

At this time, you can see in SQL Server Enterprise Manager that the database is in "read-only, suspicious, offline, and emergency mode" to see the tables in the database, but only the system tables
G. Execute the true recovery operation below to recreate the database log file. Dbcc rebuild_log ('mydb', 'c: \ Program Files \ Microsoft SQL Server \ MSSQL \ Data \ mydb_log.ldf ')

Warning: the log of the database 'mydb' has been rebuilt. Transaction consistency is lost. Dbcc checkdb should be run to verify physical consistency. The database must be reset and redundant log files may need to be deleted.
DBCC execution is complete. If DBCC outputs an error message, contact the system administrator.
In SQL Server Enterprise Manager, you can see that the database status is "only for DBO ". Now you can access the user tables in the database.
H. Verify Database Consistency (omitted) Dbcc checkdb ('mydb ')

The general execution result is as follows:
CHECKDB finds 0 allocation errors and 0 consistency errors (in database 'mydb ).
DBCC execution is complete. If DBCC outputs an error message, contact the system administrator.
I. Set the database to normal Sp_dboption 'mydb', 'dbo use only', 'false'

J. In the last step, we need to restore the "allow direct modification to the system directory" set in Step E. It is dangerous to directly operate system tables. Of course, we can recover the data in SQL Server Enterprise Manager or use the following statement. Sp_configure 'Allow updates', 0
Go
Reconfigure with override
Go

This database undoubtedly solves the problem.