- Posted by Gavin Soorma
- On June 25, 2010
- 11 Comments
I have added a few more RMAN recovery scenarios which I have come across recently and may be faced by others – so thought I’d share those with the community.
The first relates to a case where we need to create a replica of a production database on a test or development environment and we are not able to use the RMAN DUPLICATE DATABASE command because there is no network connectivity between the production and the test servers. This is very possible in cases where due to security restrictions production is on an isolated network from test or dev or there may be firewall rules in place which prevent the RMAN auxiliary channel connections (required for the duplicate) from working.
Further, we may be faced with a situation where for some kind of testing, we need the target database to be in sync with the source production database to a point in time as recent as possible. So we will need to recover the database to point in time beyond which the RMAN database backup on production was taken.
More about this …..
The second case related to a situation where for testing Disaster Recovery procedures we need to restore the full database backup on another machine provided for the purpose and point the client application to this restored backup to test the same.
Even from the point of view of best practices, while the RMAN RESTORE VALIDATE command is good to check validity of backups on a regular basis, there is no substitute to actually having the luxury of time and disk space to test a full database restore and recovery.
More about this …