Oracle Database Recovery without RMAN backup

Current situation of the industry

“The database is either collapsed or on the way to collapse”. For the data system, nothing is more important than the data backup, however, the data backup cannot be normally used for recovering the database in some circumstances:
● Completely have no data backup;
● The data backup is invalid, there is no supervision, or there is no complete data recovery practice mechanism, so it is helpless for the data recovery;
● There is valid data backup, but the time for completely recovering the data with the data backup is too long, and the requirement on the business recovery time cannot be met

Response scenes

Our Oracle ODU team has professional data recovery ability, and when the database of the user is damaged, we can help the customer to maximally complete the data recovery in the abnormal circumstance. These accidents may include:

1. Storage faults, including the following fault scenes:

Damage of hard disks and damage of Raid information Damage of ASM diskgroup diskheadermetadata The hard disk is damaged due to formatting and cannot be started Multiple hard disks in the Raid group are damaged File is deleted due to mis-operation

2. Database faults, including the following scenes:

Database cannot be opened Files are lost, the SYSTEM table space is damaged Various Ora-600 errors Mis-operation of data files or table space Offline files cannot be loaded Lack of archived logs Delete tables, fields and data by mis-operation Mis-operation on the table space and the data files


ODU successful recovery cases:

ODU has already helped many people many times to recover their Oracle databases all over the world. There are so many reasons such as hardware problems, power-down, human operation error and lack of timely database backup can cause the Oracle database corruption or data loss. In such circumstances, the powerful function and convenient characteristic of ODU can provide a timely and efficient way to recover the data from the affected Oracle database.

The following are some of the typical successful ODU recovery cases. Please note that the similar repeating recovery cases are not listed. Due to the customer privacy, we do not describe these cases in detail, while respecting the requirements for some customers, part of the cases are not listed.

·In April 2014, ODU helped a American Fortune 500 company to successfully recover their accidentally deleted data completely. Due to the error operation, all the data from this customer’s one core table (with BLOB column, to store important excel files) was accidentally deleted. This customer tried flashback, logminer and found both of them were unable to recover the deleted data, and what is worse, more than 98% percent of the delete data’s offsets of corresponding row directory in this table were completely cleared by Oracle, under such an extreme circumstance, ODU helped this customer successfully recovered all the non-overwritten deleted data completely.

·In February 2014, ODU completed a successful recovery of a core ERP system’s database. Due to the maintenance personnel’s error operation, the diskgroup’s file directory was totally cleared (the maintenance personnel aborted the add disk operation where towards an existing ASM diskgroup, emptied the ASM disk header and then recreated the ASM diskgroup). ODU scanned all the ASM disks of the above ASM diskgroup and fully extracted all the datafiles where stored key business data in that diskgroup, and finally recovered all the data.

·In March 2012, ODU successfully helped a customer to recover the accidental truncated table which contains a BLOB column. Due to the operational errors, the system maintenance personnel truncated an important table during the manual data maintenance job, while they don’t have any database backup. This table contains a BLOB column which is used to store number of important documents, the size of each document is more than a few hundred KB. To make matters worse, they insert a small amount of data into the truncated table after the truncate operation, the database has maintained in running state at the same time and the tablespace where the truncated table resides is also ONLINE. That means the associated LOB index of that LOB column has been destroyed (due to the truncate mechanism in Oracle), while the original data has been partially overwritten. In such extreme situation, we still succeeded in recovering most of the data, including BLOB data by using ODU.

·In February 2012, ODU successfully helped a customer to recover the data of their ERP system. Due to hardware failure, the Oracle database SYSTEM tablespace datafiles of the customers’ ERP system are missing, the customer spent a night to use ODU to recover the data successfully.

·In February 2012, ODU successfully helped a customer to recover their core system database which locates in ASM. Due to the storage failure, the Oracle database of customers’ core system is corrupted, and the database is resides on ASM. They use ODU to successfully recover the data completely.

·In January 2012, ODU successfully helped a customer to recover the multiple dropped users’ data. Due to the operating errors, the maintenance personnel dropped multiple users of their production database. Fortunately, they shut down the database in a timely manner, so that the deleted data has not been overwritten, and they use ODU to recover the multiple dropped users’ data finally.

·In January 2012, ODU successfully helped a customer to recover their critical data. Due to the hardware failure, the customer’s RAID is damaged, after they extracted Oracle datafiles from the damaged RAID, they found that there exist a lot of corrupted blocks in the Oracle datafiles. In such circumstances, they use ODU to successfully recover their critical data.

·In December 2011, ODU successfully helped a customer to recover the lost data of 0 bytes datafile due to the power-down. Due to the database server power-down, the check disk utility which is running automatically corrupted a datafile after the customer reboot the operating system (Windows), that datafile appears to be 0 bytes, the file-based recovery tools can not restore that file successfully (because the state of that file seems to be in the normal state). Finally, they use ODU to successfully locate and recover the lost data of that 0 bytes datafile by scanning the disk.

·In November 2011, ODU helped a customer in Denmark to successfully recover the 140GB CLOB data where the associated lob index is corrupted.Because the associated lob index has corrupted blocks, the customer’s CLOB column can not be used normally. They use ODU to successfully recover the 140GB CLOB data, the system is back to normal.

·In October 2011, ODU helped a customer to successfully recover their financial system data. Due to the hard disk failure, all datafiles of that customer’s financial system database have a large number of corrupted blocks, the database can not be opened anymore. Finally, they use ODU to recover most of their financial system data successfully.

·In July 2011, ODU helped a customer to successfully recover the abnormal data due to the file system corruption. The file system in the client’s system is corrupted, the contents of the two datafiles are actually two online log files. In such extreme situation, they use ODU to successfully recover all of the abnormal data by scanning the disk.

Contact us:

We will reply in 20 minutes!