RAID disk array data recovery-database repair process

A customer's DS5020 fiber storage failure results in data loss, which uses 16 hard disks to form a RAID disk array. The 10th and 13th dials are dropped, and the number 6th warns that data recovery is required.

RAID disk array failure conditions:
The full log state of the current store is backed up by IBM Storage Manager, and the stored logs that are backed up are partially information about the logical volume structure. All disks in the client server are sorted in a fixed order to move out of the slot to test that the disk array is normal except for the 6th-number drive with the smart status "warning".

Disk array Data recovery process:
The engineer first in the Windows environment in the RAID array in the normal state of the hard disk marked offline, and then all the memory of the disk operation, in the backup process found that the speed of the 6th drive is unusually slow, the initial speculation may be due to the disk in the unstable sectors and bad lanes more caused by the Instead, the device that mirrors the bad drive is replaced by a separate mirror operation on the 6th Drive, which adjusts the device for bad response, wait time, and skip bad sector data.

After mirroring, the disks using the Winhex mirror under the Windows platform have all been mirrored, viewing the logs generated by Winhex, and discovering the IBM storage manager/ Frombyte.com and hard drive smart status, there are no errors in the number 1th, there are bad lanes, 10th and 13th, there are a large number of irregular bad distribution, according to the bad path list to target image file analysis found that the disk array file system part of the key data in the bad lane, and then to the same stripe with the 6th hard drive XOR Manual Repair Complex. We use data recovery software to expand all the data in the backed up raid, analyze the reverse of the Ext3 file system, and analyze the log files to analyse the necessary information such as the disk sequence of the RAID disk array, the size of the RAID block, the check direction of the raid, and the check mode.
Through the analysis of the RAID information virtual reorganization RAID disk array and the Ext3 file system to extract the database files. In the database file extraction process error, the database report imp-0008 errors, data recovery engineer re-analysis of the RAID structure, once again the DMP files and DBF original library files to extract, all files normal without error.

Database Data recovery process
1. Copy the database file to the original database server, the path is/home/oracle/tmp/syntong. As a backup. A Oradata folder is created under the root directory and the entire Syntong folder of the backup is copied to the Oradata directory. Then change the group and permissions for the Oradata folder and all of its files.
2. Back up the original database environment, including the related files under the Product folder under Oracle_home. Configure the listener to connect to the database using the Splplus in the original machine. Try to start the database to the Nomount state. After you make a basic status query, you have no problem understanding the environment and the parameter files. Try to start the database to mount state, there is no problem with the status query. Start the database to the open state. An error occurred:

ORA-01122: database file 1 failed verification check/frombyte.comORA-01110: data file 1: ‘/oradata/syntong/system01.dbf‘ORA-01207: file is more recent than control file - old control file

3. After further testing and analysis, it is judged that this fault is inconsistent with the control file and data file information, which is a kind of common fault caused by power failure or abrupt shutdown.
4. The database file is detected individually, and all data files are detected without physical damage.
5. In the Mount state, the control file is backed up, ALTER DATABASE backup Controlfile to trace as '/backup/controlfile '; the control file for the backup is viewed and modified, Gets the Rebuild control file command. Copy these commands into a new script file, Controlfile.sql.
6. Close the database and delete the 3 control files under/oradata/syntong/. Start the database to the Nomount state and execute the Controlfile.sql script.

SQL>startup nomount/frombyte.comSQL>@controlfile.sql

7. After the completion of the reconstruction control file, directly start the database, error, need further processing.

SQL> alter database open;alter database open/frombyte.com*ERROR at line 1:ORA-01113: file 1 needs media recoveryORA-01110: data file 1: ‘/free/oracle/oradata/orcl/system01.dbf‘

Then execute the RESTORE command:

recover database using backup controlfile until cancel;Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log…

Do the media recovery until the report is returned and the recovery is complete.
8. Try the Open database.
sql> ALTER DATABASE open resetlogs;
9. The database started successfully. Add the data file of the original temp table space to the corresponding temp table space.
10. Perform various routine checks on the database without any errors.
11. Perform an EMP backup. Full library backup complete, no error. Connect your application to the database for application-level data validation.

RAID disk array data recovery-database repair process