X

Alejandro Vargas' Blog

  • February 12, 2008

Disaster Recovery Stories

Alejandro Vargas
Technical Leader, ACS Global Delivery, Infrastructure & BigData

In the last weeks I had the opportunity to work on two cases of disaster recovery.
There are a couple of lessons learned from both cases:

  1. Check your backups
  2. Backup your archived logs
  3. Make backups of the database structure (full export without data)
  4. Make backups of your controlfiles (backup controlfile to trace)
The first case was a development environment, where a month worth of work by a team of several developers was lost, despite that the database was working on archive log mode and they had cold backups.
The last backup was corrupted, and the archived logs of the next backup were missing.
The database undo tablespace and one of the data tablespace datafiles were lost.

In this case I did open the old backup to create a full database export, I used this export to create the application user objects in a new database. Then I did dump the data from the corrupted database using DUL and imported it into the new database.

The second case was related to a production clone that was periodically refreshed by an automatic job. As part of the job the metadata of one tablespace was exported in order to be able to plug-in it  back into the refreshed  database. That tablespace contained critical information and the delta of developers work.

In this case both the metadata export and the database refresh failed, the transportable tablespace datafile was left orphaned without its metadata export.

In this case I didn't have the data dictionary so the dumps of data lacked the original create table statements, the only reference I had was the object number and an old metadata export.

I did extract from this export the create table statements, linked them to its original objects dumps and imported the data. Some new objects, not contained  on the old metadata export, were left unnamed, to be identified by the owners of the application.

Is good to be able to recover  valuable data when all hope is almost  lost. But the better is to have good validated backups!

Join the discussion

Comments ( 5 )
  • Oscar Thursday, February 14, 2008
    Hi
    never heard of DUL, so I searched Metalink about it.
    I found two notes, they both state for example:
    "using the Oracle's Data Unloader (DUL), which is performed by Oracle Field Support on-site for an extra charge".
    So I assume DUL is not a free download, do I?
    Thanks
    Oscar
  • Paola Pullas Wednesday, March 5, 2008
    Hi Alejandro,
    Some time ago I hear about DUL, and I know that this is an internal tool of Oracle Corporation, can you say me if this is correct?.
    I found in Internet some tools similar to DUL. Have you testing some tool different from Oracle DUL?
    Best Regards,
  • Paola Pullas Wednesday, March 5, 2008
    Hola Alejandro,
    A tu criterio Fast Unload de CA es m�s rapido que Data Pump?
    Saludos,
    Paola
  • fiorda Wednesday, April 2, 2008
    I'm studying a disaster recovery solution for based on a storage solution.
    Our production environment is composed by an
    Oracle 10.2.0.3 RAC with 9 nodes ( SUN v40z with RHAS 3 ). Database files are on external disk devices (
    luns allocated on a EMC DMX 3000 storge system) managed by ASM. Our disaster
    recovery environment will be composed by an Oracle 10.2.0.3 RAC with only 1
    node with other disk devices ( luns allocated on another EMC DMX storage
    system) managed by ASM too.
    The question is the following:
    using any product - like EMC SRDF or EMC RecoverPoint, in our case - we can have LUNs on DR site syncronized with equivalent LUNs on production site.
    Can we open the database on disaster recovery site, with minimal effort ?
    In your experience, was a solution like this already implemeted?
    Are there any documents about this configuration ?
    Where can I find documentation ?( I searched on Metalink, Powerlink and googled but I didn't found any useful document )
    Thank you.
    Regards
  • Data backup Sunday, May 24, 2009
    So very true!! Check your backups!!!
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.