Data Backup and Recovery

SMO and redo logs

seno
2,896 Views

Hi,

 

Before starting, I'll be upfront and say that I'm not the DBA in this situation and probably don't know all the ins and outs of Oracle, but ...

 

We are testing SMO 3.1 (Linux) to see if it is something we want to use.  I have created 3 volumes on the NetApp side and exported them to the database host via NFS (no iSCSI or FC luns).

 

/vol/testdb_data

/vol/testdb_log

/vol/testdb_arch

 

It's pretty clear from the names that the DB is in "data", the redo logs are in "log" and "arch" is where we put the control files.  The Binaries are in a separate admin volume.

 

When running a backup via SMO, it will snapshot the _data and _arch volumes, but not touch the _log volume.  We have found references in the NetApp docs and KB that SMO doesn't back up the redo log.

 

Is this necessary to backup (snapshot) the redo log volume at the same time as the data and control files?  If so, has anyone else employed a workaround for this?

1 ACCEPTED SOLUTION

lukasz_borek
2,896 Views

No, you don't need make redo volume snapshot when databse is in *BACKUP* state. Rado will be used in case of Oracle recovery only (when you have consistend database status and you put arch on that). You can use volume based snapshots (and mount .snapshot directory in case of recovery) or  snapvault/snapmirror relaionship.

View solution in original post

2 REPLIES 2

lukasz_borek
2,897 Views

No, you don't need make redo volume snapshot when databse is in *BACKUP* state. Rado will be used in case of Oracle recovery only (when you have consistend database status and you put arch on that). You can use volume based snapshots (and mount .snapshot directory in case of recovery) or  snapvault/snapmirror relaionship.

seno
2,896 Views

Sure enough.  It came down to the way the DBA's have to start up the DB to recover it.  They have to tell it to ignore the redo logs that are newer than the data files and start with new redo logs.  In our old way of backing up DB's, this wasn't an issue since we snapped the redo log vol with all the others and restored it with all the others thus matching the timestamps.  Even though there was no data in the redo logs that wasn't already in the DB.

Now on to protection and cloning!

Public