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
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
No comments:
Post a Comment