The implementation process of the data recovery scheme that the SqlServer database cannot be read

1. Overview of database failure The
data in the SQL server database cannot be read.

2. Failure analysis
The SQL server database file cannot be read because the underlying File Record is truncated to 0, the beginning of the file cannot be found, and the data table structure is also damaged. The space of about 80M in front of the image file and the middle part are overwritten, which causes the system table to be damaged, so it cannot be read. Consider using an automatic backup file to extract the table structure.
 Operation records in the log:

Because the system tables are damaged, the structure of a large number of data tables cannot be determined, and the recovery work can only be performed by engineers based on experience.

3. The solution
backs up user data to the hard disk of lost data. Do a full backup to ensure data security.
A database that analyzes old data in backup files.
Find the structure of the data table from the old database.
Extract the structure of a part of the data table from the log.
Extract intact data from logs and residual data.
Restore the corresponding data according to the log, and check whether the data is correct.
All data is restored after verifying that the data is OK.

4. Data recovery implementation process
4.1 Backup user data
Since all the data is stored in the original disk of the customer, first hand it over to the hardware department to check whether the hard disk is physically faulty. After testing, make a full disk image for each hard disk, and use a special tool to mirror all sectors in the hard disk to a backup hard disk.
4.2 Scan the image file
Open the residual file with winhex, carefully analyze the underlying data of the hard disk, and find that there are still many logs and backup files of the previous SQL server in the underlying hard disk. After careful inspection and analysis, it is found that there are many operation records of the database including insert statements in the log, and these records can be considered for extraction. There are also backup files. When you open the backup file, you can find that there are table building statements and some old data.
However, because the entire hard disk is too large, it will be very slow to manually search for SQL server-related data. Therefore, write a small program to extract database-related data, scan all existing database residues in the entire hard disk, and extract all data.
4.3 Analyze scan data Analyze
all the scanned log files and find that the log files are also divided into data pages with a fixed beginning and end. Each piece of data has its own object ID number in a fixed position. Scan the file, continue to search for data records with the same object Id, and find that the structure is the same. It can be determined that this is intact data and can be extracted.
After analyzing the scanned backup file, it is found that many table building statements can be extracted from it, and a part of the table structure can be obtained. For the remaining table structure, since the part truncated to 0 happens to be in the system table, there is no way to extract the table structure, and the table structure and data type can only be guessed from the data extracted from the log.
4.4 Extracting data
According to the conclusion of the previous analysis, first write a program to extract the table building statement from the backup file, analyze the table structure and various data types according to the table building statement, and find the 22H, 07H, 05H tables in the remaining system tables, The corresponding relationship between the table and OBJECT_ID is established according to these. Then write a new program to extract the records in the log (I couldn't parse the bytecode of numeric type into data at this step, so I got stuck), correspond the data to the table according to the object ID, and insert it into in the new table.
4.5 Verify that all data are
verified, and the new table recovered from the data is basically consistent with the manually observed data.
Data recovery was successful.