Re: RMAN Duplicate Question

From: Snewber <snew_at_snewx.com>
Date: Thu, 04 Aug 2005 17:28:43 +1000
Message-ID: <dcsg19$11tg$1@bunyip2.cc.uq.edu.au>

Holger Baer wrote:
> Snewber wrote:
>

>> Yes, it's great when you receive a good succinct helpful answer which 
>> happens most times.
>>
>> RMAN can be quite hard to learn for some of the more advanced 
>> features. Looks like the KISS principle wasn't strongly adhered to by 
>> oracle :( which is a bit disappointing when you consider how crucial 
>> backup and recovery is.
>>

>
> Would you name but one? I've always found that as soon as I understood
> what I'm doing (as in what I'm doing with archived redologs, datafiles,
> controlfiles, what is it what a instance does, where are the processes
> running - in other words, the basic stuff), RMAN is just a peace of cake.
>
> And stop top posting please.
>
> Regards,
> Holger

:) Ok, no top post for this one.

Please correct me if I'm wrong :) I'm sure many people will.

Here are some notes I made when writing a script (utilising RMAN) that would simplify hot and cold backups, restorations and database cloning. Please note that I'm not using a recovery catalog which some people would say might make things easier. The points listed below do make some things harder to do, but ultimately RMAN is excellent for doing hot backups, it is just the restoring and recovering which is the difficult part! Using RMAN in ksh scripts to simplify things does require some tricky coding, eg, finding the most recent time to do point in time recovery for duplication purposes. All of my comments relate to the latest 9i RMAN.

To duplicate a database you must have archivelog mode turned on, even for cold backups! This is not needed when you clone databases by recreating controlfiles.

You need to use password files for database duplication. Password files are not normally needed for any other database administration tasks - maybe this will change.

If you are using connect strings rather than OS authentication, then you must have the service name in the listener.ora file, otherwise you will not be able to startup the database from RMAN. You don't need to have static entries in the listener.ora file when using automatic registration, although there are other advantages to using static registration.

Taken from metalink under the search terms of:

"Cannot connect to target database" rman blocked

When duplicating a database, it appears that RMAN cannot connect to a service when the listener has the service status marked as 'BLOCKED' (you can connect using OS authentication) however, the service must be blocked as the database is not mounted as required for database duplication! I had to devise a messy work around for this problem that involves adding entries into the listener.ora and also the tnsnames.ora so that RMAN didn't try to connect to the blocked connection. It would be much simpler if RMAN allowed you to use OS authentication on both the target and auxiliary channel but it doesn't :( You must use a connect string for one of the channels.

You must have the same backup directory structures to restore or duplicate databases regardless of the host. This is not needed when restoring OS backups on different hosts. Yes, you can simply create symlinks for this if need be, but it is an extra unnecessary step I believe.

You can't restore a database to a different name, on the same host (that is currently running a database with the same name), from an old backup that no longer exists in the control file (of the current database) unless you are using a recovery catalog.

There is no file compression (in 9i and lower), ie a 30Gb database can take up nearly 30Gb of disk space (block compression will make it smaller). You can't use a higher version of RMAN to backup a lower version database, ie you can't use 10g RMAN binary compression features on lower version databases. You can probably get around this by using pipes and so on, but it adds more complications to the backup process that really needs to be as simple as possible.

When duplicating a database, RMAN must connect to the source database (called TARGET in RMAN speak). This increases the chances of making a mistake on a production database. When restoring OS backups you don't need to connect to any other database.

So in summary, I believe that when taking some of these things into account, using RMAN is more difficult than cold OS backups. If you want to script the RMAN process (and I would think most DBAs would) then writing a script that uses RMAN isn't a trivial process. If I didn't need hot backups I wouldn't use RMAN as OS backups are so much simpler and more flexible. Please note that the largest database on our site is only 40Gb so I don't need to use a lot of other features in RMAN such as incremental backups. Received on Thu Aug 04 2005 - 02:28:43 CDT