Server raid5 data recovery success stories, disk array data recovery methods, raid5 success stories
[Introduction to physical servers and logical Storage]
The customer uses an IBM 3850 server and four RAID 5 disk arrays made of 300 gb sas disks. The server operating system is Windows x64 and runs a single-node Oracle version of 11.2.0.2. The data is stored as a file system and is not archived. This oracle data volume is small. There is only one user in oracle to create. The default users tablespace is used. There is only one data file in the users tablespace, which is less than 1 GB in size.
[Server fault symptom]
Due to heavy loads and problems with the underlying RAID disk array, you have performed a series of RAID reconstruction operations to save data, and then aborted RAID initialization due to a disk failure, however, a small amount of data is synchronized, And the RAID disk array is accessible,
Although the system has an error, it can be started normally, but the disk D, that is, the partition where the oracle database is located, cannot be opened. The chkdsk can be opened normally, but oracle cannot be started, the customer reinstalls the oracle System on the original disk and imports the dmp files backed up previously, but the data is too bad.
[Data recovery process]
After the customer contacts the Beijing data recovery center, the data recovery center arranges Oracle data recovery engineers and server data recovery engineers to come to the customer's site for recovery at the same time.
First, we analyze the RAID layer: rebuilding RAID will cause the most serious damage. However, we find that the size and disk sequence of the RAID are the same as those of the original RAID, during initialization, only a small amount of data is synchronized to the front. The RAID layer is not damaged, and the database is not damaged yet.
Then, the Administrator analyzed the damage caused by chkdsk partition and oracle system reinstallation and dmp File Import: Chkdsk does not damage the user data zone, and chkdsk only modifies the metadata zone of the file system. At this time, the database file is still not damaged. At most, the MFT or directory item of the file is damaged. The most serious issue is to reinstall the Oracle System and import the dmp file. This not only damages the file system metadata zone, but also overwrites the user data zone.
Step 3: analyze the NTFS file system of the D Drive: It is found that the MFT of all the original oracle data files is overwritten, And the NTFS logs are also overwritten early in the cycle, and unavailable information is found from the NTFS metadata area. You can only use the Oracle restoration program in the data recovery center to restore the entire partition. After scanning, it is found that the Oracle instance is ANSORA. A raw and complete control file and an original and complete undotbs tablespace data file are scanned, important system and users tablespace data files are damaged to varying degrees,
The data file in the system tablespace is only 10 MB at the middle and back ends, and the original data file should be about 700 MB. Some data files in the users tablespace are also overwritten, but only 4 MB. Extract and find the data, and then repair the seriously damaged database.
Because the system tablespace is unavailable, the data dictionary cannot be obtained. After communicating with the customer, the customer confirmed the three important tables, which are also large, the structure of the three tables is obtained from the database returned by the customer imp, and the corresponding segment is found in the data file for restoring the users tablespace. However, one table cannot correspond to each other, ask the customer again, the customer said that this table has been changed the field operation, and then build a new table structure corresponding to the segment in the users tablespace data file, then, the data of these three tables is extracted using the oracle dul tool. After the customer verifies the data, the data is no longer faulty.
[Data recovery result]It takes three days for the user to specify that more than 99% of the data is successfully restored. <