Author: Donald K.

There are areas of Oracle database recovery where the DBA could make a serious error. These mistakes are often the result of stress and poor judgment, and even Oracle Technical Support may fail to insist of these precautions.

The Oracle DBA is the custodian of the database and they must be prudent and cautious with their mission-critical system and always follow best-practices to ensure recoverability of the Oracle system.

In this article i am going to discuss the comman Oracle recovery mistakes that should be avoided to ensure proper recovery.

Not testing the recoveries:

Mostly the DBA's assume that your recovery strategy will work because it was tested a year ago. Assuming your disaster recovery strategy will work because your recovery strategy was tested successfully ever is a huge mistake.

Not monitoring the backups:

Assuming your backups are successful without monitoring.

Not storing the copies of current RDBMS:

If you keep on forgetting to store copies of the current version of your RDBMS software and other ancillary recovery oriented stuff then at the end your database will suffer.

No good backup and recovery policies:

No good backup and recovery policies.

NOARCHIVELOG database:

Backing up your NOARCHIVELOG database while it's up and running and assuming that if you have to recover from that backup that you will have Oracle find a magic way to do it

Not testing the recoveries:

The very first task of an Oracle DBA should be to back-up the corrupt database. Sadly, many Oracle shops do not test their recoveries, and in cases where you discover that your backups are not recoverable, you may be glad that you have a copy of the original corrupt database.

Using exp/imp as your primary backup tool:

Using exp/imp as your primary backup tool assuming that you can apply archived redo logs to recover the database.

Not using RMAN:

Usually DBA's are afraid of using RMAN or Making benefits of RMAN.

Not doing RTFM:

Not doing RTFM.

Less knowledge:

Mostly DBA's put it in and know how to backup but do not know how to use it to recover.

Cold backups:

For cold backups, DBAs usually provide a list of files to the unix team to backup and shut down the database. The List of files isn't updated though more datafiles are added to the database.

There is a very common Oracle backup error. When you restore the media, Oracle will not open the database because the system change numbers (SCN) in the file headers do not match.

Bad Media:

Many Oracle backups do not check the media to ensure that the database has been successfully written to the backup tape or disk. I have seen many cases where the backup writes and empty of incomplete backup, or where parity checks exist. Some shops re-read their backups to ensure against parity errors.

No Recovery:

Many shops only discover that they cannot roll-forward until they attempt a recovery. Many DBAs have lost their jobs when they must tell management that many days of work has been lost forever.

Bad hot backups:

There are many ways to perform a hot backup, and many of them will not work properly. Hot backups are tricky, and the prudent DBA will insist that the recovery from the hot backup is tested, or at least get a CYI memo from management if they refuse to test their Oracle recovery capabilities. Remember, someone IS going to be fired when a mission-critical database cannot be restored, and this memo could save your job.

Not backing up Controlfile:

Controlfile is not being backed up after a rman backup.

Error backup:

While using conventional backup; After end backup command, no log switch and no archive log backup is taken.

Problem in Tape handling and tape rotation:

Tape handling and tape rotation are also very important and I quite often see problems in that area. If tape handling is done by unmotivated people and they start cutting corners, you'll see that allthough backup procedures were good and recovery was tested, things can still go seriously wrong when the guy changing the tapes was slacking.

Not verifying every single backup:

It is a huge mistake to rely on the tape backup retention correctly for a specific time period. Suppose the yearly backup with 7-yr retention was completed successfully. Now if you don't double check this and it's wrong - you'll never know until you get audited or for whatever reason need that backup years down the road and you find that it has mysteriously disappeared. So its advised to personally verify every single backup that I need saved with a non-default retention time.

 More Oracle Articles, Database Articles and DBA Tips
   Database Security: Step by step guideline
   Best Practice for Multiple Oracle Homes!
   A Guide for Individual Objects Tuning for Databases
   Why Stored Procedures?
   A Quick Guide to determine Oracle RAM Size!!