Shulou(Shulou.com)06/03 Report--

Data was lost due to a failure of one of the customer's DS5020 fiber-optic storage, which used 16 hard drives to form a raid disk array. Disk 10 and 13 are offline, disk 6 is warning, data recovery is needed.

Raid disk array failure condition:

The full log state of the current storage is backed up through IBM storage manager, and the storage log from the backup is parsed to get some information about the logical volume structure. All the disks in the customer server are sorted out of the slot in a fixed order and tested, it is found that all the hard drives in the disk array except disk 6 smart status is "warning".

Disk array data recovery process:

The engineer first marked the normal hard disk in the raid array as offline under the windows environment, and then memorized all the disks. During the backup process, he found that the speed of the No. 6 hard disk was extremely slow. It was initially speculated that the reason may be due to the large number of unstable sectors and bad channels in the disk, so the equipment that specializes in mirroring the bad hard disk was replaced to mirror the No. 6 hard disk alone. At the same time, the bad channel response, waiting time and skipping bad sector data in the device are adjusted.

After the mirroring operation, all the disks mirrored by winhex on the windows platform have been mirrored. Looking at the logs generated by winhex, it is found that there are also bad channels in disk 1, which is not reported wrong in IBM storage manager/frombyte.com and hard disk SMART status, and there are a large number of irregular bad channels in disks 10 and 13. According to the list of bad channels, it is found that some key data of the file system in the disk array are in the bad channel area. So it was manually repaired by the same stripe xor of the No. 6 hard disk. With the help of the data recovery software, we expand all the data in the backed-up raid, analyze the reverse of the ext3 file system and the log files, and analyze the disk order of the raid disk array, the size of the raid block, the check direction and the check mode of the raid and other necessary information.

Through the analysis of the raid information, we virtual reorganize the raid disk array and unload the ext3 file system to extract the database files. An error occurred in the process of extracting the database file, the database reported imp-0008 error, the data recovery engineer re-analyzed the raid structure, and once again extracted the dmp file and the dbf original library file, and all the files reported no error normally.

Database data recovery process

1. Copy the database file to the original database server, and the path is / home/oracle/tmp/syntong. As a backup. An oradata folder is created under the root directory, and the entire backup syntong folder is copied to the oradata directory. Then change the group and permissions of the oradata folder and all its files.

two。 Back up the original database environment, including the related files under the product folder under ORACLE_HOME. Configure snooping to connect to the database using the splplus in the original machine. Try to start the database to the nomount state. After making a basic status query, we know that there is nothing wrong with the environment and parameter files. Try to start the database to the mount state, and 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 detection and analysis, it is determined that the fault is the inconsistency between the control file and the data file information, which is a kind of common fault caused by power outage or sudden shutdown.

4. The database files are tested one by one, and no physical damage is detected in all data files.

5. In the mount state, the control file is backed up, and alter database backup controlfile to trace as'/ backup/controlfile'; views and modifies the backup control file to obtain the command to rebuild the control file. 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 reconstruction of the control file is completed, start the database directly and report an error, which needs 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 files of the original temp tablespace to the corresponding temp tablespace.

10. Do all kinds of routine checks on the database without any errors.

11. Make an emp backup. The backup of the whole library has been completed and no error has been reported. Connect the application to the database for data verification at the application level.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.