Fuad Arshad

One of my fellow DBA's ran into a problem when trying to get duplicate working for restoring the database to another server.
After we resolved the issue and learned the lesson that a simple mistake can lead to hours of rman frustration . I thought it would be interesting to document .

The problem

Duplicate development database to new development server.

Tool Used

Rman command line

Server

AIX 5.3

After the DBA took the backup and had the backup NFS mounted on the system. He was unable to run duplicate on the new node. All auxialliary setup was complete and had seemed perfect.
An Rman catalog was used and Rman kept complaining that there were no backups to restore.

We tried a couple of things

remounted the NFS with the options rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0

based on Note:424785.1 which we thought didnt work

Looked at Note:356199.1 and set event="10298 trace name context forever, level 32"

This didnt help either

The duplicate script was simple

connect target test/test@test
connect catalog abc/abc@abc
connect auxiliary aux/aux@aux
run {
duplicate target database to aux
}

The commands were being executed from the auxiliary server and network config was testedto be valid.

The Solution

The problem turned out to be that the dev database was changed to be an archivelog database and the archive logs were not backed up as part of the backup process. Rman kept generating an SCN that was in the archivelogs that it could not find in the catalog at all( I'm guessing since it was connected to the target it got the info from there).
As soon as the archive logs were backed up and made available the duplicate worked like a charm.

Moral of the Story : Rman needs less cryptic messages

Technorati Tags: oracle, backup , rman _uacct = "UA-614142-1"; urchinTracker();