11gr2 DataGuard: Restarting DUPLICATE After a Failure

One of the great new features that comes in very handy when databases get larger and larger these days is RMAN's capability to duplicate from an active database and even restart a duplicate when it fails.

Imagine yourself the problem I had lately; I used the duplicate from active database feature and had to wait for an hour or 6 before all datafiles where transferred.At the end of the process some error occurred because of the syntax. While this error was easily to solve I was afraid I had to redo the complete procedure and transfer the 2.5 TB again.
Well, 11gr2 RMAN surprised me when I re-ran my command with the following output:


Using previous duplicated file +DATA/fin2prod/datafile/users.2968.719237649 for datafile 12 with checkpoint SCN of 183289288148
Using previous duplicated file +DATA/fin2prod/datafile/users.2703.719237975 for datafile 13 with checkpoint SCN of 183289295823

Above I only show a small snippet, but what happend is that RMAN smartly skipped all files that where already transferred !

The documentation says this:
RMAN automatically optimizes a DUPLICATE command that is a repeat of a previously failed DUPLICATE command. The repeat DUPLICATE command notices which datafiles were successfully copied earlier and does not copy them again. This applies to all forms of duplication, whether they are backup-based (with and without a target connection) or active database duplication. The automatic optimization of the DUPLICATE command can be especially useful when a failure occurs during the duplication of very large databases.
If a DUPLICATE operation fails, you need only run the DUPLICATE again, using the same parameters contained in the original DUPLICATE command.

Please see chapter 23 of the 11g Release 2 Database Backup and Recovery User's Guide for more details.

B.w.t. be very careful with the duplicate command. A small mistake in one of the 'convert' parameters can potentially overwrite your target's controlfile without prompting !

Rene Kundersma
Technical Architect
Oracle Technology Services

Comments:

Thank you! This is good info..I did validate it by aborting an cloning process and restarting.

using the command: duplicate target database for standby from active database dorecover spfile....;

In my case, I'm cloning to a remote system to building DG and it would take 12+ days to complete the process due to the network bandwidth. I'm staging all the archivelogs to a secondary storage device in the primary site which I need to transfer as well...When RMAN done with cloning where does it expect the archivelog files to be in? DR Server log_archive_dest_1 ? Do I have an opportunity to copy the archivelog files in batches and restart the process? I do not have any other environment to test this. Please let me know if you have gone through the scenario.

Thanks

Posted by guest on February 21, 2014 at 12:46 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Blog of Rene Kundersma, Principal Member of Technical Staff at Oracle Development USA. I am designing and evaluating solutions and best practices around database MAA focused on Exadata. This involves HA, backup/recovery, migration and database consolidation and upgrades on Exadata. Opinions are my own and not necessarily those of Oracle Corporation. See http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
23
24
25
26
27
28
29
30
   
       
Today